> And frankly, a lot of software I write is just boring, and Go does fine for a lot of that. I try Rust periodically for things, and romantically it feels like it's the closest language to "the future", but I think the future might still have a place for languages like Go.

It's not so much about being "boring" or not; Rust does just fine at writing boring code once you get familiar with the boilerplate patterns (Real-world experience has shown that Rust is not really at a disadvantage wrt. productivity or iteration speed).

There is a case for Golang and similar languages, but it has to do with software domains where there literally is no viable alternative to GC, such as when dealing with arbitrary, "spaghetti" reference graphs. Most programs aren't going to look like that though, and starting with Rust will yield a higher quality solution overall.

▲

Mawr 5 days ago | parent | next [-]

> (Real-world experience has shown that Rust is not really at a disadvantage wrt. productivity or iteration speed).

I don't believe that for a second. Even just going from Python to Go drops my productivity by maybe about 50%. Rust? Forget it.

Sure, if you have a project that demands correctness and high performance that requires tricky concurrency to achieve, something like Rust may make sense. Not for your run-of-the-mill programs though.

▲

Yoric 5 days ago | parent | next [-]

Hey, going from Rust to Go drops my productivity by maybe about 50% :)

But more seriously, yeah, Rust doesn't make sense for trivial programs. But these days, I write Python for a living, and it doesn't take long to stumble upon bugs that Rust would have trivially detected from within the comfort from my IDE.

▲

sophacles 5 days ago | parent | prev | next [-]

I believe your productivity drops as you say. I don't think it's inherent to the language though, at least not most of it. Rather it think it's a matter of familiarity and experience in each. When you're less practiced in a language, you're slower at it. I can write python fast, but im pretty slow at ruby. I've written a lot of python rust and go, and am about equally productive in them (although how that productivity is distributed through the dev cycle is different). It wasn't always this way, I was slow in each of them at first.

▲

brabel 4 days ago | parent [-]

Rust is objectively harder to write than Go (or any other GC-language) because it exposes more concerns for the programmer to take care of. With Rust, you must always ensure your program complies with the borrow checker's rules (which is what makes Rust memory-safe) which includes having to add lifetime annotations to your variables in many cases. Go just doesn't have any of that. You could argue Rust still has an advantage in that it prevents bugs that in Go you're free to write, but then what you're claiming is that this compensates for the extra work you have to do upfront in Rust. That's a difficult position to defend, though, because an experienced Go developer probably has internalized how to avoid those bugs and the cost of preventing them can be nearly negligible. I do agree that they will still make mistakes, and those can have a cost, but they may also be quite rare, or may not matter much most of the time depending on your domain. I think that's why most people seem to agree Rust is probably only advantageous where the cost of data races in production is higher than the cognitive cost (which translates into increased effort) on the programmer.

▲

sophacles 4 days ago | parent | next [-]

>Rust is objectively harder to write than Go (or any other GC-language) because it exposes more concerns for the programmer to take care of.

comparing apples to apples: Once you get a tiny bit of experience, almost all of that goes away. The common patterns and idioms in the language allow you to write whole programs without ever thinking about lifetimes or memory allocation or anything else different from the gc language case.

comparing apples to oranges: you do need to worry about those things when writing tricky memory management code that you couldn't even get from most gc lanuages... yeah then you have to worry about the things since it's a case where those things are the point.

> You could argue Rust still has an advantage in that it prevents bugs that in Go you're free to write, but then what you're claiming is that this compensates for the extra work you have to do upfront in Rust.

I have evidence in the form of multiple services and programs running in prod under heavy use for years without having to revist the code to deal with bugs. Meanwhile the stuff written in go has to be touched a lot to deal with bugs. The extra couple of weeks upfront to do it in rust is mitigated after the first incident with the go code. The effort proves worthwhile after the second incident.

Also tangentially related: the cost of an incident in the form of lost business, refunds, etc is usually far higher than the cost of a couple developer weeks.

>because an experienced Go developer probably has internalized how to avoid those bugs and the cost of preventing them can be nearly negligible

Some of them yes. But this is literally the same argument I'm making about rust experience meaning that you don't spend all that much extra effort up-front. Like I said, I'm about equally productive in go, python or rust.

> I think that's why most people seem to agree Rust is probably only advantageous where the cost of data races in production is higher than the cognitive cost (which translates into increased effort) on the programmer.

I think people who say this haven't gotten much experience in rust. In my experience they spent a week trying to learn rust and decided to stop and compare it to their years of other languages and paradigms.

▲

brabel 4 days ago | parent [-]

> I think people who say this haven't gotten much experience in rust. In my experience they spent a week trying to learn rust and decided to stop and compare it to their years of other languages and paradigms.

I have written Rust for around 6 years now.

	▲	sophacles 4 days ago \| parent [-]
		That doesn't say much about experience. Ive written ruby at a rate of a few dozen lines/year, for the 20 years. I guess I could say I've written ruby for 20 years... But someone full-time in ruby for only a year would likely be significantly better at the language than I am (i am bad at it).

▲

zozbot234 4 days ago | parent | prev [-]

> an experienced Go developer probably has internalized how to avoid those bugs and the cost of preventing them can be nearly negligible.

And an experienced Rust developer has internalized the patterns (such as cloning or ARC) that are needed to cope with the borrow checker while writing prototype-quality, quick-iteration code. What's easier, fixing hard-to-spot bugs in the code or getting that code to compile in the first place?

	▲	zelphirkalt 3 days ago \| parent [-]
		I am not a fan of Golang or the approach taken to designing it, but I will say, that writing code in a certain way may even have zero cost, because after some time it may be natural to write code that way to someone. For example this works for programming paradigms. I am just as familiar with FP as with OOP and when writing FP code I avoid mutation. Does that make my code writing slower? Only in so far as a problem inherently is or is not more difficult to solve without mutation.

