Comment by ThanhMB4332 | Hacker News Reader

Comment by ThanhMB4332 | Hacker News Reader

Parent Full thread

Most importantly, like many articles and discussions regarding Rust, this article misses the point. It's not about high end language features. In 99% of the projects it's also not about computational performance (but latencies - memory, network, disc and scalability).

Success of our projects is ultimately shaped by the development process, the matureness and reliablity of the ecosystem (standard lib of Go) and ease of use of the tools, so you can focus on the problem to solve.

Besides of that: I haven't written much Rust, so I can only comment on the Go side:

I never heard of GVM (local env for Go) - probably because it's not needed. Just use Go modules. Really, no need to worry about GOPATH etc.

Regarding the conclusion:

Rust is ultimately faster and uses less resources, no dispute here. However, there're no benchmarks in the article. For the given CLI application, the result would very likely be: There's no performance difference.

However, Rust is not generally safer than Go. Rust is safer compared to other language with manual memory management (C/C++). Rust has a stronger typesystem, but that doesn't mean Rust programs can't panic too.

Rust can statically prove there are no data races, Go cannot.

Rust offers statically checked deterministic destruction, which makes handling non-memory resources much safer from leaks. Failing to dispose non-memory resources properly (e.g in databases) may be considered a correctness problem. Rust helps in this area, Go doesn't.

Does Go have anything even close to clap/structopt?

Yes, though unlike Rust they use reflection: https://github.com/alecthomas/kong (my own)

Thanks. Looks good. The reflections don't bother me (that's the way to go with in Go).

For cli apps it doesn't really matter if it's reflection-based

Rust is a bit safer.

- it warns you if you ignore an error. - it forces variables and fields to be initialized. - it has sum types and generics instead of interface{}. - it prevents some race conditions at compile time. - it pushes programmers towards immutability.

It doesn't only WARN about ignoring an error, it refuses to compile. T and Result<T, E> are different types.

The warning comes if you try to call a function for its side effects and ignore the return value. In most cases it’s fine, but ignoring a Result or a Future will issue a warning.

I've always wondered whether "unwrap"-ing is considered ignoring? I personally always equated it to ignoring if there's an error

I would say no, because it's not ignored. It makes it explode.

They also try to have aggressive defaults on integer wrapping and so on. I work with a junior who is writing a Go program who would have benefited from the early detection ;)

For a naive code solution, I found the default naive golang code to be better performing than Rust, when processing multiple files together (I/O-bound). I'd be careful assuming Rust is faster by default, as Go has some pretty sane defaults out of the box. The developer experience is faster, simpler and stabler(?) too, but really depend what you want to make. I find Rust interesting but haven't found the time/project to learn it properly on. Point being to avoid costs and risks of premature optimizations.

Often, slow file reading means that you didn't use a BufReader, and are making more system calls than you need to.

Tip: Rust BufReaders default to 8KiB buffers which are way too small for high-performance sequential NVME I/O.

GVM is really handy if you need to switch between go versions fast. I use it often at work and it's great for that. If you never do that, you don't need GVM.

Reply on news.ycombinator.com