Re:Announcing the new Rust package manager, Cargo
by mercurial on Tuesday March 18, 2014 @03:40AM
(#7420647)
> Python 3 is a bad choice in my opinion as it hasn't learned from the precedent of Perl 6 "failure" (this was finally resolved when Perl 5 development has been restarted).
I think they suffer from opposite issues. Perl 6's problem is that it was way too ambitious for the manpower behind it, and it turned into the Duke Nukem Forever of programming languages. The issue with Python 3 was that it introduced breaking changes, but was widely felt not to bring enough to the table to warrant these changes.
Re:Announcing the new Rust package manager, Cargo
by lifthrasiir on Tuesday March 18, 2014 @04:56AM
(#7420853)
Dividing the language is bad in general, since it essentially divides the ecosystem behind them. In the case of Perl 6 the ecosystem couldn't control the ambitious development goal; in the case of Python 3 the ecosystem could control that but could not realize that the smooth transition plan is still a transition. There are less problematic but similar causes in other languages, PHP 4 vs. PHP 5 vs. PHP 5.3 (oops!), D 1.0 vs. D 2.0 and so on.
I've done it many times, and it is not quite bad to do that (it can even give a single executable file at some initial slowdown). In fact, it is so impressive that the non-compiled implementation can make a working and portable executable file at all. Rust is primarily a (ahead-of-time) compiled language and it would take a single command `rustc foo.rs` (or possibly `rustc -L<deps> foo.rs`?) to produce an executable file `foo.exe`. [1]
[1] Assuming you haven't used 0.9 and later versions, it now produces a statically linked binary by default. No `libblahblabla.dll` around.
> If you do not consider consoles or embedded systems major platforms that is. Most of the world is not POSIX.
It really depends on the definition (and I'm not saying POSIX is not the most widely available platform), but mobiles alone (approx. 300 million units sold) give a significant portion of POSIX systems.
> The last time I tried to use Rust on Windows it required a particular version of MinGW.
You haven't used 0.9, right? That restriction was temporary and it has now lifted. I think you still need MinGW for linkers right now though.
> I have used C and C++ for a long time, and I cannot say that dependency hell was ever a problem. One of the many things wrong with the "package manager" paradigm is that it encourages people to write software which is a tangled web of dependencies. Software should have few third-party dependencies, that makes maintenance and porting a lot easier. Witness the recent Python 2 -> 3 drama. The primary reason why people did not, could not upgrade to Python 3 was because they had to wait for all the dependencies of their apps to be ported. Many are still waiting.
Python 3 is a bad choice in my opinion as it hasn't learned from the precedent of Perl 6 "failure" (this was finally resolved when Perl 5 development has been restarted). But that does not justify the C/C++'s lack of package system: there are lots of old and faulty C/C++ codes around due to the lack of recent C99 or C11 or C++11 compilers at the disposal even without the package system.