▲

Ar-Curunir 4 days ago | parent | prev | next [-]

I am much more productive with Rust than any other programming language, except maybe python for programs shorter than 100 lines. Does that mean every other language has terrible productivity? No, it just means that I am more experienced with Rust. In general, experienced rust devs tend to be as efficient with Rust as other devs with other languages. There’s even Google data corroborating that internally Rust teams are as productive as Go teams

▲

ralfj 4 days ago | parent | prev [-]

See https://www.youtube.com/watch?v=QrrH2lcl9ew for a a presentation of Google's study, which found no measurable difference in productivity between teams using Rust vs Go.

▲

jchw 5 days ago | parent | prev [-]

Rust can yield a higher quality solution, but we can't make a perfect solution, we can only approach perfection. If we want to go further, we could introduce formally-proven code, too. Personally I'm interested in the intersection of proof assistants and Rust, like creusot-rs, and have been investigating it.

But as much as I love LARPing about correctness (believe me I do,) it's just simply the case that we won't right perfect software and it's totally OK. It's totally OK that our software will have artificial limitations, like with Go, only accepting filenames that are valid UTF-8, or taking some unnecessary performance/latency hits, or perhaps even crashing in some weird ass edge case. There are very few domains in which correctness issues can't be tolerated.

I don't deal with domains that are truly mission critical, where people could die if the code is incorrect. At worst, people could lose some money if my code is incorrect. I still would prefer not to cause that to happen, but those people are generally OK with taking that risk if it means getting features faster.

That's why Go has a future really. It's because for most software, some correctness issues are not the end of the world, and so you can rely on not fully sound approaches to finding bugs, like automated testing, race detection, and so on.

Rust can also make some types of software more productive to write, but it is unlikely to beat Go in terms of productivity when it comes to a lot of the stuff SaaS shops deal with. And boy, the software industry sure is swamped in fucking SaaS.

▲

sophacles 5 days ago | parent | next [-]

A lot of sass people i know are more and more choosing rust for boring code. This includes several people who said things like "go is good enough, i don't want to deal with all the rust completely".

Once your sass products get enough users, and you're dealing with millions or billions of requests per day, those rare bugs start showing up quite often... And it turns out programming towards correctness is desirable, if for no other reason than to keep pagerduty quiet. Tolerating correctness issues isn't cost-free... People having to respond during off hours costs money and stress. I think most people would rather pay the costs at dev time, when they aren't under the pressure of an incident, than during an outage.

	▲	jchw 5 days ago \| parent \| next [-]
		But correctness is not binary, it's more like a multidimensional spectrum. Your choice of programming language has some influence, as does standards and conventions, the ecosystem of your programming language, use of automated tooling like linting and testing, or even just ol' unreliable, discipline. Being a relatively greenfield language, Go is not in a terrible place when it comes to most of those things. Tons of automated tooling, including tools like the Checklocks analyzer or the many tools bundled with golangci-lint. Uber has done a pretty good job enumerating the challenges that remain, and even working at improving those issues too, such as with NilAway. The question isn't "wouldn't you prefer more correctness?" it's "how much would you pay for how much of an improvement in correctness?". Rust is still growing rapidly though, whereas Go is probably not growing rapidly anymore, I think Go has at least saturated it's own niche more than 50% and is on the other end of the curve by now. Last I checked Rust is the trendiest language by far, the one that people most wish they were writing, and the one that you want to be able to say your project is written in. So it would be extremely surprising to hear if there wasn't a growing Rust presence basically everywhere, SaaS's included.
	▲	lossolo 4 days ago \| parent \| prev \| next [-]
		> A lot of sass people i know are more and more choosing rust for boring code It seems like you're in some kind of bubble, especially when looking at Rust usage in the industry. > Once your sass products get enough users, and you're dealing with millions or billions of requests per day, those rare bugs start showing up quite often... This is a blanket statement that's simply not true and I'm speaking as someone who uses Go in the exact scenario you described. What kind of bugs are actually happening to these people? Do you have any real-world examples of the issues you're referring to, ones that suddenly start occurring only at the scale of millions or billions of requests per day to them?
	▲	zozbot234 5 days ago \| parent \| prev [-]
		This is also in line with everything we know about good software engineering. Putting out fires in production is extremely costly, hence potential issues should be addressed at the earliest feasible stage.

▲

josephg 5 days ago | parent | prev [-]

> Rust can also make some types of software more productive to write, but it is unlikely to beat Go in terms of productivity when it comes to a lot of the stuff SaaS shops deal with. And boy, the software industry sure is swamped in fucking SaaS.

I just wish Go supported parametric enums (sum types) and Option, rather than copying Hoare’s billion dollar mistake.

I ported some code to Go and rust a few years ago to try both languages out. The rust code ended up being 30% smaller because I could use an enum and a match expression. In Go I needed to make a set of types and interface{} to achieve the same thing - which was both slower and way more verbose. My rust implementation was as fast as my C implementation in 2/3rds as much code. And it was trivial to debug. My Go implementation took way more code to write - about the same amount of code as C, but it was harder to read than C and ran much slower.

For cookie cutter SAAS and prototypes, I prefer typescript. It’s fast enough for most things, and the type system is much more expressive without getting in your way. Not as convenient to deploy as go - especially on mobile. And the standard library is more like an attic. But in my opinion it’s a much better designed language.

	▲	Philpax 4 days ago \| parent [-]
		You're not the only one who wishes Go was just a bit more like Rust: https://github.com/borgo-lang/borgo Sadly, that project seems to be dead, but I hope someone picks up its mantle some day. A marginally better Go could, well, go far.