5 ms·

Is there a case for or against incrementally adopting Rust ?

glandium 4y ago
They are experimenting https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/rust-toolchain.md https://chromium.googlesource.com/chromium/src/+/refs/heads/...
- Existenceblinks 4y ago
  Is there any common module that can be shared amongst browser engines? I can feel though it sounds hard to extract these common stuff into .. "browser engine common core"? (e.g. https://github.com/SerenityOS/serenity/tree/master/Userland/Libraries/LibWeb https://github.com/SerenityOS/serenity/tree/master/Userland/...). That would be nice for next gen browser invention.
  - sbdncuvh 4y ago
  - hi_herbert 4y ago
    You can find some module candidates here https://github.com/servo/servo/issues/24026#issue-483508434 https://github.com/servo/servo/issues/24026#issue-483508434 The one that make the most economic sense would be for mozilla to drop spidermonkey and make v8 faster instead
izacus 4y ago
Which of these things is Rust immune to? How stable is it over a 10, 15, 20 year life? How old can the code be that Rust compiler still compiles and links successfully and bug-free?
- otabdeveloper4 4y ago
  Don't worry your little brain about these silly things. Programming is hard, let's go (language) shopping instead!
- 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.
- tonetheman 4y ago
  Ok here come the rust apologists. Well when rust makes changes every 6 weeks we all hold hands and update all of our code.
hi_herbert 4y ago
Betting on carbon would allow transparent FFI like Kotlin, typescript or graalvm achieve, which is economically disruptive. Rust seems more like a plan B
jokoon 4y ago
Rust is too hard to learn. I like it, but it only aims at replacing ada, not c++. I asked around and there is currently no good way to make modern native ui apps with rust. It would be okay if the syntax of rust looked a bit more like C, but it doesn't, it can be a bit difficult to read.
- oconnor663 4y ago
  Rust's learning story has some interesting dichotomies in it. For sure, no one disputes that learning Rust is harder than say Python or Java. But how does it compare to C or C++? My take (which I have no proof for, to be clear) is that learning Rust is much easier than either of those if you're truly starting from zero. Some scattered thoughts about this: - Experienced C and C++ devs have to unlearn certain patterns when they start Rust. C++ experience can be a huge help, but if you insist on using the patterns you're used to in Rust, you often have a terrible time and feel like the compiler can't handle useful programs. - Particularly with C, what we usually mean when we say "learn" has gotten kind of out of date. If someone with a few years of programming experience says they "know" Python, we might assume they can make an HTTP request and parse some JSON with a couple minutes of googling the relevant API docs. But of course in C, those tasks are much more challenging, and we often allow that someone has "learned" C even if they can't do those things without great difficulty. Part of C's reputation for being (comparatively) easy to learn is that we don't expect programmers to be able to do the same variety of tasks with it. - A lot depends on what standard of correctness and security we want to apply. For example, writing multithreaded code in Rust has an extra steep learning curve, but the resulting code is data-race-free once it compiles. Writing big multithreaded programs without data races takes many years of experience in C and C++, and it might be genuinely impossible for sufficiently large projects. So depending on what we understand "learning to write multithreaded programs" to mean, we could say that Rust is much harder but also that Rust is much easier.

They are experimenting https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/rust-toolchain.md https://chromium.googlesource.com/chromium/src/+/refs/heads/...

Existenceblinks 4y ago
Is there any common module that can be shared amongst browser engines? I can feel though it sounds hard to extract these common stuff into .. "browser engine common core"? (e.g. https://github.com/SerenityOS/serenity/tree/master/Userland/Libraries/LibWeb https://github.com/SerenityOS/serenity/tree/master/Userland/...). That would be nice for next gen browser invention.
- sbdncuvh 4y ago
- hi_herbert 4y ago
  You can find some module candidates here https://github.com/servo/servo/issues/24026#issue-483508434 https://github.com/servo/servo/issues/24026#issue-483508434 The one that make the most economic sense would be for mozilla to drop spidermonkey and make v8 faster instead

izacus 4y ago

Which of these things is Rust immune to? How stable is it over a 10, 15, 20 year life? How old can the code be that Rust compiler still compiles and links successfully and bug-free?

otabdeveloper4 4y ago
Don't worry your little brain about these silly things. Programming is hard, let's go (language) shopping instead!
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.
tonetheman 4y ago
Ok here come the rust apologists. Well when rust makes changes every 6 weeks we all hold hands and update all of our code.

hi_herbert 4y ago

Betting on carbon would allow transparent FFI like Kotlin, typescript or graalvm achieve, which is economically disruptive. Rust seems more like a plan B

jokoon 4y ago

Rust is too hard to learn. I like it, but it only aims at replacing ada, not c++. I asked around and there is currently no good way to make modern native ui apps with rust. It would be okay if the syntax of rust looked a bit more like C, but it doesn't, it can be a bit difficult to read.

oconnor663 4y ago
Rust's learning story has some interesting dichotomies in it. For sure, no one disputes that learning Rust is harder than say Python or Java. But how does it compare to C or C++? My take (which I have no proof for, to be clear) is that learning Rust is much easier than either of those if you're truly starting from zero. Some scattered thoughts about this: - Experienced C and C++ devs have to unlearn certain patterns when they start Rust. C++ experience can be a huge help, but if you insist on using the patterns you're used to in Rust, you often have a terrible time and feel like the compiler can't handle useful programs. - Particularly with C, what we usually mean when we say "learn" has gotten kind of out of date. If someone with a few years of programming experience says they "know" Python, we might assume they can make an HTTP request and parse some JSON with a couple minutes of googling the relevant API docs. But of course in C, those tasks are much more challenging, and we often allow that someone has "learned" C even if they can't do those things without great difficulty. Part of C's reputation for being (comparatively) easy to learn is that we don't expect programmers to be able to do the same variety of tasks with it. - A lot depends on what standard of correctness and security we want to apply. For example, writing multithreaded code in Rust has an extra steep learning curve, but the resulting code is data-race-free once it compiles. Writing big multithreaded programs without data races takes many years of experience in C and C++, and it might be genuinely impossible for sufficiently large projects. So depending on what we understand "learning to write multithreaded programs" to mean, we could say that Rust is much harder but also that Rust is much easier.