4 ms·

Well, precisely : if people want modern/innovating/fast evolving languages, they can use Rust, Go, Elixir, etc. I actually started using C for my side projects

Well, precisely : if people want modern/innovating/fast evolving languages, they can use Rust, Go, Elixir, etc. I actually started using C for my side projects since two years precisely because I want very long term backward compatibility (that is, being able to leave a program for years without maintaining it, then make a small edit in it and build it with minimum pain). C is perfect for that, and I agree with the sentiment that backward compatibility is its most important feature.

deleted 6y ago
[deleted]
coder543 6y ago
> I actually started using C for my side projects since two years precisely because I want very long term backward compatibility (that is, being able to leave a program for years without maintaining it, then make a small edit in it and build it with minimum pain). Rust actually takes a very strong stance on maintaining backwards compatibility, and Go's stance is arguably even stronger in most cases. You're implying incorrectly that these languages are just breaking things left and right for no reason other than "innovation!", which isn't true. The overwhelming majority of Rust and Go code from years ago will compile without problems today. Any code from post-1.0 that doesn't compile today was (inadvertently) relying on buggy, incorrect behaviors that have since been fixed... and even then, not all incorrect behaviors get fixed because compatibility is considered so important. C is fine for certain applications, but no one should choose it for side projects based on some notion of backwards compatibility, in my opinion. If some company is building a business application that needs "backwards compatibility" in the sense that it can run on all sorts of arcane microarchitectures and operating systems, then sure... C is still a really painful* choice, but it might be the right choice then, or if there's an existing C code base, then it probably doesn't make business sense to rewrite it any time soon. * yes, having no protection from footguns, no real standard library, no built-in concept of asynchronous code, and very little of anything useful is definitely painful. If C is the only valid choice for a project, then it's the only valid choice, and that's what you have to do. The number of projects where you simply can't use something other than C is diminishing by the day.
- jki275 6y ago
  Rust and Go haven't been around long enough to make those statements about them.
  - virtue3 6y ago
    That and, while "backwards compatability" has been quoted as important things in these languages. I can attest to rust having issues with what is "idiomatic" rust: https://timidger.github.io/posts/i-cant-keep-up-with-idiomatic-rust/ https://timidger.github.io/posts/i-cant-keep-up-with-idiomat... there are other similar complaints around the net. While the C and C++ code I wrote over 2 decades ago is now finally "out of date" as of 5 years ago. It took a while. Not 2-3 years. Which is absolutely attributed to the language being new, not a design fault. C is already "settled"
    - im3w1l 6y ago
      It seems idiomatic C++ is recently changing much faster than before, as C++ feels the need to keep pace with competing languages. But you don't have to keep up with what's idiomatic.
      - guenthert 6y ago
        It can cause friction though, if new programmers work on old code or new and seasoned programmers work on the same project. Of those who do like Common Lisp, many like it because the standard hasn't changed in nearly thirty years (while simultaneously offering features added to the C++ standard just very recently, e.g. a filesystem path abstraction).
    - jki275 6y ago
      I'm learning Rust now, I don't have anything particularly against it other than the obvious, big static binaries and such, and maybe those will be fixed eventually. I've been able to compile and run C and C++ code from 20 years ago a truly amazing number of times. It's really surprising at how easy it is to work with well written code even if it's decades old. Will Rust and Go age that way? Maybe. Too soon to tell.
blargmaster33 6y ago
You forgot C++
apta 6y ago
golang is not modern nor fast evolving.
sacado2 6y ago
I think it's the first time I see someone call Go a modern/innovating/fast evloving language. What attracted me to this language in the first place is the fact backward compatibility is seen as a dogma in the community. It's one of its strongest selling points IMO. I have production code written in 2014 that still compiles and works perfectly without any warning from any (popular) linter.

deleted 6y ago

[deleted]

coder543 6y ago

> I actually started using C for my side projects since two years precisely because I want very long term backward compatibility (that is, being able to leave a program for years without maintaining it, then make a small edit in it and build it with minimum pain). Rust actually takes a very strong stance on maintaining backwards compatibility, and Go's stance is arguably even stronger in most cases. You're implying incorrectly that these languages are just breaking things left and right for no reason other than "innovation!", which isn't true. The overwhelming majority of Rust and Go code from years ago will compile without problems today. Any code from post-1.0 that doesn't compile today was (inadvertently) relying on buggy, incorrect behaviors that have since been fixed... and even then, not all incorrect behaviors get fixed because compatibility is considered so important. C is fine for certain applications, but no one should choose it for side projects based on some notion of backwards compatibility, in my opinion. If some company is building a business application that needs "backwards compatibility" in the sense that it can run on all sorts of arcane microarchitectures and operating systems, then sure... C is still a really painful* choice, but it might be the right choice then, or if there's an existing C code base, then it probably doesn't make business sense to rewrite it any time soon. * yes, having no protection from footguns, no real standard library, no built-in concept of asynchronous code, and very little of anything useful is definitely painful. If C is the only valid choice for a project, then it's the only valid choice, and that's what you have to do. The number of projects where you simply can't use something other than C is diminishing by the day.

jki275 6y ago
Rust and Go haven't been around long enough to make those statements about them.
- virtue3 6y ago
  That and, while "backwards compatability" has been quoted as important things in these languages. I can attest to rust having issues with what is "idiomatic" rust: https://timidger.github.io/posts/i-cant-keep-up-with-idiomatic-rust/ https://timidger.github.io/posts/i-cant-keep-up-with-idiomat... there are other similar complaints around the net. While the C and C++ code I wrote over 2 decades ago is now finally "out of date" as of 5 years ago. It took a while. Not 2-3 years. Which is absolutely attributed to the language being new, not a design fault. C is already "settled"
  - im3w1l 6y ago
    It seems idiomatic C++ is recently changing much faster than before, as C++ feels the need to keep pace with competing languages. But you don't have to keep up with what's idiomatic.
    - guenthert 6y ago
      It can cause friction though, if new programmers work on old code or new and seasoned programmers work on the same project. Of those who do like Common Lisp, many like it because the standard hasn't changed in nearly thirty years (while simultaneously offering features added to the C++ standard just very recently, e.g. a filesystem path abstraction).
  - jki275 6y ago
    I'm learning Rust now, I don't have anything particularly against it other than the obvious, big static binaries and such, and maybe those will be fixed eventually. I've been able to compile and run C and C++ code from 20 years ago a truly amazing number of times. It's really surprising at how easy it is to work with well written code even if it's decades old. Will Rust and Go age that way? Maybe. Too soon to tell.

blargmaster33 6y ago

You forgot C++

apta 6y ago

golang is not modern nor fast evolving.

sacado2 6y ago

I think it's the first time I see someone call Go a modern/innovating/fast evloving language. What attracted me to this language in the first place is the fact backward compatibility is seen as a dogma in the community. It's one of its strongest selling points IMO. I have production code written in 2014 that still compiles and works perfectly without any warning from any (popular) linter.