Is it just me or does comparing go and rust make very little sense? Other than being popular and relatively new, they have almost nothing else in common. Rust is multi domain language design to be as versatile as possible, very intentionally limited with a set of carefully chosen constraints. Not intended to be particularly easy or quick to use, by design. Go is very clearly web-biased, centered for backend, microservices, not universal by design. Syntax very C like, verbose, feels low level, but actually batteries included. Really, the only thing in common with rust is that it is very popular with developers, but again for very different reasons. People who like rust often hate go and vice versa. You can tell by the comments in this thread too.
You can write in both languages software. They might have strengths and weakness for specific use cases, but that is a good reason to compare. So people learn these differences. I mean I compare Python to Rust in example when deciding in what language it should be. People want to learn only one language at a time, so it makes sense to compare them.
True. But I would argue it makes more sense comparing python to rust than go to rust. Scope of use cases for python is more similar to rust. Other than that - sure, you can compare Haskell and x86 assembly too, though it would be of little use.
In your initial reply you compared Rust to Go, funny enough. So people understand the differences and your opinion when to use which. And that’s the point.
Go is not even good. It’s horribly designed (or rather, un-designed, since its creators actually boasted about deliberately doing the core part in what? a couple of weeks IIRC). If it wasn’t for the associated corporate brand, it would have been a dead meme in the eyes of everyone by 2015 when Rust hit v1.0 (It was born a meme in the eyes of those who know).
And I mentioned that date to point out that we can’t call these languages new forever 😉 . In fact, if you took a snapshot of street tech talk from 10 years ago, you would see that these generic conventional unwisdom comparisons have been done to death already. Which then begs the question: what newfound “wisdom” needed to be added to these “muh best tool for the job” talking points? Or are we just testing the wisdom of our new best tool for all jobs, LLMs?
Totally agree. I still wonder how anyone even accepted this horrible mess as a backend language. Combine LLM + Go, the resulting code is a verbose vomit that I don’t want to cleanup.
I’m not proficient enough in Go to say how good or bad it is, but I have tried it in the past and it made and immediately not like it. Verbose syntax, no null safety or any error handling, no templates at that time, people literally copy/pasted the code of containers for different data types and did find/replace on it. The only feature that was kind of convenient is goroutines. For my money, Kotlin and even Java were more modern looking and would prefer them to go any day. Also not apples to apples comparison, but far more similar than rust.
Nah. There was space for simple (in a good way) native (no VM) GC languages to set between scripted (python) and VM(-first) languages (java) on one side, and no-GC languages on the other. Not doing OOP and not doing exceptions were good decisions as a starting point. But the problem is that this was based on following C (instead of C++) and nothing else, making no use of decades of programming language research and development*. And it’s the (un)design that followed that ended up creating a horrible simple (in a bad way) language. And this google-branded language hogged that space where other better languages could have been developed, or those which got developed could have flourished more and gained more momentum. And the corporate marketing actually tried to sell every bad design aspect as a “akshually a feature”. For example, lack of generics was celebrated for years as great simplicity, until an almost deliberately bad implementation of generics got added later as you mentioned.
tl;dr: The surface premise of the language was good and arguably needed at the time. What got delivered was bad.
* An observant historian would point out here that some good (arguably better even) languages predate C itself (e.g. the ML family).
I agree with everything. Compiled, GC language was weirdly missing. Also, I think that exceptions are not a particularly good error handling solution. But it’s weird to have a GC abstraction and goroutines built-in, yet not have support for any other abstraction for programmers. Just seems not well thought through language from the start.
Is it just me or does comparing go and rust make very little sense? Other than being popular and relatively new, they have almost nothing else in common. Rust is multi domain language design to be as versatile as possible, very intentionally limited with a set of carefully chosen constraints. Not intended to be particularly easy or quick to use, by design. Go is very clearly web-biased, centered for backend, microservices, not universal by design. Syntax very C like, verbose, feels low level, but actually batteries included. Really, the only thing in common with rust is that it is very popular with developers, but again for very different reasons. People who like rust often hate go and vice versa. You can tell by the comments in this thread too.
You can write in both languages software. They might have strengths and weakness for specific use cases, but that is a good reason to compare. So people learn these differences. I mean I compare Python to Rust in example when deciding in what language it should be. People want to learn only one language at a time, so it makes sense to compare them.
True. But I would argue it makes more sense comparing python to rust than go to rust. Scope of use cases for python is more similar to rust. Other than that - sure, you can compare Haskell and x86 assembly too, though it would be of little use.
In your initial reply you compared Rust to Go, funny enough. So people understand the differences and your opinion when to use which. And that’s the point.
Go is not even good. It’s horribly designed (or rather, un-designed, since its creators actually boasted about deliberately doing the core part in what? a couple of weeks IIRC). If it wasn’t for the associated corporate brand, it would have been a dead meme in the eyes of everyone by 2015 when Rust hit v1.0 (It was born a meme in the eyes of those who know).
And I mentioned that date to point out that we can’t call these languages new forever 😉 . In fact, if you took a snapshot of street tech talk from 10 years ago, you would see that these generic conventional unwisdom comparisons have been done to death already. Which then begs the question: what newfound “wisdom” needed to be added to these “muh best tool for the job” talking points? Or are we just testing the wisdom of our new best tool for all jobs, LLMs?
Totally agree. I still wonder how anyone even accepted this horrible mess as a backend language. Combine LLM + Go, the resulting code is a verbose vomit that I don’t want to cleanup.
I’m not proficient enough in Go to say how good or bad it is, but I have tried it in the past and it made and immediately not like it. Verbose syntax, no null safety or any error handling, no templates at that time, people literally copy/pasted the code of containers for different data types and did find/replace on it. The only feature that was kind of convenient is goroutines. For my money, Kotlin and even Java were more modern looking and would prefer them to go any day. Also not apples to apples comparison, but far more similar than rust.
Nah. There was space for simple (in a good way) native (no VM) GC languages to set between scripted (python) and VM(-first) languages (java) on one side, and no-GC languages on the other. Not doing OOP and not doing exceptions were good decisions as a starting point. But the problem is that this was based on following C (instead of C++) and nothing else, making no use of decades of programming language research and development*. And it’s the (un)design that followed that ended up creating a horrible simple (in a bad way) language. And this google-branded language hogged that space where other better languages could have been developed, or those which got developed could have flourished more and gained more momentum. And the corporate marketing actually tried to sell every bad design aspect as a “akshually a feature”. For example, lack of generics was celebrated for years as great simplicity, until an almost deliberately bad implementation of generics got added later as you mentioned.
tl;dr: The surface premise of the language was good and arguably needed at the time. What got delivered was bad.
* An observant historian would point out here that some good (arguably better even) languages predate C itself (e.g. the ML family).
I agree with everything. Compiled, GC language was weirdly missing. Also, I think that exceptions are not a particularly good error handling solution. But it’s weird to have a GC abstraction and goroutines built-in, yet not have support for any other abstraction for programmers. Just seems not well thought through language from the start.