6 ms·

> Rust kind-of owns that space True. But it's a pretty small space to be in. And there are good reasons for that: a) The only correctness Rust can, mostly, gu

> Rust kind-of owns that space True. But it's a pretty small space to be in. And there are good reasons for that: a) The only correctness Rust can, mostly, guarantee, is that there won't be unexpected data races or memory bugs. While this is proudly announced often and loudly, it also isn't the most common problem in code...logic bugs...against which the rust compiler can do as little as any other language. b) Rust can only give these guarantees because it is ALOT more complex than C. That means harder to read, harder to write, harder to learn. And developer time matters. Alot. If I can already ship features, while my competition is still stuck in onboarding, it won't matter if my code has the odd memory bugs...those can be fixed...I will already have the market to myself.

rapsey 3y ago
> a) The only correctness Rust can, mostly, guarantee, is that there won't be unexpected data races or memory bugs. While this is proudly announced often and loudly, it also isn't the most common problem in code...logic bugs...against which the rust compiler can do as little as any other language. A powerful type system helps quite a lot with logic bugs actually.
- usrbinbash 3y ago
  > A strong type system helps quite a lot with logic bugs actually. A static type system does, and all the languages that Rust has to compete with in its space, have one.
  - rapsey 3y ago
    Go's type system is much less expressive and it has null pointers. An entire giant class of bugs.
    - usrbinbash 3y ago
      > Go's type system is much less expressive Please, do explain: what does "much less expressive" mean, in technical terms? What specific data modeling can I not do in Go, and what specific bugs can be caused by that? > and it has null pointers Yes, so? De-Referencing a null pointer in Go crashes the program, making the bug very obvious. Go made the choice to have null pointers (which do exist in silica), and avoid the complexity of languages who pretend that null pointers don't exist. It's a tradeoff, and a very good one at that.
      - herbstein 3y ago
        > What specific data modeling can I not do in Go You're getting into the Turing tar-pit. There's nothing you can do in Rust you can't also do in Go, technically. Hell, you can do it all in Brainfuck too, if you so desire. The big thing, though, is ADTs. Being able to say "the value is one of 3 possible values" is a lot easier than saying "here are three values, you should use the non-zero one".
        usrbinbash 3y ago
        > You're getting into the Turing tar-pit. I am fully aware of that. My question is, what specific technical problems are caused by Go not having {feature_goes_here}. > The big thing, though, is ADTs Except it isn't a big thing, because for the few use cases where an ADT is actually, really, really, REALLY required, they can be expressed in Go using existing language features. https://go.dev/doc/faq#variant_types https://go.dev/doc/faq#variant_types https://eli.thegreenplace.net/2018/go-and-algebraic-data-types/ https://eli.thegreenplace.net/2018/go-and-algebraic-data-typ... Quote: "It seems that Go can do just fine without adding variant types, due to the challenges mentioned in the beginning of the post and the ease with which the major use-cases can be implemented using existing language features." End Quote On the one hand, yes, this is more verbose. On the other hand, these use cases are simply not frequent enough to justify making the languages syntax and type system more complex. Again: Yes, Go lacks many features of other languages. That is on purpose. The language is made to be simple, as in "easy to learn, easy to read, easy to refactor, easy to generate, easy to maintain large bodies of code".
        EnergyAmy 3y ago
        That link shows the Go type system's lack of expressiveness. You have to manually include things like the default case. Rust's compiler will do exhaustiveness checking for you, and you can't just forget about it. Also, it's not about ADT's being required. They're preferred, and Go's type system suffers for their lack. Go is a living, breathing example of the blub paradox in action.
        3y ago

rapsey 3y ago

> a) The only correctness Rust can, mostly, guarantee, is that there won't be unexpected data races or memory bugs. While this is proudly announced often and loudly, it also isn't the most common problem in code...logic bugs...against which the rust compiler can do as little as any other language. A powerful type system helps quite a lot with logic bugs actually.

usrbinbash 3y ago
> A strong type system helps quite a lot with logic bugs actually. A static type system does, and all the languages that Rust has to compete with in its space, have one.
- rapsey 3y ago
  Go's type system is much less expressive and it has null pointers. An entire giant class of bugs.
  - usrbinbash 3y ago
    > Go's type system is much less expressive Please, do explain: what does "much less expressive" mean, in technical terms? What specific data modeling can I not do in Go, and what specific bugs can be caused by that? > and it has null pointers Yes, so? De-Referencing a null pointer in Go crashes the program, making the bug very obvious. Go made the choice to have null pointers (which do exist in silica), and avoid the complexity of languages who pretend that null pointers don't exist. It's a tradeoff, and a very good one at that.
    - herbstein 3y ago
      > What specific data modeling can I not do in Go You're getting into the Turing tar-pit. There's nothing you can do in Rust you can't also do in Go, technically. Hell, you can do it all in Brainfuck too, if you so desire. The big thing, though, is ADTs. Being able to say "the value is one of 3 possible values" is a lot easier than saying "here are three values, you should use the non-zero one".
      - usrbinbash 3y ago
        > You're getting into the Turing tar-pit. I am fully aware of that. My question is, what specific technical problems are caused by Go not having {feature_goes_here}. > The big thing, though, is ADTs Except it isn't a big thing, because for the few use cases where an ADT is actually, really, really, REALLY required, they can be expressed in Go using existing language features. https://go.dev/doc/faq#variant_types https://go.dev/doc/faq#variant_types https://eli.thegreenplace.net/2018/go-and-algebraic-data-types/ https://eli.thegreenplace.net/2018/go-and-algebraic-data-typ... Quote: "It seems that Go can do just fine without adding variant types, due to the challenges mentioned in the beginning of the post and the ease with which the major use-cases can be implemented using existing language features." End Quote On the one hand, yes, this is more verbose. On the other hand, these use cases are simply not frequent enough to justify making the languages syntax and type system more complex. Again: Yes, Go lacks many features of other languages. That is on purpose. The language is made to be simple, as in "easy to learn, easy to read, easy to refactor, easy to generate, easy to maintain large bodies of code".
        EnergyAmy 3y ago
        That link shows the Go type system's lack of expressiveness. You have to manually include things like the default case. Rust's compiler will do exhaustiveness checking for you, and you can't just forget about it. Also, it's not about ADT's being required. They're preferred, and Go's type system suffers for their lack. Go is a living, breathing example of the blub paradox in action.
        3y ago