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

231–240 of 280 posts

Re: Go's Sweet 16

#231

Post by super_flanker »

vlovich123 wrote: post #176
liveoneggs wrote: post #173

Earlier quoted context omitted.

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

It’s not true of C/C++ which need changes to the build system. Also true for rust workspaces which is how I’d recommend structuring monorepos although it is generally easy (you just need to add a small cargo.toml file) or you can not use a workspace but you still need to declare the binary if I recall correctly.

No, you don't. All you need is to create a folder `bin` and any file with `main` fn in it will create a binary.

Re: Go's Sweet 16

#232

Post by tapirl »

0x696C6961 wrote: post #230
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.

The problem is, when you modified the go version in go.mod, the behaviors of some code change, but the change is not easy to detect in time. Go team never plan to develop a tool to identify/detect code affected by such breaking changes, leaving developers without guarantees for safe migration.

And when running go scripts without go.mod files, the v1.22 toolchain doesn't respect the "//go:build go1.xx" directives: https://go101.org/bugs/go-build-directive-not-work.html

And consider that some people run go scripts even without the "//go:build go1.xx" directives ... (Please don't refute me. The Go toolchain allows this and never warns on this.)

Re: Go's Sweet 16

#233

Post by tapirl »

gf000 wrote: post #213
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…

It's especially funny considering that this issue has been known from lisps for 50+ years..

They can fix the issue by just changing the semantics of "for-range" loops, almost no negative effects. But they also applied the change to 3-clause-for loops, which causes many problems, some of which have been pointed out before the change was made. So the rookie mistake is totally caused by arrogance.

Re: Go's Sweet 16

#234

Post by roncesvalles »

zimpenfish wrote: post #143
egl2020 wrote: post #37

Earlier quoted context omitted.

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…

> I'm pretty sure that I won't do anything in a go program that would cause the other team members much trouble Alas there are plenty of people who do[0] - for some reason Go takes architecture astronaut brain and wacks it up to 11 and god help you if you have one or more of those on your team. [0] flashbacks to the interface calling an interface calling an interface calling an interface I dealt with last year - NONE…

My cardinal rule in Go is just don't use interfaces unless you really, really need to and there's no other way. If you're using interfaces you're probably up to no good and writing Java-ish code in Go. (usually the right reason to use interfaces is exportability)

Yes, not even for testing. Use monkey-patching instead.

Re: Go's Sweet 16

#235

Post by dlock17 »

insurancesucks wrote: post #185

Every Go thread on this site is the same. "Man I love Go, it's so simple, plenty fast, really easy to pick up, read, and write. I really love that it doesn't have dozens of esoteric features for my colleagues to big brain into the codebase" "Oh yeah? Well Go sucks, it doesn't have dozens of esoteric features for me to big brain into the codebase" Repeat

Yep, and I personally feel like it's been the biggest stealth marketing of Go through the years.

Re: Go's Sweet 16

#236

Post by Merovius »

liveoneggs wrote: post #229
dlisboa wrote: post #225

Earlier quoted context omitted.

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 w…

> But, like, this is exactly as easy with every single other language that I can think of.

I mean, not exactly. Rust (or rather Cargo) requires you to declare binaries in your Cargo.toml, for example. It also, AIUI, requires a specific source layout - binaries need to be named `main.rs` or be in `src/bin`. It's a lot more ceremony and it has actively annoyed me whenever I tried out Rust.

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

Again, no, it is not trivial. Using make requires you to write a Makefile. Using shell requires you to write a shell script.

I'm not saying any of this is prohibitive - or even that they should convince anyone to use Go - but it is just not true to say that other languages make this just as easy as Go.

Re: Go's Sweet 16

#237

Post by culebron21 »

lenkite wrote: post #150
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…

> This makes you split functions in many pieces, turning your code into enterprise Java. Umm..in Java you won't have to split functions here. Maybe you should study some modern Java ?

I didn't mean that in Java you must split functions. I meant that code becomes a lot of functions with seemingly English names, but it's obscure what is happening.

p.s. upvoted, because some mob came and downvoted those who replied to me.

Re: Go's Sweet 16

#238

Post by culebron21 »

9rx wrote: post #92
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…

> proper enums It has proper enums. Granted, it lacks an enum keyword, which seems to trip up many. Perhaps what you are actually looking for is sum types? Given that you mentioned Rust, which weirdly[1] uses the enum keyword for sum types, this seems likely. Go does indeed lack that. Sum types are not enums, though. > sensible arrays & slices, without any magic and awkward syntax Its arrays and slices are exactly th…

upvoted to compensate the mob that came about and downvoted those who replied to me.

Re: Go's Sweet 16

#239

Post by morshu9001 »

ajross wrote: post #34
morshu9001 wrote: post #24

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.

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…

nodejs and npm are easy for beginners, especially compared to the Python packaging situation

Re: Go's Sweet 16

#240

Post by nasretdinov »

Merovius wrote: post #236
liveoneggs wrote: post #229

Earlier quoted context omitted.

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 w…

> But, like, this is exactly as easy with every single other language that I can think of. I mean, not exactly . Rust (or rather Cargo) requires you to declare binaries in your Cargo.toml, for example. It also, AIUI, requires a specific source layout - binaries need to be named `main.rs` or be in `src/bin`. It's a lot more ceremony and it has actively annoyed me whenever I tried out Rust. > The second part "Running g…

I think one other major part is that, compared to e.g. make the build process is more-or-less the same for all Go projects. There is some variation, and some (newcomers I want to think) still like to wrap go commands into Makefile, but it's still generally very easy to understand and very uniform across different Go projects
Post reply on HN