3 ms·

Of course. But they are starting with 40 years less baggage. And can reasonably assume a modern hardware architecture, for example.

uecker 1y ago
You could also just use the newest C standard. I would personally trust that C23 code written today still works in ten years and still has excelelnt support in compilers a lot more than that this is the case for any code written in Zig, Odin, or Rust.
- PaulRobinson 1y ago
  Ah, but then you have potential interop and portability issues. C11 isn't yet universally adopted, and there are some dark corners out there where even ANSI (C89/C90) is not quite embraced and original K&R is holding out. I think the jury is out on Zig and Odin (but I like Zig a lot, in particular), but I feel Rust has hit a tipping point - like Go, Python and Java - where there's too much production code out there for it to disappear in the next ten years. If you were to ask me about languages where that might not be the case in ten years, I'd point to where usage is not very production oriented (R, Julia), or where people have had a good try and decided they want to pull back investment (anecdotally, Ruby and Scala seem to be on that curve right now).
  - uecker 1y ago
    Nothing really disappears, the question is how strong the ecosystem is in ten years and how good the support for the code you write today. Rust will not go away but I doubt that the code written today still works without hassle or that all the 1000 crates it depends on still exist. That there are dark corners using C89 or K&R is not a weakness, it demonstrates how strong the C ecosystem is. If you write something in Zig or Rust now, you need to realize that in 10 years it might also be considered ugly legacy code, even if you think it is shiny modern code today. The question is then if it is as easy as using "gcc -std=c89" to work with it.
    - ay 1y ago
      A piece of anecdata: my Rust code from 8 years ago still compiles fine, though compiler complains about not having the defined edition set.
      - uecker 1y ago
        News such as this one do not build confidence though: https://internals.rust-lang.org/t/type-inference-breakage-in-1-80-has-not-been-handled-well/21374 https://internals.rust-lang.org/t/type-inference-breakage-in...
        ay 1y ago
        Ah. Apparently I didn’t use that crate, so happily missed that footgun, thanks for the info! That is an unfortunate case. Though I suspect it’s fair to say the entire settlement is built of glass houses here :-) https://news.ycombinator.com/item?id=43798312 https://news.ycombinator.com/item?id=43798312 I suppose if one wants absolutely no surprises, they will need to lock the entire toolchain as well, regardless of the language…
        uecker 1y ago
        Maybe, but this GCC change would affect only code that is already broken and then there is even a compiler flag to fix it.

uecker 1y ago

You could also just use the newest C standard. I would personally trust that C23 code written today still works in ten years and still has excelelnt support in compilers a lot more than that this is the case for any code written in Zig, Odin, or Rust.

PaulRobinson 1y ago
Ah, but then you have potential interop and portability issues. C11 isn't yet universally adopted, and there are some dark corners out there where even ANSI (C89/C90) is not quite embraced and original K&R is holding out. I think the jury is out on Zig and Odin (but I like Zig a lot, in particular), but I feel Rust has hit a tipping point - like Go, Python and Java - where there's too much production code out there for it to disappear in the next ten years. If you were to ask me about languages where that might not be the case in ten years, I'd point to where usage is not very production oriented (R, Julia), or where people have had a good try and decided they want to pull back investment (anecdotally, Ruby and Scala seem to be on that curve right now).
- uecker 1y ago
  Nothing really disappears, the question is how strong the ecosystem is in ten years and how good the support for the code you write today. Rust will not go away but I doubt that the code written today still works without hassle or that all the 1000 crates it depends on still exist. That there are dark corners using C89 or K&R is not a weakness, it demonstrates how strong the C ecosystem is. If you write something in Zig or Rust now, you need to realize that in 10 years it might also be considered ugly legacy code, even if you think it is shiny modern code today. The question is then if it is as easy as using "gcc -std=c89" to work with it.
  - ay 1y ago
    A piece of anecdata: my Rust code from 8 years ago still compiles fine, though compiler complains about not having the defined edition set.
    - uecker 1y ago
      News such as this one do not build confidence though: https://internals.rust-lang.org/t/type-inference-breakage-in-1-80-has-not-been-handled-well/21374 https://internals.rust-lang.org/t/type-inference-breakage-in...
      - ay 1y ago
        Ah. Apparently I didn’t use that crate, so happily missed that footgun, thanks for the info! That is an unfortunate case. Though I suspect it’s fair to say the entire settlement is built of glass houses here :-) https://news.ycombinator.com/item?id=43798312 https://news.ycombinator.com/item?id=43798312 I suppose if one wants absolutely no surprises, they will need to lock the entire toolchain as well, regardless of the language…
        uecker 1y ago
        Maybe, but this GCC change would affect only code that is already broken and then there is even a compiler flag to fix it.