3 ms·

Define "unfinished". You're being deliberately misleading with that word. The Rust stdlib has everything most folks need. There are some things like simd which

Define "unfinished". You're being deliberately misleading with that word. The Rust stdlib has everything most folks need. There are some things like simd which are currently being actively pushed that are "missing", but even C++ doesn't have "stable" simd, it has compiler extensions in some compilers. Most of the unstable APIs in the stdlib exist independently in the crates.io ecosystem anyway (or their functionality can be replicated with other stdlib apis). The fact that the rust stdlib can still be improved does not make it unfinished (or, if it does, being "unfinished" is not a bad thing). By that argument every language that still pushes out new versions is unfinished. Your definitions of "stable" and "finished" exclude almost all the languages/compilers out there, I highly doubt these are the definitions that 99% of programmers use.

lacampbell 10y ago
Define "unfinished". You're being deliberately misleading with that word. Oh I made up my own definition for "unfinished". Just like the rust team has for "stable". Give me time and I'll make a blog post explaining what my redefinition means, then I'll spend my time on hacker news and slashdot and reddit "correcting" everyone. Your definitions of "stable" and "finished" exclude almost all the languages/compilers out there, Changing the API of the standard library on minor release versions is stable now. Got it. Fearless concurrency, etc etc.
- steveklabnik 10y ago
  > Changing the API of the standard library Adding to the API of the standard library, as SemVer specs. Backwards incompatible changes aren't made. (Except for soundness reasons, which happens in extremely rare circumstances, and are made with great care with regards to the upgrade path.)
- detaro 10y ago
  Rust releases follow SemVer, which is not exactly an uncommon standard for those things. Code that works in released version 1.X.Y is supposed to work in all following versions. Are there languages that won't add backwards-compatible features?
- Manishearth 10y ago
  > Changing the API of the standard library on minor release versions is stable now No it's not. A release version of rust cannot access that API. It's just there in the docs. We could possibly remove it from the release docs, or make the messaging clearer (this is being discussed), but you can't use it on a release. That is stable. I mean, you have the same situation with https://gcc.gnu.org/projects/cxx-status.html#cxx1z https://gcc.gnu.org/projects/cxx-status.html#cxx1z . They, too, explicitly say that opting in to this may break backwards compatibility (i.e. it's unstable). http://clang.llvm.org/cxx_status.html http://clang.llvm.org/cxx_status.html says something similar. In both those cases the default release compiler contains the ability to opt in. With Rust, even this isn't the case; you have to download a different compiler if you really really want those features, and even then you still have to explicitly opt in at a fine-grained level.

lacampbell 10y ago

Define "unfinished". You're being deliberately misleading with that word. Oh I made up my own definition for "unfinished". Just like the rust team has for "stable". Give me time and I'll make a blog post explaining what my redefinition means, then I'll spend my time on hacker news and slashdot and reddit "correcting" everyone. Your definitions of "stable" and "finished" exclude almost all the languages/compilers out there, Changing the API of the standard library on minor release versions is stable now. Got it. Fearless concurrency, etc etc.

steveklabnik 10y ago
> Changing the API of the standard library Adding to the API of the standard library, as SemVer specs. Backwards incompatible changes aren't made. (Except for soundness reasons, which happens in extremely rare circumstances, and are made with great care with regards to the upgrade path.)
detaro 10y ago
Rust releases follow SemVer, which is not exactly an uncommon standard for those things. Code that works in released version 1.X.Y is supposed to work in all following versions. Are there languages that won't add backwards-compatible features?
Manishearth 10y ago
> Changing the API of the standard library on minor release versions is stable now No it's not. A release version of rust cannot access that API. It's just there in the docs. We could possibly remove it from the release docs, or make the messaging clearer (this is being discussed), but you can't use it on a release. That is stable. I mean, you have the same situation with https://gcc.gnu.org/projects/cxx-status.html#cxx1z https://gcc.gnu.org/projects/cxx-status.html#cxx1z . They, too, explicitly say that opting in to this may break backwards compatibility (i.e. it's unstable). http://clang.llvm.org/cxx_status.html http://clang.llvm.org/cxx_status.html says something similar. In both those cases the default release compiler contains the ability to opt in. With Rust, even this isn't the case; you have to download a different compiler if you really really want those features, and even then you still have to explicitly opt in at a fine-grained level.