Go is a simpler-to-read language that does not involve lifetimes (as you know, it is GC’d). For a lot of smaller projects like this, the boringness of Go is preferred. Less mental bandwidth required.
I’ll admit my definition of “industrial” here was vague, but I think you can get my point. I’m not trying to say that Rust isn’t good in a business setting - my job also has Rust in the code!
However, for these purposes, most of the benefits of Rust in this situation are already provided by Go.
I don’t agree go is simpler to read. It is simpler to learn the syntax but the syntax is only part of what makes a language. Having learnt both, and having spent more time actually writing go I still prefer writing rust and finding it far easier to work with then go. Go has too many hidden gotchas that you need to trip up on to learn and then remember forever or else trip up on them again.
I agree here. I always find it difficult to navigate a Go codebase, especially when public members just seem to magically exist as opposed to being explicitly imported.
@solardirus@SorteKanin Maybe Go is easier to read in a word-for-word sense, but when I read a program, I want to understand what it does and why it works the way it works. I want to validate its properties to build a mental model of how pieces interact.
As soon as I start doing that I find Rust is much easier to reason about, because the compiler enforces a lot of properties that I rely on, whereas with Go I end up looking through multiple files to get the same picture.
@solardirus I find the situation to be the opposite, you need more mental bandwidth to navigate a go codebase. The signal to noise ratio is very poor because of badly designed error handling, poor libraries at some domains and lack of some modern goodies on programming languages making you having to reinvent the wheel every time.
Also, you rarely have to explicitly specify lifetimes.
Go is a simpler-to-read language that does not involve lifetimes (as you know, it is GC’d). For a lot of smaller projects like this, the boringness of Go is preferred. Less mental bandwidth required.
I’ll admit my definition of “industrial” here was vague, but I think you can get my point. I’m not trying to say that Rust isn’t good in a business setting - my job also has Rust in the code!
However, for these purposes, most of the benefits of Rust in this situation are already provided by Go.
I don’t agree go is simpler to read. It is simpler to learn the syntax but the syntax is only part of what makes a language. Having learnt both, and having spent more time actually writing go I still prefer writing rust and finding it far easier to work with then go. Go has too many hidden gotchas that you need to trip up on to learn and then remember forever or else trip up on them again.
I agree here. I always find it difficult to navigate a Go codebase, especially when public members just seem to magically exist as opposed to being explicitly imported.
@solardirus @SorteKanin Maybe Go is easier to read in a word-for-word sense, but when I read a program, I want to understand what it does and why it works the way it works. I want to validate its properties to build a mental model of how pieces interact.
As soon as I start doing that I find Rust is much easier to reason about, because the compiler enforces a lot of properties that I rely on, whereas with Go I end up looking through multiple files to get the same picture.
@solardirus I find the situation to be the opposite, you need more mental bandwidth to navigate a go codebase. The signal to noise ratio is very poor because of badly designed error handling, poor libraries at some domains and lack of some modern goodies on programming languages making you having to reinvent the wheel every time.
Also, you rarely have to explicitly specify lifetimes.
@SorteKanin