> developing in Go requires much less time and effort
Show me the empirical evidence otherwise it's just an opinion.
I also have an opinion which is that Go and Rust are about equal in complexity.
Show me the empirical evidence otherwise it's just an opinion.
I also have an opinion which is that Go and Rust are about equal in complexity.
I don't think this is really a "citation needed" kind of discussion. This is basically how Rust is advocated--you do work to satisfy the borrow checker, but in return, you get a program which is both high-performance and safe. In Go, the safety cost is paid at runtime.
I also wouldn't ask for evidence that Rust is faster than Go at runtime. This is well known.
If it helps, think of the language ecosystem, including Go and Rust, as Pareto-efficient.
I'd say you pay for the complexity when you learn the language. Once satisfying the borrow checker becomes second nature, it feels just as fast to write as go (in my opinion, after switching from go to rust for most of my scratchpad code)
Really core stuff is nice to write in Rust. Parsers, core algorithms, that kind of thing.
However, I write a lot of code in Go that does stuff like glue together libraries, call APIs, etc. That stuff is really nice to use in Go.
I'd also say that when I need to use a library in Rust, it's a coin-flip whether the library has a straightforward interface, or whether it is some monster with tons of template parameters, or maybe even a bunch of macro rules that you are supposed to use. Go libraries tend to be much simpler to use than Rust libraries.
How about the code written for commercial purposes? As in "you have to write a service that satisfies business requirements and you have to finish by time T"
I will come to you with "the empirical evidence" as soon as I decide to write a paper on the topic.
Needless to say we both are entitled to our respective opinions and will have to live with that.