Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Go Is Not Good (2014)

yager.io

Post reply on HN
Print view View original

211–220 of 466 posts

Re: Why Go Is Not Good (2014)

#211

Post by tjholowaychuk »

I think this post neglects the fact that one of Go's biggest strengths has almost nothing to do with the language. A huge portion of every-day logic is implemented very well, and very consistently in the stdlib.

Personally I don't want to go pick through half-baked third-party packages, mix and match concurrency models or GC. I have experienced enough of that in Node and it's not pretty. Having it all consistently implemented in the stdlib is a great feature.

Go not being cute was also something I found attractive, I'm not particularly worried about how much I type, because typing has never been a bottleneck. I prefer that code is easy to comprehend. My biggest problem with Go as a language is the arbitrary nature of some aspects when it comes to assignability etc.

When Rust or Haskell can say the same I'll definitely invest in them but until then it's just not a problem. I don't think it's about one language being academically better than the other, it's what is best right now for the job you're doing. I want those languages to do well of course, more options the better, but for now Go ticks the right boxes for a lot of people.

Re: Why Go Is Not Good (2014)

#212

Post by vvanders »

Veedrac wrote: post #47
pmilot wrote: post #12

I like this article and I agree with most of what was said there. Against that type of point-by-point criticism, fans of a language will usually use the argument: "but that language was not designed for that!". Then the question becomes: What was that language designed for? My impression was that Go was meant to be a slightly higher-level systems language with better constructs for concurrent programming. With that i…

I can't really see a world in which Rust is a "better Go". Rust is one of the more complex languages in existence, largely because it competes with C++ and thus can't afford to lose many features nor do many things the easy way. Go is one of the simplest languages in existence. It's on the other side of the charts.

Rust has many things that C++ doesn't have, and that's a good thing.

I think you might want to spend a bit more time with Rust before considering it just another C++.

Re: Why Go Is Not Good (2014)

#213

Post by wyager »

Veedrac wrote: post #47
pmilot wrote: post #12

I like this article and I agree with most of what was said there. Against that type of point-by-point criticism, fans of a language will usually use the argument: "but that language was not designed for that!". Then the question becomes: What was that language designed for? My impression was that Go was meant to be a slightly higher-level systems language with better constructs for concurrent programming. With that i…

I can't really see a world in which Rust is a "better Go". Rust is one of the more complex languages in existence, largely because it competes with C++ and thus can't afford to lose many features nor do many things the easy way. Go is one of the simplest languages in existence. It's on the other side of the charts.

> Go is one of the simplest languages in existence.

By what metric?

I can think of a lot of simpler languages. Lua, C, Forth, all the theoretical dead-simple combinator languages you don't want to use (Lambda Calculus, SKI calculus, etc.), etc...

Re: Why Go Is Not Good (2014)

#214

Post by x1024 »

pkulak wrote: post #161
hbex5 wrote: post #8

Earlier quoted context omitted.

Any critique of Go seems to be met with angry pitchforks in this place. As you say, the Go developers seem to have developed a kind of bunker mentality where they interpret legitimate criticisms of the language design as personal attacks, and respond by wearing Go's shortcomings as a badge of honour. It's not, I think, entirely healthy.

I think everyone who uses Go for anything is pretty clear about why they like it, and one of the major reasons is simplicity. So why are people then surprised when criticisms over lack of features fall on deaf ears? And to be honest, this whole argument about pitchforks seems like a straw man. If anything, it's currently fashionable to dump on Go at every opportunity. Hell, it's fashionable to dump on everything arou…

No, I've talked to Go people and they really do respond that way. Maybe my opinion is just one data point, but this entire thread seems to agree...

Re: Why Go Is Not Good (2014)

#215

Post by x1024 »

tjholowaychuk wrote: post #211

I think this post neglects the fact that one of Go's biggest strengths has almost nothing to do with the language. A huge portion of every-day logic is implemented very well, and very consistently in the stdlib. Personally I don't want to go pick through half-baked third-party packages, mix and match concurrency models or GC. I have experienced enough of that in Node and it's not pretty. Having it all consistently im…

But... Python already exists? Sorry to go all old-school on you, but the quality of Python's stdlib has literally been a part of pop culture for more than half a decade: https://xkcd.com/353/

Re: Why Go Is Not Good (2014)

#216

Post by thegeekpirate »

cmrdporcupine wrote: post #9
fixermark wrote: post #6

"Go does not support operator overloading or keyword extensibility." Very much working as intended, I believe. Experience from languages that support those features has shown that what we gain in the very few situations where those extensions make sense (such as defining mathematical operations on vectors using the same symbols that are used in vector mathematics), we lose in too many developers thinking they have a…

I agree that operator overloading is probably a feature not wanted in a language with this target problem domain. However "working as intended" I think is also the response of Go to their lack-of-generics, which I think is kind of crap.

> However "working as intended" I think is also the response of Go to their lack-of-generics, which I think is kind of crap.

Where the hell did you get that from?

https://news.ycombinator.com/item?id=9622417

Re: Why Go Is Not Good (2014)

#217

Post by Zikes »

mike_hearn wrote: post #196
Zikes wrote: post #87

I like Go. It's fun, it's fast, and it's introduced me to a lot of programming concepts I had never used before. The one thing that seems to be missing from these discussions is that Go fits in an unexpected niche. I come from a web development background. I grew up on Perl, ASP, PHP, and Javascript. I dabbled a bit in C in college, but I always felt like I was fighting to avoid shooting myself in the foot with it. F…

I think the main question then is, why don't you take a look at more modern languages than Go and see if you have the same experience (fun, fast, introduces to new programming concepts)? You could start by checking out https://kotlinlang.org/ - it targets the JVM so the tools are much better than what Go has and the library ecosystem is much larger. The language is a straightforward imperative style language that wil…

That's a bit of a slippery slope, though, isn't it? I'm already doing everything I want to do with Go, so all of the things it's "missing" don't really matter to me. If we had to learn and switch languages every time something implemented a feature the other did not have, we'd be refactoring our code every other week, wouldn't we?

That's not to say those other languages don't interest me, or that I would eschew learning for the sake of learning. I've been eyeballing Rust for a while, and I do think it may someday fill the role Go currently fills for me, but for the type of coding I currently do Go is more than sufficient.

Re: Why Go Is Not Good (2014)

#219

Post by 15155 »

trimbo wrote: post #154
Kapura wrote: post #108

Earlier quoted context omitted.

Certainly Go lacks some features (generics) which are more-or-less standard in other large languages, but I think that's a sacrifice to the code quality gods (not that you can't write shit code in Go). To use another metaphor: if C++ and Java are motorcycles, Go is more like a bicycle. Smaller, easier to maintain, and more portable, but there are times when you might really wish you had a motor.

> easier to maintain How do we know this? Has anyone written enough Go in an environment with a lot of engineers to make that determination?

I think a common sense standpoint would actually prove the opposite for some facts of Go: tons of unnecessary duplication due to a lack of generics is bound to lead to bugs, hard-to-maintain code due to sheer volume.

Re: Why Go Is Not Good (2014)

#220

Post by wyager »

fideloper wrote: post #28

Most of these arguments seem to be arguments between the pragmatism vs purity camps. I've switched between these camps before, and the lesson I've taken away is to use each when needed. (Altho I personally err on the pragmatic).

I believe you are incorrectly conflating pragmatism with monotony.

I've found Haskell to be very pragmatic, once I learned how to apply it. I haven't re-visited Rust in a while, but I expect to use it very pragmatically once it matures and people start developing Rust tooling for embedded work.

Post reply on HN