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.
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.