4 ms·
This is amazing, and great. "Does a language change too much" is very much use dependent, and it's great to have the data. For me, an embedded systems develop
by as-j 7y ago
This is amazing, and great. "Does a language change too much" is very much use dependent, and it's great to have the data.
For me, an embedded systems developer, this is an order of magnitude too much. Rust is so appealing for my use case in many ways, but I need an environment that a team can easily work in for years. My current code base is 10 years old. Our base system dates from 2017, and it took until 2018 for us to update to that. We were going to do a late 2019 base update, but sadly the project was delayed for other reasons. Our application side updates monthly, a much smaller OTA DFU. (over the air device firmware update)
You can compare it Lua:
https://www.lua.org/versions.html https://www.lua.org/versions.html
The community is much smaller but it's interesting to see even at it's comparatively glacial release schedule there's a large split between 5.1/5.3.
Why do a rapidly evolving language, stdlib, etc matter?
1. We're going to be year(s) behind. I need everyone to learn and be proficient at the languages we use. They need good consistent doc and manual for our version. And not complain that we're on 1.31.0 but this great feature is in 1.33.1.
2. Moving base languages is support, not direct project improvement. While we standstill moving the base system/language/tooling forward our customer releases a new feature.
3. People are always going to google "how to do silly thing" and get code snippets. Heck I do this all the time with Python. =) It's really nice for this be somewhat consistent/right.
Sigh, as an embedded dev I'm so torn on Rust.
- steveklabnik 7y agoHave you heard of the Sealed Rust work?
- as-j 7y agoNope? This? https://ferrous-systems.com/blog/2019-06-05-sealed-rust-the-pitch.html https://ferrous-systems.com/blog/2019-06-05-sealed-rust-the-... Do you have a short version recap in 1 or 2 sentences? Plus any liensing/costs/etc/etc?
- steveklabnik 7y agoYep! The short recap is: some folks are trying to get a subset of the language certified. They run an entire consultancy that does a lot of embedded Rust work. I am hoping that this will help to alleviate the issues you're talking about; we'll see how it goes!
- as-j 7y agoThat's awesome thanks! I look forward to it.
- worik 7y agohttps://github.com/ferrous-systems/sealed-rust https://github.com/ferrous-systems/sealed-rust Awesome
- masklinn 7y ago> 1. We're going to be year(s) behind. I need everyone to learn and be proficient at the languages we use. They need good consistent doc and manual for our version. And not complain that we're on 1.31.0 but this great feature is in 1.33.1. rustup doc gives the standard documentation (book and API) for whatever version is currently active. You should be able to install and default to any version of the toolchain you want e.g. `rustup default 1.31.0` and you're done > And not complain that we're on 1.31.0 but this great feature is in 1.33.1. Surely that has nothing do do with Rust's evolution, and happens on every language which is not literally dead? Even on languages with a relatively slow release schedule this happens. You mention Python, that's what we use at $dayjob, we're currently on 3.5 compatibility. Some colleagues would like to use f-strings, or walrus, or dataclasses, and they can't and that's life.
- as-j 7y agoOn 2 you've got a point, but it does depend on the dev and how fast a language is moving. I tend to find, or feel this push on newer languages to always being pushed forward. We're on python 3.7, 3.5 and 2.7, yay! :) Don't use it on embedded systems though, version just depends on who's backend, mfgtest, etc, we're dealing with.