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

501–510 of 526 posts

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

#501

Post by the_gipsy »

9rx wrote: post #498
the_gipsy wrote: post #496

Earlier quoted context omitted.

With conclusion I meant you claiming that go returns multiple values because a function also takes multiple values. I did not refer to judging this as worse or better than having tuples as general types instead. > it was no doubt for map presence checks. Without that, it is impossible to know if a map contains a given key Are you just making stuff up on the go? A map access is not even a function call. And if you nee…

> With conclusion I meant you claiming that go returns multiple values because a function also takes multiple values. That remains the most reasonable explanation. There is no legitimate reason for functions that accept multiple arguments but only return one argument. That defies the very nature of what a function is. C made a mistake, but that is not a good reason to copy it. It also made a mistake around memory man…

Rust, and other modern languages, have tuples. So a single return value is effectively sufficient.

I refuse to believe that go added MRV for some esoteric reason. In practice it just makes up for the lack of tuples and sumtypes (errors mostly). It also would stand sharply against every other design decision (or accident) that go has made.

MRV also lacks functors in contrast to tuples.

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

#502

Post by Arnavion »

sshine wrote: post #493
Arnavion wrote: post #398

Earlier quoted context omitted.

>Because the compiler will fail if you don't explicitly mention each possible exception. But only the first time. Once you add `throws FooException` to the caller signature, the compiler won't complain about any future callees that also happen to throw FooException, even if you did care about handling their exceptions yourself. With callees that return Result you do get to make that decision for every callee.

That's a fair distinction. I would say "adding Result to the caller signature" provides a similar cascade, but it's not entirely true: Every call must separately be unwrapped. So consistently wrapping your Result calls with the '?' operator is similar to a gigantic try-catch block or adding 'throws CheckedException' everywhere. So both the '?' operator and adding 'throws CheckedException' everywhere let you accidenta…

>So both the '?' operator and adding 'throws CheckedException' everywhere let you accidentally neglect proper error handling: You have a default that is syntactically almost invisible and frees you from thinking.

No. You're choosing to write the `?` there to bubble up the error. It's a compiler error if you forget it. Whereas with `throws FooException` you only get forced to remember it the first time, and after that you're allowed to forget it.

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

#503

Post by worldsayshi »

guappa wrote: post #455
worldsayshi wrote: post #187

Earlier quoted context omitted.

The one language feature that I miss in most languages is pattern matching. I wonder if there's any minimalistic language that implements pattern matching well?

haskell?

Minimalistic?

I suppose you mean haskell without extensions.

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

#504

Post by baranul »

dfawcus wrote: post #390
packetlost wrote: post #338

Earlier quoted context omitted.

Rust and Go's lack of stack traces are basically equivalent in that you need to call an additional function to add the stack context to the error result. For go you use fmt.Errorf, in Rust you use .context from anyhow (bad practice in many contexts IMO) or .inspect_err + log. It's rather unfortunate that neither has an easy way of capturing a line number + file easily and appending it to the context. Go could easily…

> I agree that Go should really have an analogue to Rust's `?`, but you can't really do that in a sane way without sum types to represent your conditions. The very multiple-return style error propagation makes it impractical to do. There is always the Odin style 'or_return' operator, which is defined for a similar situation. https://odin-lang.org/docs/overview/#or_return-operator

What is quite interesting (after looking at their documentation), is that V lang[1] has all that is mentioned: `?`[2], `or`[2], sum types[3], and can return multiple values[4].

[1]: https://vlang.io/

[2]: https://github.com/vlang/v/blob/master/doc/docs.md#optionres...

[3]: https://github.com/vlang/v/blob/master/doc/docs.md#sum-types

[4]: https://github.com/vlang/v/blob/master/doc/docs.md#returning...

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

#505

Post by baranul »

masklinn wrote: post #78
the_gipsy wrote: post #29

Earlier quoted context omitted.

There are several shortcomings with go's error handling. The author heavily lies onto rust, so the alternative is not exceptions but a `Result ` sum type. No stacktraces and error wrapping forces you to not only invent unique error messages. You must also conceive a unique wrapping message at every call-site so that you can grep the error message and approximate a stacktrace. The weird "return tuple" , which obviousl…

> The weird "return tuple" , which obviously just exists for errors because there is not a single other place where you can use tuples in the language MRV, go does not have tuples. Go is not the only language with MRV (as a special case) and they’re not necessarily bad, iirc Common Lisp uses them as auxiliary data channels and has a whole host of functions to manipulate and refit them. Go is singularly incompetent at…

I've noticed that many people make this mistake with Go and other languages that use MRV (multiple return values). It seems that people who come from a language with tuples have a hard time dealing with the difference or realizing they are different.

It's a plus versus minus type of situation, where both have their advantages and disadvantages, along with a number of workarounds and alternatives that can be used.

In many cases, people can return arrays, hash maps, or structs in place of tuples. That looks like the reasoning in Go, where if the person needs something beyond MRV, they can use the other options available. Go and various other languages, didn't need or didn't want to lean on tuples as much.

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

#506

Post by baranul »

the_gipsy wrote: post #370
packetlost wrote: post #338

Earlier quoted context omitted.

