6 ms·

Rust is the more elegant and powerful language. Creating a new language and repeating the "billion dollar mistake" by including null (sailing under the brand na

Rust is the more elegant and powerful language. Creating a new language and repeating the "billion dollar mistake" by including null (sailing under the brand name "nil" in Go) is just crazy. Error handling is another strange thing in Go. And generics have been only introduced recently, but there is hardly any support for libraries in it (now). While Go is definitely fast enough for most scenarios, it is not the best language for low level code like drivers or kernel development. So, depending on your goals, I think Rust is the better language in general. But if your goal is to get something done fast, then Go would probably be better, since it doesn't require that much learning effort.

lpapez 4y ago
While Go is definitely fast enough for most scenarios, it is not the best language for low level code like drivers or kernel development. Go was never ever intended for this purpose.
- cryptos 4y ago
  Yes, I know (although they promoted it as a "systems language", but it was not really defined what that should mean in the beginning), but it is a restriction, you don't have in Rust. Basically, Rust can do everything Go can do, but not the other way around. That _might_ help to make a decision for a language.
  - stavros 4y ago
    Technically, assembly can do everything Rust can do, yet that doesn't help to make a decision for a language. Ergonomics matter.
  - agumonkey 4y ago
    It seems to be an idiom shift. Systems means connected parts, go concurrency does just that, connecting parts through channels. But it's not `systems` as in bare metal electronic chips systems. More like IT `system`.
mmarq 4y ago
> Creating a new language and repeating the "billion dollar mistake" by including null (sailing under the brand name "nil" in Go) is just crazy. You forgot pointers used to represent nullables.
nailer 4y ago
> Creating a new language and repeating the "billion dollar mistake" by including null (sailing under the brand name "nil" in Go) is just crazy. Can you explain? What do I set ‘score’ to when someone hasn’t sat the test yet?
- davidatbu 4y ago
  The Billion Dollar Mistake refers to the fact that things that are not explicitly marked as "nullable" can be null/nil. In rust, you would annotate score as `Option<u32>` (`u32` is one of Rust's integer types), and then you would set the score of someone who hasn't sat the test yet as `None`, and someone who got a 100 on the test as `Some(100)`.
  - nailer 4y ago
    Oh yeah, allowing values to be nullable by default is bad, that's totally different than just 'including null'. I thought they meant including null in the language! > you would set the score of someone who hasn't sat the test yet as `None` Yep that's what I expected. Emoji thumbs up.
    - dannymi 4y ago
      >Oh yeah, allowing values to be nullable by default is bad, that's totally different than just 'including null'. In Rust (and Haskell and OCaml for that matter), there is no built-in null keyword. Option is just an enum in the library that happens to have a variant called None. So it's technically Option::None and Option::Some(x). But, really, it could be Quux and Quux::Bla and Quux::Boo(x) instead--without any language changes. That is vastly better that what IntelliJ does for Java with their weird @NonNull annotations on references--which technically still can be the null. null is still a keyword there, and null is somehow a member of every reference type (but not of the other types--how arbitrary). And C# has a null keyword, and the rules for type autoconverting it are complicated, and some things you just aren't allowed to do with null (even though they should be possible according to the rules) because then you'd see what mess they made there (you'd otherwise be able to figure out what the type of null is--and there's no "the" type there. null is basically still a member of every type. And that is bad). So even the language used in "allowing values to be nullable by default" is insinuating a bad idea. Nullability is not necessarily a property that needs to exist on values in the first place (as far as the programming language is concerned).

lpapez 4y ago

While Go is definitely fast enough for most scenarios, it is not the best language for low level code like drivers or kernel development. Go was never ever intended for this purpose.

cryptos 4y ago
Yes, I know (although they promoted it as a "systems language", but it was not really defined what that should mean in the beginning), but it is a restriction, you don't have in Rust. Basically, Rust can do everything Go can do, but not the other way around. That _might_ help to make a decision for a language.
- stavros 4y ago
  Technically, assembly can do everything Rust can do, yet that doesn't help to make a decision for a language. Ergonomics matter.
- agumonkey 4y ago
  It seems to be an idiom shift. Systems means connected parts, go concurrency does just that, connecting parts through channels. But it's not `systems` as in bare metal electronic chips systems. More like IT `system`.

mmarq 4y ago

> Creating a new language and repeating the "billion dollar mistake" by including null (sailing under the brand name "nil" in Go) is just crazy. You forgot pointers used to represent nullables.

nailer 4y ago

> Creating a new language and repeating the "billion dollar mistake" by including null (sailing under the brand name "nil" in Go) is just crazy. Can you explain? What do I set ‘score’ to when someone hasn’t sat the test yet?

davidatbu 4y ago
The Billion Dollar Mistake refers to the fact that things that are not explicitly marked as "nullable" can be null/nil. In rust, you would annotate score as `Option<u32>` (`u32` is one of Rust's integer types), and then you would set the score of someone who hasn't sat the test yet as `None`, and someone who got a 100 on the test as `Some(100)`.
- nailer 4y ago
  Oh yeah, allowing values to be nullable by default is bad, that's totally different than just 'including null'. I thought they meant including null in the language! > you would set the score of someone who hasn't sat the test yet as `None` Yep that's what I expected. Emoji thumbs up.
  - dannymi 4y ago
    >Oh yeah, allowing values to be nullable by default is bad, that's totally different than just 'including null'. In Rust (and Haskell and OCaml for that matter), there is no built-in null keyword. Option is just an enum in the library that happens to have a variant called None. So it's technically Option::None and Option::Some(x). But, really, it could be Quux and Quux::Bla and Quux::Boo(x) instead--without any language changes. That is vastly better that what IntelliJ does for Java with their weird @NonNull annotations on references--which technically still can be the null. null is still a keyword there, and null is somehow a member of every reference type (but not of the other types--how arbitrary). And C# has a null keyword, and the rules for type autoconverting it are complicated, and some things you just aren't allowed to do with null (even though they should be possible according to the rules) because then you'd see what mess they made there (you'd otherwise be able to figure out what the type of null is--and there's no "the" type there. null is basically still a member of every type. And that is bad). So even the language used in "allowing values to be nullable by default" is insinuating a bad idea. Nullability is not necessarily a property that needs to exist on values in the first place (as far as the programming language is concerned).