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

Lies we tell ourselves to keep using Golang (2022)

fasterthanli.me

Post reply on HN
Print view View original

401–410 of 526 posts

Re: Lies we tell ourselves to keep using Golang (2022)

#401

Post by packetlost »

9rx wrote: post #377
pdimitar wrote: post #340

Earlier quoted context omitted.

RE: Golang v2, they clearly said they will not do it and will double down on backwards compatibility with exceptions powered by env vars and/or CLI switches.

Technically, Go v2 signified the transition away from Google control to the project being directed by the community. That happened several years ago. Go v2 is already here and has been for a long time. The stdlib is also at v2 now (e.g. math/rand/v2). You must mean the language? They said that a language v2 (go2) is probably unnecessary – that any future additions could be added without breaking the existing language…

This was what I was referring to. The stdlib is what would need to see backwards-compatibility-breaking changes, not the language itself.

Re: Lies we tell ourselves to keep using Golang (2022)

#402

Post by Too »

quotemstr wrote: post #122
maleldil wrote: post #119

Earlier quoted context omitted.

> what's the difference between your program and one with exceptions Because errors as values are explicit. You're not forced to use ? everywhere; you can still process errors however you like, or return them directly to the calling function so they deal with it. They're not separate control flow like exceptions, and they're not a mess like Go's.

No, because you end up with a function coloring problem that way. A function that returns something other than Result has to either call only infallible code or panic on error, and since something can go wrong in most code, the whole codebase converges as time goes to infinity on having Result everywhere. Yeah, yeah, you can say it's explicit and you can handle it how you want and so on, but the overall effect is jus…

I think your conclusion is on the right track. Syntax sugar propagating results is in a way equivalent to exceptions. What you are missing it isn’t just equivalent to ordinary exceptions. It’s more equivalent to checked exceptions. A very powerful concept, that unfortunately got a bad rap, because the most widespread implementation of it (Java) was unreasonably verbose to use in practice. You might claim Rust is still too verbose and I don’t disagree with that, it’s a big improvement from Java at least, while at the same time providing even more safety nets.

Re: Lies we tell ourselves to keep using Golang (2022)

#403

Post by monksy »

Cthulhu_ wrote: post #73
monksy wrote: post #57

Earlier quoted context omitted.

> Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives. A lot of people really don't like Go because they have experienced other language features. Go has taken an arrogant stance at trying to make the decision about what features you might need and has given you a very small amount of things to work with.

Counterpoint, other languages - notably Javascript, Scala, PHP, maybe Java - have taken the stance that they adopt other languages' features, not because the language needs it, but because developers were clamoring for it. Which led to added complexity, because they kept adding more and more ways to solve a problem or structure an application, which led to every codebase being so different from the next that the amou…

I like scala and I think it's a great language even with teams.

I think you're overlooking the context of the language. It was a language that introduced a lot of new concepts to most programmers out there on top of that it was flexible to accomidate existing Java developers (for better or for worse). It evolved and grew quite a bit.

The fact that you could develop different styles made the language a lot more useful.

I'm not sure what you mean by transferable skills.. but that sounds like code for overly excessive coding preferences by hiring groups. If you're working with Play you'll be able to learn Finagale, or go to Http4s.

When you attack a codebase, you can't consume it and understand the full context easily, the range of operations that a code base is expected to do is far too vast for that. Even with Go, you can't just pickup and go that quickly. It may (if you're that experienced) become easier to understand. But with a large codebase, it's going to make it much harder as that it encourages large drawn out functions and verbose handling of errors. Also, Go's testing preferences tend to make it harder to write good and effective tests.

Re: Lies we tell ourselves to keep using Golang (2022)

#404

Post by monksy »

theshrike79 wrote: post #76
monksy wrote: post #57

Earlier quoted context omitted.

> Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives. A lot of people really don't like Go because they have experienced other language features. Go has taken an arrogant stance at trying to make the decision about what features you might need and has given you a very small amount of things to work with.

I love the fact that I can pick up a Go project from 5+ years ago and it still compiles with the current toolchain. I might need to do a 'go mod init' first. It didn't get 67 new features that start shooting deprecation warnings on old functions in the meantime. I don't have to learn new paradigms or switch integral parts of my code to something new. Generics has been in Go for dunno how long, haven't used it once. D…

I'm not sure that's a good thing. But for your arugement, code from 5+ years ago and keeping the same deps you're mostly able to do that with java*.

(With exception to some java9 and minor deprications).

However, wait long enough that will come to Go, or it'll become less useful.

Re: Lies we tell ourselves to keep using Golang (2022)

#405

Post by monksy »

madeofpalk wrote: post #166
monksy wrote: post #10

Earlier quoted context omitted.

I would certainly argue against the claim that explicit error handling is far overkill. Where I agree: It forces you to think about all of the possibilities your code might generate. (This is more of a C question than it is with other languages) However, when abstracting blocks of code away, you don't always need to handle the error immediently or you may want to handle it down the stack. You're giving up a lot of re…

> It forces you to think about all of the possibilities your code might generate. Except it doesn't actually. You can totally just ignore it and pretend errors don't exist. Lack of sum types/Result, and pointers as poor mans optional, really hinder's Go's error handling story.

I agree with you that the sum types are much better and it's intentional that they wanted null support. (Which was a frustrating pick considering the modern dev languages out there).

The coding style encourages the behavior you're talking about. We're back in the C days where you have a result and an error. It's not a good pattern.

Re: Lies we tell ourselves to keep using Golang (2022)

#406

Post by mjevans »

CharlieDigital wrote: post #270
mjevans wrote: post #16

There _are_ two problems with Golang that I _would_ like to wave a magic wand and fix if that was a power I had. 1) Sum types (E.G. C/C++ union types) - Yeah, something similar to that should exist... it's syntax sugar over #2 2) 'casting' / reshaping perspective on data ; as long as something has the same struct size a programmer should be able to tell the compiler 'but this is actually that'. Which also implies a w…