Rust and Go's lack of stack traces are basically equivalent in that you need to call an additional function to add the stack context to the error result. For go you use fmt.Errorf, in Rust you use .context from anyhow (bad practice in many contexts IMO) or .inspect_err + log. It's rather unfortunate that neither has an easy way of capturing a line number + file easily and appending it to the context. Go could easily…

> Go should really have an analogue to Rust's `?`, but you can't really do that in a sane way without sum types It could be just some simple (hey, that's what go wants to be, right?) macro thing, that just does the everyday `if err!=nil{return ..., err}` for you without having to juggle (and think about) vars. b := g(f()?)? // var b B // { // var a A // var err error // a, err = f() // if err != nil { // return *new(…

For a more corporate driven and controlled language, once it goes down a certain direction, it appears really hard for it to stop the train or get enough momentum to change directions. Easy examples are generics, enums, sum types, etc...

Therefore other languages (influenced by Golang), like V (vlang.io), Odin (odin-lang.org), Jai, C3... made such improvements. One could argue that it's more a matter of if people are going to be brave or open-minded enough to try something different or go in a different direction.

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

#507

Post by thot_experiment »

zwnow wrote: post #446
thot_experiment wrote: post #375

Earlier quoted context omitted.

You should bother because of the externalities that aren't captured by capitalism. Also OP never called anyone a poor programmer, he said the language was made FOR poor programmers. Rob Pike, one of the people who came up with golang (and unix) is quoted as saying: > They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of und…

Sam Altman read a draft of this, I wont read anything that has to do with this idiot. Also poor programmers now equals idiots?

Probably shouldn't be on HN then, it's about the same degrees removed.

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

#508

Post by sshine »

Arnavion wrote: post #502
sshine wrote: post #493

Earlier quoted context omitted.

That's a fair distinction. I would say "adding Result to the caller signature" provides a similar cascade, but it's not entirely true: Every call must separately be unwrapped. So consistently wrapping your Result calls with the '?' operator is similar to a gigantic try-catch block or adding 'throws CheckedException' everywhere. So both the '?' operator and adding 'throws CheckedException' everywhere let you accidenta…

>So both the '?' operator and adding 'throws CheckedException' everywhere let you accidentally neglect proper error handling: You have a default that is syntactically almost invisible and frees you from thinking. No. You're choosing to write the `?` there to bubble up the error. It's a compiler error if you forget it. Whereas with `throws FooException` you only get forced to remember it the first time, and after that…

> You're choosing to write the `?`

...but you're not choosing to write the `throws FooException`?

I can only say that if the `?` weren't around and you had to write more verbose handling each time, having the question "How should this one particular error be handled?" might come up more often and might prevent more bugs than when you can carelessly `?`-annotate your way through a dozen lines without any equivalents of `finally { ... }` anywhere.

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

#509

Post by masklinn »

baranul wrote: post #505
masklinn wrote: post #78

Earlier quoted context omitted.

> The weird "return tuple" , which obviously just exists for errors because there is not a single other place where you can use tuples in the language MRV, go does not have tuples. Go is not the only language with MRV (as a special case) and they’re not necessarily bad, iirc Common Lisp uses them as auxiliary data channels and has a whole host of functions to manipulate and refit them. Go is singularly incompetent at…

I've noticed that many people make this mistake with Go and other languages that use MRV (multiple return values). It seems that people who come from a language with tuples have a hard time dealing with the difference or realizing they are different. It's a plus versus minus type of situation, where both have their advantages and disadvantages, along with a number of workarounds and alternatives that can be used. In…

> It seems that people who come from a language with tuples have a hard time dealing with the difference or realizing they are different.

The problem is that Go only has the drawbacks of MRV and leverages essentially none of the advantages.

> Go and various other languages, didn't need or didn't want to lean on tuples as much.

As far as I’m concerned go would be a strictly better language if it had tuples (or even just the ability to unpack structs).

All the nonsense about foo/foo2 to handle both single and multiple results would go away, and pretty much the only thing which would be lost is individual addressing of MRVs for named return values, which is easy enough to replace by naming the return struct and going through it.

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

#510

Post by nagarajh »

amai wrote: post #378

Sorry to spoil the party, but the future is mobile and none of your favorite programming language ( Rust, go, Python, Nim, Lisp, Zig, Smalltalk ...) is ready for this. The future will be Kotlin, Swift and Javascript and I already hate it.

Absolutely. New programming languages keep coming in. But what survives for long term are those which help solve business problems. Love them or hate them, but programming languages like Java, JavaScript, Kotlin, Swift do them more than any other languages for the Servers, front end and mobiles. Then there is Python ecosystem for the huge AI job market. Wearable devices take the challenge to next level along with all those advancements in mobile space. All these cool languages have a long way to go in building the eco system to be effective at these landscapes. By the time they try to get there, there will be new other languages that would be termed 'cool' at that point in time. And, the problem landscape will be elsewhere altogether. Then these cool languages would no longer be cool by then. Nor would they be addressing the growing landscape with their just growing eco system. they slowly fall into identity crisis and die down. I'm sorry, what a grim picture I'm portraying :-)
Post reply on HN