News for hackers. Stuff that matters.
Re:Thoughts on replacement languages by keeperofdakeys on Saturday January 10, 2015 @08:00PM (#8868615)
What's the point in making 1.0 if it's not forwards compatible? There were some very serious issues with the language, that if not addressed, would require rewriting code when they were fixed. Adding them in 2.0 would probably doom it.

It's not like 1.0 represents all the features they want though, there are many language and library features that are planned for the future.

Re:Thoughts on replacement languages by lukasm on Saturday January 10, 2015 @08:18PM (#8868659)
I can't find any empirical evidence that adding features in the next version dooms the language. The opposite is true. All successful languages started small.
Re:Thoughts on replacement languages by codygman on Saturday January 10, 2015 @09:39PM (#8868814)
Python is being hurt by Python 3.0 changing so much.
Re:Thoughts on replacement languages by lukasm on Saturday January 10, 2015 @10:26PM (#8868920)
By breaking backward compatibility. Not forward.
Re:Thoughts on replacement languages by keeperofdakeys on Monday January 12, 2015 @06:10AM (#8873279)
The changes that are currently being done in Rust for 1.0 are those kinds of breaking changes. Many things that are being changed have been in a state of semi-decay from old experiments, and old features of the language.

As an example, the IO subsystem had lots of generality designed for when lightweight tasks were still a feature. By ripping them out, the library is both easier to use, and simpler for future expansion. It was also changed to support the general error-handling facilities that Rust now has (which are partly similar to the old IO-specific error handling features, but wouldn't work well with other libraries).

Others like the collection-api cleanup were badly needed, because of inconsistency and a lack of direction over time. Now the collection-api is much cleaner, and consistent between different types of collections. This allows them to add things like collection-api traits in the future, and newer collections that can follow the same api conventions