3 ms·

I mean, Go and Java have those properties, but achieve them using managed runtimes. The first thing that crossed my mind reading this comment was Nim. It’s pr

I mean, Go and Java have those properties, but achieve them using managed runtimes. The first thing that crossed my mind reading this comment was Nim. It’s pretty Pythonesque (but that’s kinda what I hate about it.)

gwd 2y ago
I love Go, but it certainly doesn't have the safety guarantees that Rust has. You're not going to have a memory leak or use-after-free, due to the garbage collector, but you have nil pointer dereferences and data races.
- usrnm 2y ago
  I have seen more leaks in the golang project I currently work on than in most C++ codebases I've worked with in my career. It's trivial to leak stuff in golang, and much more difficult to make sure that you don't
  - binary132 2y ago
    Ok? Is it not trivial to leak in unsafe rust? Managed memory is safety. And frankly, OOM termination is not unsafe. If you crash the host because you ate all the system resources, that’s a different thing, and Rust doesn’t fix that either.
- pdimitar 2y ago
  And it's trivially easy to ignore an error. Also channels and WaitGroups are easy to misuse (well, that's why there's also an ErrGroup now). I'd make Golang my 100% go-to language if it got rid of several footguns. Though let's be real, that's absolutely certain to never happen, they take their backwards compatibility extremely seriously. So we'll have to keep relying on checkers and linters that alleviate some of the pains somewhat.
  - angra_mainyu 2y ago
    I'm not aware of any serious Go project without linting and tests. In fact, most projects I've worked on won't even merge a PR with ignored errors. Also, `go test -race` is a Go feature, there's nothing wrong with using it.
    - dgacmu 2y ago
      go test -race is awesome and everyone should use it. But it's worth remembering that it's a dynamic analysis that only covers access patterns created by your tests.
- angra_mainyu 2y ago
  Strange, I've worked on complex projects in the distributed space with Go and it's very easy to catch these things with `-race` and linters.
- binary132 2y ago
  nil dereference isn’t unsafe.
  - imtringued 2y ago
    It's undefined behaviour, which is even worse!
    - binary132 2y ago
      Nope. Nil deref in Go is checked, and simply panics, just like array access out of bounds.
- binary132 2y ago
  Also, data races in Go are trivially addressed using the common pipeline / CSP pattern, since channels are serializing. Of course, it doesn’t eliminate the possibility of doing stupid concurrency things, and you could of course argue that giving users trivially easy concurrency primitives encourages stupid concurrency, but I think it is fair to say that in most cases, Go idioms and primitives make race-free concurrency pretty easy. You have to go out of your way to write racy Go, and there’s nothing really preventing people from going out of their way to write unsafe Rust, either.

gwd 2y ago

I love Go, but it certainly doesn't have the safety guarantees that Rust has. You're not going to have a memory leak or use-after-free, due to the garbage collector, but you have nil pointer dereferences and data races.

usrnm 2y ago
I have seen more leaks in the golang project I currently work on than in most C++ codebases I've worked with in my career. It's trivial to leak stuff in golang, and much more difficult to make sure that you don't
- binary132 2y ago
  Ok? Is it not trivial to leak in unsafe rust? Managed memory is safety. And frankly, OOM termination is not unsafe. If you crash the host because you ate all the system resources, that’s a different thing, and Rust doesn’t fix that either.
pdimitar 2y ago
And it's trivially easy to ignore an error. Also channels and WaitGroups are easy to misuse (well, that's why there's also an ErrGroup now). I'd make Golang my 100% go-to language if it got rid of several footguns. Though let's be real, that's absolutely certain to never happen, they take their backwards compatibility extremely seriously. So we'll have to keep relying on checkers and linters that alleviate some of the pains somewhat.
- angra_mainyu 2y ago
  I'm not aware of any serious Go project without linting and tests. In fact, most projects I've worked on won't even merge a PR with ignored errors. Also, `go test -race` is a Go feature, there's nothing wrong with using it.
  - dgacmu 2y ago
    go test -race is awesome and everyone should use it. But it's worth remembering that it's a dynamic analysis that only covers access patterns created by your tests.
angra_mainyu 2y ago
Strange, I've worked on complex projects in the distributed space with Go and it's very easy to catch these things with `-race` and linters.
binary132 2y ago
nil dereference isn’t unsafe.
- imtringued 2y ago
  It's undefined behaviour, which is even worse!
  - binary132 2y ago
    Nope. Nil deref in Go is checked, and simply panics, just like array access out of bounds.
binary132 2y ago
Also, data races in Go are trivially addressed using the common pipeline / CSP pattern, since channels are serializing. Of course, it doesn’t eliminate the possibility of doing stupid concurrency things, and you could of course argue that giving users trivially easy concurrency primitives encourages stupid concurrency, but I think it is fair to say that in most cases, Go idioms and primitives make race-free concurrency pretty easy. You have to go out of your way to write racy Go, and there’s nothing really preventing people from going out of their way to write unsafe Rust, either.