4 ms·

Go is easy, decently fast, and reasonably safe. It's a good tool for many problems. Rust is complex, extremely fast, and notably safer than Go. It sounds lik

by xedrac 4y ago

Go is easy, decently fast, and reasonably safe. It's a good tool for many problems. Rust is complex, extremely fast, and notably safer than Go. It sounds like Vale is trying to push the envelope of what is possible, which to me, means having a simple yet expressive, extremely fast, and extremely safe language. Go makes compromises in all of those areas (as do many other good languages). I'd argue that Go isn't really near the boundaries in any of those areas, so it's not surprising that they didn't use it as a comparison to illustrate those three aspects of a programming language. It seems Vale's goal is to have their cake and eat it too.

throwaway894345 4y ago
Agreed that Go trades off some performance and safety. I’m not sure what “easy” means exactly, but IMO Go has the shortest learning curves of any language whether “time to productivity” or “time to mastery” and it also has the fastest developer velocity IMO (and I’m coming from Python, which has that reputation as well). It seems like Go is at the boundary for anything worth calling “easy”.
- Gwypaas 4y ago
  People feel like they have a short learning curve and they master Go. Greenfield programming in Go is an amazingly empowering feeling. The issue is they don't see the issues they create until something implicit, a default value after a refactor or any of Go's paper cuts lead to a production issue. One central issue is that anything touching concurrency and Go is a tangle of nastiness with implicit effects. But apparently Go is "natively concurrent" and everyone simply prays that the race detector is good enough. https://eng.uber.com/data-race-patterns-in-go/ https://eng.uber.com/data-race-patterns-in-go/
  - throwaway894345 4y ago
    Yeah, Go doesn’t have top safety, but it lets you move a lot faster than safer languages. You can spend the extra time finding and fixing most of these bugs and still have time to spare compared to safer languages. Parallelism does need some design to avoid making a mess (minimize shared mutable state and lock what you can’t minimize and you’re fine). Note also that Rust and other safer languages don’t help much because most shared mutable state is remote and accessed by multiple application processes (e.g., an object in an S3 bucket, a file in an NFS volume, etc). With Rust or with Go, you need to test for these kinds of bugs, but with Go you’ll be able to start your testing sooner (with Rust you’d still be writing the app code).
foldr 4y ago
In what respects is Rust safer than Go? They are both memory safe, and both have safe concurrency options (in addition to unsafe ones).
- cwzwarich 4y ago
  Unless they've made a recent radical change, data races on multiword values (e.g. interfaces and slices) are unsafe in Go. In other GC languages (e.g. Java and C#), data races don't compromise memory safety, but Go made different implementation choices.
- tialaramex 4y ago
  As we saw in a recent back-and-forth you can come to believe Go is really safe by just having incredibly conservative expectations. If your expectations are low enough Go can meet those low expectations, and you may see a language like Rust as not adding anything since you'd never express anything that's safe (and perhaps faster) in Rust but would be unsafe in Go.
  - foldr 4y ago
    I’m sure you do have a substantive point to make, but all that you actually do in the text of your post is throw shade at Go programmers. I can’t find the back and forth to which you refer. I'm aware of the potential for data races to lead to data corruption in Go, although as an exploitable issue it seems a bit theoretical. There are also soundness bugs in Rust from time to time (as for example with the whole Pin saga).
    - tialaramex 4y ago
      > I can’t find the back and forth to which you refer. https://news.ycombinator.com/item?id=31703732 https://news.ycombinator.com/item?id=31703732 > I'm aware of the potential for data races to lead to data corruption in Go, although as an exploitable issue it seems a bit theoretical. Go's language design says it doesn't care about this problem, Rust's language says it eliminates this problem. If you see these as basically the same because you also don't care about the problem, it seems like your original claim (that they're both safe) was simply wrong. > There are also soundness bugs in Rust from time to time To be absolutely clear here: Data races in Go are not "bugs". Go is specifically designed not to even be safe if you have a data race which touches compound types. Undefined behaviour, you lose, game over, the language designers have nothing further to say on the matter. If you raise a ticket saying "I had this race and now everything is on fire" in Golang it will get a WONTFIX or whatever the equivalent is.

by xedrac 4y ago

throwaway894345 4y ago

Agreed that Go trades off some performance and safety. I’m not sure what “easy” means exactly, but IMO Go has the shortest learning curves of any language whether “time to productivity” or “time to mastery” and it also has the fastest developer velocity IMO (and I’m coming from Python, which has that reputation as well). It seems like Go is at the boundary for anything worth calling “easy”.

Gwypaas 4y ago
People feel like they have a short learning curve and they master Go. Greenfield programming in Go is an amazingly empowering feeling. The issue is they don't see the issues they create until something implicit, a default value after a refactor or any of Go's paper cuts lead to a production issue. One central issue is that anything touching concurrency and Go is a tangle of nastiness with implicit effects. But apparently Go is "natively concurrent" and everyone simply prays that the race detector is good enough. https://eng.uber.com/data-race-patterns-in-go/ https://eng.uber.com/data-race-patterns-in-go/
- throwaway894345 4y ago
  Yeah, Go doesn’t have top safety, but it lets you move a lot faster than safer languages. You can spend the extra time finding and fixing most of these bugs and still have time to spare compared to safer languages. Parallelism does need some design to avoid making a mess (minimize shared mutable state and lock what you can’t minimize and you’re fine). Note also that Rust and other safer languages don’t help much because most shared mutable state is remote and accessed by multiple application processes (e.g., an object in an S3 bucket, a file in an NFS volume, etc). With Rust or with Go, you need to test for these kinds of bugs, but with Go you’ll be able to start your testing sooner (with Rust you’d still be writing the app code).

foldr 4y ago

In what respects is Rust safer than Go? They are both memory safe, and both have safe concurrency options (in addition to unsafe ones).

cwzwarich 4y ago
Unless they've made a recent radical change, data races on multiword values (e.g. interfaces and slices) are unsafe in Go. In other GC languages (e.g. Java and C#), data races don't compromise memory safety, but Go made different implementation choices.
tialaramex 4y ago
As we saw in a recent back-and-forth you can come to believe Go is really safe by just having incredibly conservative expectations. If your expectations are low enough Go can meet those low expectations, and you may see a language like Rust as not adding anything since you'd never express anything that's safe (and perhaps faster) in Rust but would be unsafe in Go.
- foldr 4y ago
  I’m sure you do have a substantive point to make, but all that you actually do in the text of your post is throw shade at Go programmers. I can’t find the back and forth to which you refer. I'm aware of the potential for data races to lead to data corruption in Go, although as an exploitable issue it seems a bit theoretical. There are also soundness bugs in Rust from time to time (as for example with the whole Pin saga).
  - tialaramex 4y ago
    > I can’t find the back and forth to which you refer. https://news.ycombinator.com/item?id=31703732 https://news.ycombinator.com/item?id=31703732 > I'm aware of the potential for data races to lead to data corruption in Go, although as an exploitable issue it seems a bit theoretical. Go's language design says it doesn't care about this problem, Rust's language says it eliminates this problem. If you see these as basically the same because you also don't care about the problem, it seems like your original claim (that they're both safe) was simply wrong. > There are also soundness bugs in Rust from time to time To be absolutely clear here: Data races in Go are not "bugs". Go is specifically designed not to even be safe if you have a data race which touches compound types. Undefined behaviour, you lose, game over, the language designers have nothing further to say on the matter. If you raise a ticket saying "I had this race and now everything is on fire" in Golang it will get a WONTFIX or whatever the equivalent is.