21–30 of 133 posts
Successful eco systems are pragmatic and idiomatically straightforward.
Everything & the kitchen sink in a language is not a recipe for success.
Every language that has a long lifespan spent a long time in feature minimal stasis too. The world won't learn a moving target.
Now that there's been 5 years since v1.0, is there any consensus on design mistakes that Rust made? Any mistakes that people wish they could turn back time and do differently but can't because it would break compatibility with too much existing code out there? That's the more interesting list to me.
They then said that they'd probably do the same thing in 2021.
Now they're debating whether a 2021 edition is needed since there aren't any breaking changes with broad support except for the removal of deprecated syntax and APIs.
This is strong evidence that the answer to your question is "no".
Is there a roadmap for the next 1/2/5 years?
Is the current status of Rust that it is slower than Go ? According to this previous post - https://news.ycombinator.com/item?id=23058147
The killer feature of rust is rapid incremental improvement of the language. Every quarter something gets better.
The progress on the error messages truly is worth highlighting, and kudos to the team for all the hard work there. It's one of the hardest things to get right in a programming language, particularly if that language has a fussy compiler.
I’ve been using the anyhow crate and it’s made error handling almost painless.
- an enum (or struct)
- its Display implementation
- its Error implementation, now just one function
And a few `impl From for MyError` to make the try? operator work.
For a library it's really not that much work. And even that can be simplified further to a few derive macros with another library : thiserror.
Is there a roadmap for the next 1/2/5 years?
* Splitting the compiler into libraries so it's easier to iterate on them, while also making it easier to develop static analysis tools - http://smallcultfollowing.com/babysteps/blog/2020/04/09/libr...
* Improving the async experience - http://smallcultfollowing.com/babysteps/blog/2020/04/30/asyn...
Non-Lexical Lifetimes was huge. Impressive list. I hope the next 5 years bring compiler speed ups.
Is the current status of Rust that it is slower than Go ? According to this previous post - https://news.ycombinator.com/item?id=23058147
While Go may be faster somewhere, that post was not a good comparison. See the discussion around it and the patches made by the community and the final results. See the individual benchmarks: https://github.com/christianscott/levenshtein-distance-bench...
hyperfine go/out 'node javascript/main.js' rust/target/release/rust 1 Benchmark #1: go/out
Time (mean ± σ): 1.888 s ± 0.013 s [User: 2.040 s, System: 0.045 s]
Range (min … max): 1.875 s … 1.918 s 10 runs
Time (mean ± σ): 4.257 s ± 0.033 s [User: 4.295 s, System: 0.042 s]
Range (min … max): 4.221 s … 4.338 s 10 runs
Time (mean ± σ): 874.1 ms ± 50.8 ms [User: 5.688 s, System: 0.830 s]
Range (min … max): 813.5 ms … 1001.9 ms 10 runs
'rust/target/release/rust' ran
2.16 ± 0.13 times faster than 'go/out'
4.87 ± 0.29 times faster than 'node javascript/main.js'Now that there's been 5 years since v1.0, is there any consensus on design mistakes that Rust made? Any mistakes that people wish they could turn back time and do differently but can't because it would break compatibility with too much existing code out there? That's the more interesting list to me.
The "2018 edition" of Rust made breaking changes to the syntax (but the core stayed compatible, so 2015 edition and 2018 edition Rust can be used simultaneously on the same project). They then said that they'd probably do the same thing in 2021. Now they're debating whether a 2021 edition is needed since there aren't any breaking changes with broad support except for the removal of deprecated syntax and APIs. This is…
There are also some thoughts about Rust-like languages with some differences, see https://boats.gitlab.io/blog/post/notes-on-a-smaller-rust/ as a prominent example.