Live data from Hacker News

Go's Sweet 16

go.dev

51–60 of 280 posts

Re: Go's Sweet 16

#51
Oh wow, so it's already been 16 years since Google steamrolled the Go! language, which had existed a decade before Go and had every right to the name. This was when they were still pretending "do no evil" was their brand.

There may be no honor amongst thieves but there is honor amongst langdevs, and when they did Go! dirty, Google made clear which one they are.

Status changed to Unfortunate

https://github.com/golang/go/issues/9#issuecomment-66047478

Re: Go's Sweet 16

#52

I know they say that your programming language isn't the bottleneck, but I remember sitting there being frustrated as a young dev that I couldn't parse faster in the languages I was using when I learned about Go. It took a few more years before I actually got around to learning it and I have to say I've never picked up a language so quickly. (Which makes sense, it's got the smallest language spec of any of them) I'm…

Well that's good, since Go was specifically designed for juniors. From Rob Pike himself: "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical." However, the main design goal was to reduc…

Doesn't Google use mostly C++?

Re: Go's Sweet 16

#53
I'm glad Go exists. If nothing else, it cemented that tooling is at least as important as the language.

Re: Go's Sweet 16

#54
post #52

Earlier quoted context omitted.

Well that's good, since Go was specifically designed for juniors. From Rob Pike himself: "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical." However, the main design goal was to reduc…

Doesn't Google use mostly C++?

Just because it was a design goal doesn't mean it succeeded ;)

From Russ Cox this time: "Q. What language do you think Go is trying to displace? ... One of the surprises for me has been the variety of languages that new Go programmers used to use. When we launched, we were trying to explain Go to C++ programmers, but many of the programmers Go has attracted have come from more dynamic languages like Python or Ruby."

https://research.swtch.com/gotour

Re: Go's Sweet 16

#55

I know they say that your programming language isn't the bottleneck, but I remember sitting there being frustrated as a young dev that I couldn't parse faster in the languages I was using when I learned about Go. It took a few more years before I actually got around to learning it and I have to say I've never picked up a language so quickly. (Which makes sense, it's got the smallest language spec of any of them) I'm…

I write a lot of Go, a bit of Rust, and Zig is slowly creeping in. To add to the above comment, a lot of what Go does encourages readability... Yes it feels pedantic at moments (error handling), but those cultural, and stylistic elements that seem painful to write make reading better. Portable binaries are a blessing, fast compile times, and the choices made around 3rd party libraries and vendoring are all just icing…

Error handling isn't even a pain to write any more with AI autocomplete which gets it right 95%+ of the time in my experience.

Re: Go's Sweet 16

#56
post #39

Earlier quoted context omitted.

The nice thing about Go is that you can learn "all of it" in a reasonable amount of time: gotchas, concurrency stuff, everything. There is something very comforting about knowing the entire spec of a language. I'm convinced no more than a handful of humans understand all of C# or C++, and inevitably you'll come across some obscure thing and have to context switch out of reading code to learn whatever the fuck a "part…

> The nice thing about Go is that you can learn "all of it" in a reasonable amount of time This always feels like one of those “taste” things that some programmers tend to like on a personal level but has almost no evidence that it leads to more real-world success vs any other language. Like, people get real work done every day at scale with C# and C++. And Java, and Ruby, and Rust, and JavaScript. And every other la…

Just an anecdote and not necessarily generalizable, but I can at least give one example:

I'm in academia doing ML research where, for all intents and purposes, we work exclusively in Python. We had a massive CSV dataset which required sorting, filtering, and other data transformations. Without getting into details, we had to rerun the entire process when new data came in roughly every week. Even using every trick to speed up the Python code, it took around 3 days.

I got so annoyed by it that I decided to rewrite it in a compiled language. Since it had been a few years since I've written any C/C++, which was only for a single class in undergrad and I remember very little of, I decided to give Go a try.

I was able to learn enough of the language and write up a simple program to do the data processing in less than a few hours, which reduced the time it took from 3+ days to less than 2 hours.

I unfortunately haven't had a chance or a need to write any more Go since then. I'm sure other compiled, GC languages (e.g., Nim) would've been just as productive or performant, but I know that C/C++ would've taken me much longer to figure out and would've been much harder to read/understand for the others that work with me who pretty much only know Python. I'm fairly certain that if any of them needed to add to the program, they'd be able to do so without wasting more than a day to do so.

Re: Go's Sweet 16

#57

Earlier quoted context omitted.

This is also what I like about JS, except it's even easier than Go. Meanwhile Python has a surprising number of random features.

ECMAScript is an order of magnitude more complicated than Go by virtually every measure - length of language spec, ease of parsing, number of context-sensitive keywords and operators, etc.

Yeah I’m pretty sure people who say JS is easy don’t know about its Prototype based OOP

Re: Go's Sweet 16

#58
post #37

Earlier quoted context omitted.

The nice thing about Go is that you can learn "all of it" in a reasonable amount of time: gotchas, concurrency stuff, everything. There is something very comforting about knowing the entire spec of a language. I'm convinced no more than a handful of humans understand all of C# or C++, and inevitably you'll come across some obscure thing and have to context switch out of reading code to learn whatever the fuck a "part…

I've been writing go professionally for about ten years, and with go I regularly find myself saying "this is pretty boring", followed by "but that's a good thing" because I'm pretty sure that I won't do anything in a go program that would cause the other team members much trouble if I were to get run over by a bus or die of boredom. In contrast writing C++ feels like solving an endless series of puzzles, and there is…

Go is okay. I don't hate it but I certainly don't love it.

The packaging story is better than c++ or python but that's not saying much, the way it handles private repos is a colossal pain, and the fact that originally you had to have everything under one particular blessed directory and modules were an afterthought sure speaks volumes about the critical thinking (or lack thereof) that went into the design.

Also I miss being able to use exceptions.

Re: Go's Sweet 16

#59
post #36

Earlier quoted context omitted.

> I'm convinced no more than a handful of humans understand all of C# or C++ How would the proportion of humans that understand all of Rust compare?

Rust isn’t that complicated if you have some background in non GC languages.

Parent say _all_ of it, not a subset for everyday use.

Re: Go's Sweet 16

#60

Golang to me is a great runtime and very poor language. I could maybe get used to the C pointer-like syntax and to half of my code checking if err != nil, but the lack of classes is a step too far. The Golang idiomatic approach is to have a sprawling set of microservices talking to each other over the network, to manage complexity instead of having classes. This makes sense for things like systems agents (eg K8) but…

I think lack of classes is highly desirable. So much enterprise code is poorly put together abstractions. I think go needs some more functional aspects, like iterators and result type/pattern matching.

Go does have iterators: https://pkg.go.dev/iter
Post reply on HN