I started learning Go and when I got to the chapter on slices is when I dropped it. I can't put my finger on why it was so off-putting, but it just left a bad taste.

It's exactly what I described in point 3 as 'the problem'.

Maps 'work' because as a programmer you're aware of how expensive it is to copy a whole hash table, and it makes sense that a pointer to the thing is the whole thing. So it's an exception, but one _clean_ exception that just behaves consistently.

Slices are horrid in that they SOMETIMES work the way someone who passes by value expects, and that's the same for both NOT updating AND Updating. This is because the management stage is passed by copy, not reference, but the backing data IS a reference, which initially is copied. That leads to in-place overwrites when no change in size has happened. It leads to appends that do get written but not reflected in other copies of the slice, and then if there's a need to re-allocate it leads to even the updates not updating the other copies of the slice.

Slices are the most beginner un-friendly part of Golang.

Re: Lies we tell ourselves to keep using Golang (2022)

#407

Post by zapnuk »

Terretta wrote: post #372
zapnuk wrote: post #196

Earlier quoted context omitted.

If they'd drastically improved their tooling then yes. But sadly it's not that easy to create a statically liked binary in swift. The last time i did it it also included the whole runtime, and the resulting "hello world" binary was 50mb large. Annoying at least. For years I wished they got their stuff together, but at this point I'd be very suprised. They probably have too much technical dept already due to the suppo…

> For years I wished they got their stuff together, but at this point I'd be very suprised. This is a thing that's having work done, but still too large depending: https://www.swift.org/documentation/articles/static-linux-ge... See here for sizes of various languages as of August 2024 when I'm commenting, but this is Swift 5.10 for Windows: https://github.com/MichalStrehovsky/sizegame Build actions here: https://gith…

Good that they work on it. And the efforts to refactor foundation into smaller modules go in the same direction.

I continue to root for them but they need so many improvments to be a realistic alternative to python/typescript/go/java for regular backend development.

At least in my field where we need to sure that other developers can continue the development without much hassle.

Just as an example, with those languages it's almost trivial to setup a basic projekt with dependencies. In swift however, it takes careful reading ot the swift package manager documentation to understand their concept of "products", "targets", etc. And I'm pretty sure i'd have to start from zero when i use swift for the advent of code in a few days.

There are many problems with devepdencies in Python, or package.json/gradle files. But at least they are (almost) foolproof to get started.

Re: Lies we tell ourselves to keep using Golang (2022)

#408

Post by the_gipsy »

wbl wrote: post #379
the_gipsy wrote: post #368

Earlier quoted context omitted.

https://go.dev/wiki/CodeReviewComments#interfaces

How on earth is that violated by error? error is implemented by types all over the standard library and beyond and consumed by functions that wrap errors in the errors package. It's exactly an example of what you claim is violated. Even more obviously your link isn't talking about functions but packages. There are some violations out there but generally when included packages define interfaces they are ones that get…

> The implementing package should return concrete (usually pointer or struct) types

It's in the first paragraph. It goes on in the second:

> Do not define interfaces on the implementor side of an API “for mocking”; instead, design the API so that it can be tested using the public API of the real implementation.

And yes, io.Reader/Writer violate that too, because either the tenet is wrong or the design of interfaces in go is wrong.

> Even more obviously your link isn't talking about functions but packages.

It doesn't matter: your exporting errors behind the error interface, not your concrete error implementation. If you're just using one of the many ways to create stringly errors (!) like fmt.Errorf, you maybe don't notice but you are in fact returning interfaces all the time.

Re: Lies we tell ourselves to keep using Golang (2022)

#409

Post by Too »

liotier wrote: post #59
troupo wrote: post #12

Earlier quoted context omitted.

It's actually very rare that it should be the caller who has to handle the errors. Go, however, forces you to spread your error handling over a thousand little pieces with zero overview or control of what's happening. Rust eventually realised this and introduced try! and ? to simplify this

Unsure if this is the right place to ask, but this conversation inspires me this question: Is there in practice a significant difference between try/catch and Go's "if err" ? Both seem to achieve the same purpose, though try/catch can cover a whole bunch of logic rather than a single function. Is that the only difference ?

“if err” doesn’t catch all types of errors. Some errors are colored different from others and instead cause the program to immediately crash, sorry panic. But don’t worry! it’s just very rare errors, like nil dereference and index out of bounds, that throw unrecoverable errors like this!

Re: Lies we tell ourselves to keep using Golang (2022)

#410

Post by foresto »

ivell wrote: post #237
sureglymop wrote: post #133

Rust and Go are very different and I feel people want a middle ground that just doesn't exist currently. A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc. Syntactically, Gleam and Kotlin come somewhat close but not really. I like Rust but I do believe it is too complicated for many people who are capable of creating some…

There is Crystal and Nim. With especially Nim, there is GC and generates c in the end.

Unfortunately, Nim's BDFL is... not known for playing well with others. Perhaps the Nimskull fork will grow into something widely useful?

https://github.com/nim-works/nimskull

Post reply on HN