6 ms·

Well, there's Go. Java was supposed to fix all of these problems, but it's a mess in its own way. There's no perfect language. Almost simultaneously with C th

by gregjor 12y ago

Well, there's Go. Java was supposed to fix all of these problems, but it's a mess in its own way. There's no perfect language. Almost simultaneously with C the Pascal language was introduced, completely safe and easier to learn. It enjoyed a period of popularity, and for a while it was widely taught in high schools and universities. Some big systems were built in Pascal, but every big Pascal app I've ever seen relied on external code in C (or assembly language) because Pascal is hobbled to enforce safety (see Brian Kernighan's article "Why Pascal Is Not My Favorite Programming Language, http://www.lysator.liu.se/c/bwk-on-pascal.html http://www.lysator.liu.se/c/bwk-on-pascal.html). Some of Pascal's faults were fixed in Modula and Oberon but those never got any traction. To be absolutely safe the language is either crippled so it's missing important features, or it requires a runtime to sandbox everything, check pointer references, do garbage collection, etc. And that slows things down. I don't see C going away any time soon in embedded software, which is where bugs and vulnerabilities can be most dangerous and where they are hardest to fix. It's not much of a disaster for a video game to crash, but it can be very bad if piece of hospital hardware or a flight control system has a latent bug. There are tools that can analyze C code both statically and dynamically -- the language is not just old, it's mature. I'm sure someone is already rewriting the Linux kernel and all of the Unix-y tools in Rust or Go or whatever. I won't hold my breath.

coldtea 12y ago
>Well, there's Go. Not for the things C is good for. OS work, drivers, common libs like OpenSSL callable from other apps, infrastructure work, etc. Besides Go is nothing new. There have been similar languages ever since 1970, and they are not replacing C.
- __Joker 12y ago
  Agree, better shout out would be Rust. Also referring the complete interview[1] which the TC article quotes, which seems to be favouring Rust. [1]. https://www.codementor.io/rust/tutorial/steve-klabnik-rust-vs-c-go-ocaml-erlang https://www.codementor.io/rust/tutorial/steve-klabnik-rust-v...
  - steveklabnik 12y ago
    Two things: First, I'm on the core team, so I obviously have bias. I try to remain as objective as possible at these things, but still. Second, that interview was from October. Not a lot has changed, really, but it is an eternity in Rust-time.
    - akulbe 12y ago
      Question for you, sir. When folks like you and the rest of the team set about making a new programming language, is it ever with the new programmer in mind? Or is your primary purpose to fix a shortcoming in another language, and as such, you're not really thinking of the beginners? The reason I ask is because I went to look at the docs for Rust, and they still seem incomplete. As someone on the outside looking in... I'd have a hard time recommending Rust over C, because the learning path isn't complete yet. C is extremely well-documented. I want to learn Rust, because it's the new hotness, but it seems difficult to do right now. That said, I'm very curious to hear your thoughts on this. Also, if you have advice on how best to learn Rust, I'd love to hear what you have to say on that. My professional experience has been almost entirely with scripting languages, and nothing more low-level than that.
      - steveklabnik 12y ago
        > is it ever with the new programmer in mind? New programming languages are almost never designed with the new programmer in mind. I've spent a _lot_ of time teaching people to program, and they all have really serious hurdles. There are some good projects in this space, but they're a very, very tiny minority. Don't underestimate how hard "Hello world" is, which is actually something that that PDF I linked points out. > they still seem incomplete. Can you elaborate on this, with specifics? It'd be really helpful.
        akulbe 12y ago
        I created a video with ScreenFlow. https://www.dropbox.com/s/vuax1ocki846llu/rust_example.mp4?dl=0 https://www.dropbox.com/s/vuax1ocki846llu/rust_example.mp4?d... Downloading and installing Rust, no problem. Then I tried doing the "Hello, World!" example. Pretty sure I had it typed right in vim. It didn't work. Then, I typed it in Sublime Text, it still didn't work. Then I thought, I forgot to set +x on the file, and I remember I hadn't set anything on the shebang line in the file, so I went on in the docs. As you can see... I got to the "Learn Rust" page, and it wasn't ready yet.
GolDDranks 12y ago
There's already some toy OSes written in Rust: http://scialex.github.io/reenix.pdf http://scialex.github.io/reenix.pdf I think Rust IS able to replace C, precisely for the same reason why Java and Go fail to do that: they have runtimes and they are garbage-collected. That means that you can't easily write a library in Java or Go and then call into that from another language without complicated interop and overhead. You can't write low-level code without headaches. Et cetera. Rust doesn't have a runtime, so it's like safe C++, for that matter.
- lloeki 12y ago
  > they have runtimes Go has as much a runtime as C or C++ [0]. [0]: http://en.wikipedia.org/wiki/Crt0 http://en.wikipedia.org/wiki/Crt0
  - yoklov 12y ago
    My understanding is you typically bootstrap the runtime for C/C++ when you write an OS. This is a significantly larger task for Go, to the point where I'd say it's probably infeasible (Is it possible to write the Go runtime in Go? Even the GC?).
  - dbaupp 12y ago
    I don't think that's really true? Certainly Go has a much weighter runtime than those. Neither C nor C++ implicitly insert context switches into the runtime into the generated code, nor do they have garbage collectors that scan the processes memory.
agumonkey 12y ago
> There's no perfect language. Reminds me of cultures. Differences between groups times themselves over the years and will mostly diverge from each others (not necessarily). Each linguistic specificity will lead to different idioms, libraries and landscape; also fitting to different domains. Some times, Lisps or algebra-based FP (in my inexperienced eyes it could lead to safier code too) makes me think there a way to reunite all this under the same roof though. ps: I agree with your post. Maybe language matters to a certain extent only; good system design is language agnostic.
Dewie3 12y ago
> There's no perfect language. > I'm sure someone is already rewriting the Linux kernel and all of the Unix-y tools in Rust or Go or whatever. I won't hold my breath. You're right, man. Nothing is perfect and we can't start with a blank slate so we might as well give up. http://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_solution_fallacy http://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_solutio...
- gregjor 12y ago
  Thanks for the link, and here's one for you: http://www.merriam-webster.com/dictionary/condescension http://www.merriam-webster.com/dictionary/condescension I neither believe nor wrote that if we can't start with a blank slate we might as well give up. Since I specialize in working with legacy code that's actually pretty much the opposite of what I do. What I meant by "I won't hold my breath" is that C has an enormous lead in maturity, programmers, and installed software base. Displacing it because a writer at TechCrunch thinks C sucks and Rust is better is a different kind of fallacy. I'd be happy to see a safer language that didn't sacrifice expressive power, performance, and memory footprint. Many, many candidates have been floated since C made its debut, so either they have all been found wanting, or the obstacles to moving beyond C are bigger than just inventing a safer language. That was my point.
  - Dewie3 12y ago
    I'll agree that the sentiment "death to C" is hyperbolic and unrealistic. A very, very long term phasing out is more realistic. :)

by gregjor 12y ago

coldtea 12y ago

>Well, there's Go. Not for the things C is good for. OS work, drivers, common libs like OpenSSL callable from other apps, infrastructure work, etc. Besides Go is nothing new. There have been similar languages ever since 1970, and they are not replacing C.

__Joker 12y ago
Agree, better shout out would be Rust. Also referring the complete interview[1] which the TC article quotes, which seems to be favouring Rust. [1]. https://www.codementor.io/rust/tutorial/steve-klabnik-rust-vs-c-go-ocaml-erlang https://www.codementor.io/rust/tutorial/steve-klabnik-rust-v...
- steveklabnik 12y ago
  Two things: First, I'm on the core team, so I obviously have bias. I try to remain as objective as possible at these things, but still. Second, that interview was from October. Not a lot has changed, really, but it is an eternity in Rust-time.
  - akulbe 12y ago
    Question for you, sir. When folks like you and the rest of the team set about making a new programming language, is it ever with the new programmer in mind? Or is your primary purpose to fix a shortcoming in another language, and as such, you're not really thinking of the beginners? The reason I ask is because I went to look at the docs for Rust, and they still seem incomplete. As someone on the outside looking in... I'd have a hard time recommending Rust over C, because the learning path isn't complete yet. C is extremely well-documented. I want to learn Rust, because it's the new hotness, but it seems difficult to do right now. That said, I'm very curious to hear your thoughts on this. Also, if you have advice on how best to learn Rust, I'd love to hear what you have to say on that. My professional experience has been almost entirely with scripting languages, and nothing more low-level than that.
    - steveklabnik 12y ago
      > is it ever with the new programmer in mind? New programming languages are almost never designed with the new programmer in mind. I've spent a _lot_ of time teaching people to program, and they all have really serious hurdles. There are some good projects in this space, but they're a very, very tiny minority. Don't underestimate how hard "Hello world" is, which is actually something that that PDF I linked points out. > they still seem incomplete. Can you elaborate on this, with specifics? It'd be really helpful.
      - akulbe 12y ago
        I created a video with ScreenFlow. https://www.dropbox.com/s/vuax1ocki846llu/rust_example.mp4?dl=0 https://www.dropbox.com/s/vuax1ocki846llu/rust_example.mp4?d... Downloading and installing Rust, no problem. Then I tried doing the "Hello, World!" example. Pretty sure I had it typed right in vim. It didn't work. Then, I typed it in Sublime Text, it still didn't work. Then I thought, I forgot to set +x on the file, and I remember I hadn't set anything on the shebang line in the file, so I went on in the docs. As you can see... I got to the "Learn Rust" page, and it wasn't ready yet.

GolDDranks 12y ago

There's already some toy OSes written in Rust: http://scialex.github.io/reenix.pdf http://scialex.github.io/reenix.pdf I think Rust IS able to replace C, precisely for the same reason why Java and Go fail to do that: they have runtimes and they are garbage-collected. That means that you can't easily write a library in Java or Go and then call into that from another language without complicated interop and overhead. You can't write low-level code without headaches. Et cetera. Rust doesn't have a runtime, so it's like safe C++, for that matter.

lloeki 12y ago
> they have runtimes Go has as much a runtime as C or C++ [0]. [0]: http://en.wikipedia.org/wiki/Crt0 http://en.wikipedia.org/wiki/Crt0
- yoklov 12y ago
  My understanding is you typically bootstrap the runtime for C/C++ when you write an OS. This is a significantly larger task for Go, to the point where I'd say it's probably infeasible (Is it possible to write the Go runtime in Go? Even the GC?).
- dbaupp 12y ago
  I don't think that's really true? Certainly Go has a much weighter runtime than those. Neither C nor C++ implicitly insert context switches into the runtime into the generated code, nor do they have garbage collectors that scan the processes memory.

agumonkey 12y ago

> There's no perfect language. Reminds me of cultures. Differences between groups times themselves over the years and will mostly diverge from each others (not necessarily). Each linguistic specificity will lead to different idioms, libraries and landscape; also fitting to different domains. Some times, Lisps or algebra-based FP (in my inexperienced eyes it could lead to safier code too) makes me think there a way to reunite all this under the same roof though. ps: I agree with your post. Maybe language matters to a certain extent only; good system design is language agnostic.

Dewie3 12y ago

> There's no perfect language. > I'm sure someone is already rewriting the Linux kernel and all of the Unix-y tools in Rust or Go or whatever. I won't hold my breath. You're right, man. Nothing is perfect and we can't start with a blank slate so we might as well give up. http://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_solution_fallacy http://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_solutio...

gregjor 12y ago
Thanks for the link, and here's one for you: http://www.merriam-webster.com/dictionary/condescension http://www.merriam-webster.com/dictionary/condescension I neither believe nor wrote that if we can't start with a blank slate we might as well give up. Since I specialize in working with legacy code that's actually pretty much the opposite of what I do. What I meant by "I won't hold my breath" is that C has an enormous lead in maturity, programmers, and installed software base. Displacing it because a writer at TechCrunch thinks C sucks and Rust is better is a different kind of fallacy. I'd be happy to see a safer language that didn't sacrifice expressive power, performance, and memory footprint. Many, many candidates have been floated since C made its debut, so either they have all been found wanting, or the obstacles to moving beyond C are bigger than just inventing a safer language. That was my point.
- Dewie3 12y ago
  I'll agree that the sentiment "death to C" is hyperbolic and unrealistic. A very, very long term phasing out is more realistic. :)