Golang absolutely has a faster development cycle than Rust. Unless you’re a Rust expert who never touches Go, but then it’s an issue of familiarity. Go devs hit the ground running and the ergonomics are streamlined, and the borrow checker and other rust restrictions don’t get in the way.

Given my downvotes you seem to be with the consensus on this one. I had 30 years of c++ development going into rust and I never found myself fighting the borrow checker. Golang seemed the same, just started coding and stuff worked mostly. But, the complexity of rust was familar coming from c++ with generics and macros but without some of the footguns, so it just seemed like power, not clutter.

I like go, but I wouldn't prototype in it, I'd pick julia or python. And if I'm familiar with the problem and want to code for production, rust really doesn't seem any slower to develop in than go to me and perhaps a bit less verbose. But in retrospect I think that is because of the direction I came at rust from means my habitual coding style lined up more closely with what rust expects. Its not a harder coding mindset, just a different one than someone who came from java would be used to.

30 years of C++ development experience means you aren't going to find any PL difficult and therefore your views on easy/difficult a PL is to learn and get going cannot be taken seriously. :)

While my overinflated ego enjoys your assessment, I want to reiterate that the patterns that minimize friction with the borrow checker aren't harder than standard patterns you'd see in garbage collected OOP or Functional focused languages, just different. Anecdotally here on HN it seems like people who came from ocaml or f# find rust even easier to adapt to than c++ people.

30 years of C++ can inoculate you to the idea of hideous amounts of boilerplate, or worrying about memory allocation timelines and such. I'm a 25 year C++ veteran myself.

I recently wrote an asynchronous microservice in C++, because it needed to use a C++ library I'd already written. Took about two weeks of effort, and clocked in at 1500 loc, not counting tests or the half-dozen external dependencies. I rewrote it in 100 lines of idiomatic Go using nothing except the standard library a few days ago. That's a 10x reduction in both lines of code and development time, although it's a bit unfair because I had already done the C++ version first. That is after giving up on a Rust version that was already weighing in at ~1000 LOC in an unfinished state.

After this experience, I don't think I'd ever use C++ or Rust again for a concurrent web service, unless there was hard real-time latency requirements. Golang is just so much better streamlined for that application, and the standard library is batteries included.

Go was designed from the ground up for that sort of thing, so that makes sense. And anecdotally asymc/await is a pain in rust. I've only used rust async through other libraries, and not that very often. I usually use plain threads.

Yeah Rust supports the same concurrency primitives as Go, but man are they a pain to use by comparison. With Go it is as trivial as using built-in keywords to spawn and merge lightweight threads, and the lightweight thread is the default mode of execution when main is invoked. Structs automatically serialize to JSON. The standard library’s HTTP server is fast, concurrent, and safe for use in production. Summed together that makes use case like mine a breeze to implement in Go.

But yeah, if I was writing an embedded firmware or something I would absolutely prefer Rust.

I use it for numeric heavy stuff and I'm going through tonic for any service connections. That abstracts me from any async wierdness and for the dsp code I don't care about lightweight threads. I don't want many/any more threads than I will have cores.