4 ms·

Rust does well on this front. There's a new release every 6 weeks, and majority of users jump on it straight away (to complete shock of everyone not used to it)

by pornel 4y ago

Rust does well on this front. There's a new release every 6 weeks, and majority of users jump on it straight away (to complete shock of everyone not used to it). Rust has editions which keep old code working without any changes, even if you mix it with new code, even if you do it with macros. It has rustfix that automatically migrates majority of the old code. Rust has a standard project layout, standard test runner, and a central code repository, which enables testing language releases against nearly all publicly available code (see "crater run"). The language itself is stricter, with the safe subset being free of UB, so there's less stuff to break to begin with. You can't suddenly use a moved-from object. There's even "cap lints" feature that disables `-Werror` equivalent for dependencies, so that new lints don't break your builds.

pjmlp 4y ago
Editions only work for easy stuff, superficial grammar changes, and in a context where all dependencies are compiled from scratch with exactly the same compiler, aware of all editions. How many editions are rustc, rust-gcc, cranelift and whatever might come, being still kept up to date in 40 years (C++ age)? What about all the language changes that actually require semantic changes, how are epochs supposed to deal with inter-editions calls where the epochs have incompatible ABI expectations between caller and callee, regarded expected compiler behavior?
- spoiler 4y ago
  Rust is so trivially updated that claiming using the latest compiler is problematic almost sounds like a bad faith argument. Everyone in the Rust ecosystem updates withing a few days, because of how trivial it is. Also if you go to GitHub and see a package that's not been updated in 5years, do you think enthusiastically "oh yeah, I'm gonna use this"? Because IMO, if it's not been updated in years, it's probably abandonware. And another point is that I'm happy for them to deprecate/remove 40-year old (or less even) design decisions that have become outdated. Thinking all design decisions are immune to time decay like is foolish. The ABI discussion is a bit worn out by now. Everyone will just tell you to use use C ABI if you need compatibility (until something better comes along?), And there's is a plethora of methods for all sorts of languages to help bridge language gaps.
  - pjmlp 4y ago
    Plenty of enterprise software has not been updated in 5 years, and keeps delivering business value. Suggesting to stick with the OS C ABI (there isn't such thing as C ABI), assuming it was written in V, for compatibility between Rust libraries is kind of ironic. It is a matter to which kind of industry domains Rust folks want to cater to.
  - gspr 4y ago
    > Everyone in the Rust ecosystem updates withing a few days, because of how trivial it is. I love Rust, but this attitude is terrible. Luckily it's also not accurate – it's perfectly fine to stay on your distro's compiler.
diydsp 4y ago
This how i got traumatized by rust: i had a simple task, 1 day long. Write a routine, use a standard output format, theb parse the results. It was to be presented in front of 20 peers the next day. Decided to try the last part in rust... Did a few tutorials, not all of them "worked," but i scratched my head and moved on. Started writing the parser. No examples worked. Couldn't put together any reference code. Even copying straight from web pages! Switched to python. Done in 45 minutes. Told the whole story to the group. Had a laugh. Manager quipped, "that was when you went from leading edge... to bleeding edge." :) Later i learned rust was still making breaking changes, leaving a wake of dysfunctional tutorials. Canttrustthatlanguage.jpg. Thought i'd go back someday when they get it straightened out.
- kubb 4y ago
  You were set up for failure: "do something for tomorrow in a new complex technology, and present in front of multiple peers". Your solution - to use a different technology designed with different requirements, that you were already familiar with, and that you knew could do the job, was the right solution in your situation. Your conclusion could be revised and improved.
  - avgcorrection 4y ago
    > You were set up for failure: "do something for tomorrow in a new complex technology, and present in front of multiple peers". Perhaps you missed this part > > Decided to try the last part in rust...
- herdcall 4y ago
  I don't know when you tried it, but I had a similar need (build a query parser for a tiny SQL subset in a day) a few weeks back, and it took me may be a couple of hours. Actually, picking the library was the more painful part, and this is a problem with Rust IMO, because for most non-trivial new things you (at least I) typically need to dig through crates.io, research, experiment, etc. Anyway, FYI I ended up using PEST (pest.rs) if you still have a need.
- avgcorrection 4y ago
morelisp 4y ago
> Rust does well on this front. Rust needs to exist for at least 20 years before you can say it "does well" on 20yo projects. > majority of users jump on it straight away This is a sign of a language with a tiny mostly-hobbyist user-base.
- spoiler 4y ago
  > This is a sign of a language with a tiny mostly-hobbyist user-base. Or that the tooling is so trivially easy to update that people don't need to think about it. Sometimes if I want to upgrade GCC I need to upgrade the whole os, or have multiple versions installed and be careful where they're installed lest I incur Ubuntu's wrath
nextstepguy 4y ago
Not true. I picked up a git repo 18 months old. I tried to set up my rust dev stack to match the version in cargo. Then hit a lot of issues with dependencies due to abandoned repos used for the crates. I gave up and moved on.
- pornel 4y ago
  A random person on github abandoning their pet project is not the kind of language stability we're talking about here. It's not the kind of complaint you'd write to the ISO committee. You may have run into a project using nightly Rust, which is an explicitly unstable version for testing of experimental not-yet-finished features. Using it requires users to intentionally opt out of having language stability. C++ also has GNU and Clang extensions and experimental implementations of not-yet-standardized features. However, the normal workflow is using a stable version of the compiler. It is backwards compatible with the 1.0 release from 2015, except handful of edge cases that you won't run into an average project. Users are encouraged to use crates.io and keep Cargo.lock which guarantees they get the same dependencies that worked last time.
fortran77 4y ago
How on earth can you predict that rust will be stable in 20 years?
pclmulqdq 4y ago
> Rust has a standard project layout, standard test runner, and a central code repository, which enables testing language releases against nearly all publicly available code (see "crater run"). I'm not sure why this is treated as a selling point. It helps projects up to a point, but the minute you want to do something that doesn't fit the mold, it makes things a lot harder. All of these products are orthogonal to a language, and yet they are very tightly bundled with the idea of using the Rust language. It certainly makes "business logic" systems and web backends easier to implement, but I'm not sure many people were building those in C++ to begin with (except in legacy systems, where you are stuck with what you have). Also, I'm not sure how a language that is less than 10 years old (in its released, 1.x versions) has any claim to having no problems with evolution over the next 10 years.
- dtolnay 4y ago
  > the minute you want to do something that doesn't fit the mold, it makes things a lot harder This is not my experience at all; it's been extremely helpful for doing things outside the mold: In a work codebase that is millions of lines of first-party Rust code with thousands of third-party Rust dependencies from crates.io, we're building with Buck not Cargo because that is what the rest of the monorepo uses for C++ and other languages. It's fantastic for this that all the third-party projects describe their dependency graph in the same standard Cargo manifest format and follow a standard project layout, even though our builds do not use Cargo, because we can programmatically translate them to Buck targets.

by pornel 4y ago

pjmlp 4y ago

Editions only work for easy stuff, superficial grammar changes, and in a context where all dependencies are compiled from scratch with exactly the same compiler, aware of all editions. How many editions are rustc, rust-gcc, cranelift and whatever might come, being still kept up to date in 40 years (C++ age)? What about all the language changes that actually require semantic changes, how are epochs supposed to deal with inter-editions calls where the epochs have incompatible ABI expectations between caller and callee, regarded expected compiler behavior?

spoiler 4y ago
Rust is so trivially updated that claiming using the latest compiler is problematic almost sounds like a bad faith argument. Everyone in the Rust ecosystem updates withing a few days, because of how trivial it is. Also if you go to GitHub and see a package that's not been updated in 5years, do you think enthusiastically "oh yeah, I'm gonna use this"? Because IMO, if it's not been updated in years, it's probably abandonware. And another point is that I'm happy for them to deprecate/remove 40-year old (or less even) design decisions that have become outdated. Thinking all design decisions are immune to time decay like is foolish. The ABI discussion is a bit worn out by now. Everyone will just tell you to use use C ABI if you need compatibility (until something better comes along?), And there's is a plethora of methods for all sorts of languages to help bridge language gaps.
- pjmlp 4y ago
  Plenty of enterprise software has not been updated in 5 years, and keeps delivering business value. Suggesting to stick with the OS C ABI (there isn't such thing as C ABI), assuming it was written in V, for compatibility between Rust libraries is kind of ironic. It is a matter to which kind of industry domains Rust folks want to cater to.
- gspr 4y ago
  > Everyone in the Rust ecosystem updates withing a few days, because of how trivial it is. I love Rust, but this attitude is terrible. Luckily it's also not accurate – it's perfectly fine to stay on your distro's compiler.

diydsp 4y ago

This how i got traumatized by rust: i had a simple task, 1 day long. Write a routine, use a standard output format, theb parse the results. It was to be presented in front of 20 peers the next day. Decided to try the last part in rust... Did a few tutorials, not all of them "worked," but i scratched my head and moved on. Started writing the parser. No examples worked. Couldn't put together any reference code. Even copying straight from web pages! Switched to python. Done in 45 minutes. Told the whole story to the group. Had a laugh. Manager quipped, "that was when you went from leading edge... to bleeding edge." :) Later i learned rust was still making breaking changes, leaving a wake of dysfunctional tutorials. Canttrustthatlanguage.jpg. Thought i'd go back someday when they get it straightened out.

kubb 4y ago
You were set up for failure: "do something for tomorrow in a new complex technology, and present in front of multiple peers". Your solution - to use a different technology designed with different requirements, that you were already familiar with, and that you knew could do the job, was the right solution in your situation. Your conclusion could be revised and improved.
- avgcorrection 4y ago
  > You were set up for failure: "do something for tomorrow in a new complex technology, and present in front of multiple peers". Perhaps you missed this part > > Decided to try the last part in rust...
herdcall 4y ago
I don't know when you tried it, but I had a similar need (build a query parser for a tiny SQL subset in a day) a few weeks back, and it took me may be a couple of hours. Actually, picking the library was the more painful part, and this is a problem with Rust IMO, because for most non-trivial new things you (at least I) typically need to dig through crates.io, research, experiment, etc. Anyway, FYI I ended up using PEST (pest.rs) if you still have a need.
avgcorrection 4y ago

morelisp 4y ago

> Rust does well on this front. Rust needs to exist for at least 20 years before you can say it "does well" on 20yo projects. > majority of users jump on it straight away This is a sign of a language with a tiny mostly-hobbyist user-base.

spoiler 4y ago
> This is a sign of a language with a tiny mostly-hobbyist user-base. Or that the tooling is so trivially easy to update that people don't need to think about it. Sometimes if I want to upgrade GCC I need to upgrade the whole os, or have multiple versions installed and be careful where they're installed lest I incur Ubuntu's wrath

nextstepguy 4y ago

Not true. I picked up a git repo 18 months old. I tried to set up my rust dev stack to match the version in cargo. Then hit a lot of issues with dependencies due to abandoned repos used for the crates. I gave up and moved on.

pornel 4y ago
A random person on github abandoning their pet project is not the kind of language stability we're talking about here. It's not the kind of complaint you'd write to the ISO committee. You may have run into a project using nightly Rust, which is an explicitly unstable version for testing of experimental not-yet-finished features. Using it requires users to intentionally opt out of having language stability. C++ also has GNU and Clang extensions and experimental implementations of not-yet-standardized features. However, the normal workflow is using a stable version of the compiler. It is backwards compatible with the 1.0 release from 2015, except handful of edge cases that you won't run into an average project. Users are encouraged to use crates.io and keep Cargo.lock which guarantees they get the same dependencies that worked last time.

fortran77 4y ago

How on earth can you predict that rust will be stable in 20 years?

pclmulqdq 4y ago

> Rust has a standard project layout, standard test runner, and a central code repository, which enables testing language releases against nearly all publicly available code (see "crater run"). I'm not sure why this is treated as a selling point. It helps projects up to a point, but the minute you want to do something that doesn't fit the mold, it makes things a lot harder. All of these products are orthogonal to a language, and yet they are very tightly bundled with the idea of using the Rust language. It certainly makes "business logic" systems and web backends easier to implement, but I'm not sure many people were building those in C++ to begin with (except in legacy systems, where you are stuck with what you have). Also, I'm not sure how a language that is less than 10 years old (in its released, 1.x versions) has any claim to having no problems with evolution over the next 10 years.

dtolnay 4y ago
> the minute you want to do something that doesn't fit the mold, it makes things a lot harder This is not my experience at all; it's been extremely helpful for doing things outside the mold: In a work codebase that is millions of lines of first-party Rust code with thousands of third-party Rust dependencies from crates.io, we're building with Buck not Cargo because that is what the rest of the monorepo uses for C++ and other languages. It's fantastic for this that all the third-party projects describe their dependency graph in the same standard Cargo manifest format and follow a standard project layout, even though our builds do not use Cargo, because we can programmatically translate them to Buck targets.