I think I read somewhere that part of the motivation is that they won’t need a runtime to be installed to use it, but Go could fill that role as well of course.
But I think you said it yourself:
I know this is blasphemy, but why not Go? Why Rust? I love writing Rust CLIs
I guess they also prefer Rust to Go. I’d choose Rust over go for a CLI any day. Why do you say Rust wouldn’t be good in an “industrial setting”? I use Rust professionally and I don’t see any problems in that setting.
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.
I think I read somewhere that part of the motivation is that they won’t need a runtime to be installed to use it, but Go could fill that role as well of course.
But I think you said it yourself:
I guess they also prefer Rust to Go. I’d choose Rust over go for a CLI any day. Why do you say Rust wouldn’t be good in an “industrial setting”? I use Rust professionally and I don’t see any problems in that setting.
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