Live data from Hacker News

Go's Sweet 16

go.dev

111–120 of 280 posts

Re: Go's Sweet 16

#111
post #107

To me, Go is like Rust oversimplified beyond reason. It edits your code when you don't ask, removing things you just started; it lacks iterators -- every time you must write a big cycle instead. It lacks simple things like check if a key exists in a map. Proponents say it has nothing under the hood. I see under-the-hood-magic happen every time. 1) The arrays append is one example. Try removing an element from an arra…

> it lacks iterators -- every time you must write a big cycle instead It has iterators - https://pkg.go.dev/iter . > It lacks simple things like check if a key exists in a map. What? `value, keyExists := myMap[someKey]` > Try removing an element from an array - you must rely on some magic and awkward syntax, and there's no clear explanation what actually happens under the hood (all docs just show you that a slice is…

> `value, keyExists := myMap[someKey]`

If I don't need the value, I have to do awkward tricks with this construct. like `if _, key_exists := my_may[key]; key_exists { ... }`.

Also, you can do `value := myMap[someKey]`, and it will just return a value or nil.

Also, if the map has arrays as elements, it will magically create one, like Python's defaultdict.

This construct (assigning from map subscript) is pure magic, despite all the claims, that there's none in Golang.

...And also: I guess the idea was to make the language minimal and easy to learn, hence primitives have no methods on them. But... after all OOP in limited form is there in Golang, exactly like in Rust. And I don't see the point why custom structs do have methods, and it's easier to use, but basic ones don't, and you have to go import packages.

Not that it's wrong. But it's not easier at all, and learning curve just moves to another place.

Re: Go's Sweet 16

#112

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…

Language can be bottleneck if there's something huge missing from it that you need, like how many of them didn't have first class support for cooperative multitasking, or maybe you need it to be compiled, or not compiled, or GC vs no GC. Go started out with solid greenthreading, while afaik no major lang/runtime had something comparable at the time (Java now does supposedly). The thing people tend to overvalue is the…

I'll be the one to nickpick, but Scala never intended to be a nicer Java. It was and still is an academic exercise in compiler and language theory. Also, judging by Kotlin's decent strides, "little Syntex differences" get you a long way on a competent VM/Runtime/stdlib.

Re: Go's Sweet 16

#113

Go would probably be my favorite language if it just had a few more features around functional programming. Specifically around immutability and nullness, and maybe exhaustive switch statements. Then it just might be perfect. At work we use Uber’s NillAway, so that helps bit. https://github.com/uber-go/nilaway Though actually having the type system handle it would be nicer.

There is borgo https://github.com/borgo-lang/borgo but it's not yet mature and not being actively developed

Re: Go's Sweet 16

#114
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…

I think Go is a great language when hiring. If you're hiring for C++, you'll be wary of someone who only knows JavaScript as they have a steep learning curve ahead. But learning Go is very quick when you already know another programming language.

Re: Go's Sweet 16

#115

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…

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 using Python since 2008, and I don’t feel like I understand very much of it at all, but after just a couple of years of using Go in a hobby capacity I felt I knew it very well.

Re: Go's Sweet 16

#116
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…

I agree that empirical data in programming is difficult, but i’ve used many of those languages personally, so I can say for myself at least that I’m far more productive in Go than any of those other languages.

> As an aside, I’d even go so far as to say that the main problem with C++ is not that it has so many features in number, but that its features interact with each other in unpredictable ways. Said another way, it’s not the number of nodes in the graph, but the number of edges and the manner of those edges.

I think those problems are related. The more features you have, the more difficult it becomes to avoid strange, surprising interactions. It’s like a pharmacist working with a patient who is taking a whole cocktail of prescriptions; it becomes a combinatorial problem to avoid harmful reactions.

Re: Go's Sweet 16

#117

Earlier quoted context omitted.

When Go was new, having better package management than Python and C++ was saying a lot. I’m sure Go wasn’t the first, but there weren’t many mainstream languages that didn’t make you learn some imperative DSL just to add dependencies.

Sure, but all those languages didn't have the psychotic design that mandated all your code lives under $GOPATH for the first several versions. I'm not saying it's awful, it's just a pretty mid language, is all.

I picked up Go precisely in 2012 because $GOPATH (as bad as it was) was infinitely better than CMake, Gradle, Autotools, pip, etc. It was dead simple to do basic dependency management and get an executable binary out. In any other mainstream language on offer at the time, you had to learn an entire programming language just to script your meta build system before you could even begin writing code, and that build system programming language was often more complex than Go.

Re: Go's Sweet 16

#118
post #109
post #34

Earlier quoted context omitted.

The Javascript world hides its complexity outside the core language, though. JS itself isn't so weird (though as always see the "Wat?" video), but the incantations required to type and read the actual code are pretty wild. By the time you understand all of typescript, your templating environment of choice, and especially the increasingly arcane build complexity of the npm world, you've put in hours comparable to what…

…do you know you can just write JavaScript and run it in the browser? You don’t need TypeScript, NPM or build tools.

You do if you want more than one file, or if you want to use features that a user’s target browser may not support.

Re: Go's Sweet 16

#119
post #109

Earlier quoted context omitted.

…do you know you can just write JavaScript and run it in the browser? You don’t need TypeScript, NPM or build tools.

You do if you want more than one file, or if you want to use features that a user’s target browser may not support.

> You do if you want more than one file

Modules were added in, like, 2016.

Re: Go's Sweet 16

#120

Earlier quoted context omitted.

Does anyone use that other language? No!

That's not the point, no one uses 99% of languages, so if that's the standard then it's a free-for-all. The PL community is small, so norms are important. PL naming code is: 1. Whoever uses the name first, has claim to the name. Using the name first is measured by: when was the spec published, or when is the first repo commit. 2. A name can be reused IFF the author has abandoned the original project. Usually there's…

Like how C and C# are different languages, Go and Go! are different. There's not name reuse here.
Post reply on HN