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

Go's Sweet 16

go.dev

Post reply on HN
Print view View original

221–230 of 280 posts

Re: Go's Sweet 16

#221

Post by malkia »

liveoneggs wrote: post #173
liampulles wrote: post #133

I love Go. One thing I haven't seen noted here is how great it is for use in monorepos. Adding a new application is just a matter of making a folder and putting a main packaged go file with a main() func. Running go install at the root ./.. takes care of compiling everything quickly and easily. This combined with the ease of building CLI programs has been an absolute godsend in the past when I've had to quickly spin…

I don't understand how this isn't also true for practically every other language?

With bazel/buck/pants/etc won't be problem for other major languages.

Re: Go's Sweet 16

#222

Post by nicodjimenez »

grey-area wrote: post #201
nicodjimenez wrote: post #47

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…

Microservices are entirely unrelated to classes and in no way endemic to go. Go’s lack of inheritance is one of its bolder decisions and I think has been proven entirely correct in use. Instead of the incidental complexity encouraged by pointless inheritance hierarchies we go back to structure which bundle data and behaviour and can compose them instead. Favouring composition over inheritance is not a new idea nor di…

Microservices in Golang are definitely related to classes due to the ergonomic aspects of a language. It takes a lot of discipline in Golang not to end up with huge flat functions. Golang services are easier to reason about when they are small due to the lack of abstractions, also Golang is very quick to compile, so its natural to just add services to extend functionality. Code re-use is just a lot of work in Golang. Golang is not monolith friendly IMO.

Re: Go's Sweet 16

#223

Post by benjiro »

Xeoncross wrote: post #3

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…

Funny thing is that also makes it easier on LLM / AI... Tried a project a while ago both creating the same thing in Rust and Go. Go's worked from the start, while Rust's version needed a lot of LLM interventions and fixes to get it to compile.

We shall not talk about compile time / resource usage differences ;)

I mean, Rust is nice, but compared to when i learned it like 10 years ago, it really looks a lot more these days, like it took too much of a que from C++.

While Go syntax is still the same as it was 10 years ago with barely anything new. What may anger people but even so...

The only thing i love to see is reduce executable sizes because pushing large executables on a dinky upload line, to remove testing is not fun.

Re: Go's Sweet 16

#224

Post by benjiro »

ErroneousBosh wrote: post #186
throw1111221 wrote: post #50

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…

> This is why unused dependencies are a compile time error. I think my favourite bit of Go opinionatedness is the code formatting. K&R or GTFO. Oh you don't like your opening bracket on the same line? Tough shit, syntax error.

But it also has a advantages that you can literally read a lot of code from other devs without twisting your eyes sideways because everybody has their own style.

Re: Go's Sweet 16

#225

Post by dlisboa »

liveoneggs wrote: post #173
liampulles wrote: post #133

I love Go. One thing I haven't seen noted here is how great it is for use in monorepos. Adding a new application is just a matter of making a folder and putting a main packaged go file with a main() func. Running go install at the root ./.. takes care of compiling everything quickly and easily. This combined with the ease of building CLI programs has been an absolute godsend in the past when I've had to quickly spin…

I don't understand how this isn't also true for practically every other language?

It just isn't. There's nothing stopping other languages from being that easy but very few even try.

Go sees itself more as a total dev environment than just a language. There's integrated build tooling, package management, toolchain management, mono repo tools, testing, fuzzing, coverage, documentation, formatting, code analysis tools, performance tools...everything integrated in a single binary and it doesn't feel bloated at all.

You see a lot of modern runtimes and languages have learned from Go. Deno, Bun and even Rust took a lot of their cues from Go. It's understood now that you need a lot more than just a compiler/runtime to be useful. In languages that don't have that kind of tooling the community is trying to make them more Go-like, for example `uv` for Python.

Getting started in a Go project is ridiculously easy because of that integrated approach.

Re: Go's Sweet 16

#226

Post by ricardobeat »

malkia wrote: post #221
liveoneggs wrote: post #173

Earlier quoted context omitted.

I don't understand how this isn't also true for practically every other language?

With bazel/buck/pants/etc won't be problem for other major languages.

Have you worked with those before? "Quickly and easily" are not exactly what comes to mind.

Re: Go's Sweet 16

#227

Post by [deleted] »

culebron21 wrote: post #87

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…

[deleted]

Re: Go's Sweet 16

#228

Post by ricardobeat »

culebron21 wrote: post #111
Mawr wrote: post #107

Earlier quoted context omitted.

> 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, de…

_ is idiomatic and not an awkward trick. It keeps signatures consistent even when you don't need the value.

Re: Go's Sweet 16

#229

Post by liveoneggs »

dlisboa wrote: post #225
liveoneggs wrote: post #173

Earlier quoted context omitted.

I don't understand how this isn't also true for practically every other language?

It just isn't. There's nothing stopping other languages from being that easy but very few even try. Go sees itself more as a total dev environment than just a language. There's integrated build tooling, package management, toolchain management, mono repo tools, testing, fuzzing, coverage, documentation, formatting, code analysis tools, performance tools...everything integrated in a single binary and it doesn't feel b…

I personally like Go and appreciate its simplicity and tooling and everything but the example given is "making a folder" and "putting a ... main() func" in it. But, like, this is exactly as easy with every single other language that I can think of.

The second part "Running go install at the root ./.." is actually terrible and risky but, still, trivial with make (a - literally - 50 year old program) or shell or just whatever.

I get that the feelz are nice and all (just go $subcmd) but.. come on.

Re: Go's Sweet 16

#230

Post by 0x696C6961 »

tapirl wrote: post #88

> Go stands by its compatibility promise—the old way will continue to work in perpetuity ... It is so weird that they still claim this after they have made the the semantic change for 3-clause for-loop in Go 1.22. When a Go module is upgraded from 1.21- to 1.22+, there are some potential breaking cases which are hard to detect in time. https://go101.org/blog/2024-03-01-for-loop-semantic-changes-... Go toolchain 1.22…

The new toolchain continues to compile old code using the old semantics. Only modules which specify Go 1.22 in go.mod have the new bahivour.
Post reply on HN