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

441–450 of 526 posts

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

#441

Post by erik_seaberg »

masklinn wrote: post #204
pwdisswordfishz wrote: post #189

Earlier quoted context omitted.

> MRV, go does not have tuples. > MRVs mostly end up being worse tuples I think you noticed yourself that you’re getting too hung up on terminology. Multiple return values are a half-hearted, non-reified version of tuples.

No, MRVs can actually offer useful properties and features, that is what they do in Common Lisp. That Go does not do that has nothing to do with MRVs.

f(g(), h()) can't work with MRVs, only f(g()). multiple-value-list, multiple-value-call, and quietly ignoring unneeded values makes them much more usable.

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

#442

Post by damnever »

devjab wrote: post #5

This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take expl…

Go's error handling is not explicit because error is an interface. So, a nil MyError is not the same as a nil error, and error comparison is inconvenient because the interface constraints are so loose that people often resort to checking errors with strings.Contains.

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

#443

Post by thesuperbigfrog »

OtomotO wrote: post #435
jll29 wrote: post #427

Earlier quoted context omitted.

One of my dreams is for someone to create a Rust stdlib, full stop. I love Rust the language, but the current bazar of little bits of functionality scattered around in the form of a zoo of crates is such a mess compared to, say, Java's class library (I/O, data structures, std. algorthms for searching, sorting etc., arranged in a logically and hierarchially named way). I'm not against alternative implementations, but…

No! I mean, yes, but not an official one. The stdlib is where good ideas go to die. Waiting for "pub struct RDBMSInferfaceV17ThisTimeWeGotItRightForSure"

Firm disagree.

Sylvain Kerkour described the problems Rust faces by having a limited standard library:

"The time has come for Rust to graduate from a shadow employment program in Big Tech companies to a programming language empowering the masses of engineers (and not just "programmers") wanting to build efficient and robust sfotware.

What crypto library should we use? ring, RustCrypto, rust-crypto (don't use it!), boring, aws-lc-s or openssl?

Which HTTP framework? actix-web, axum, dropshot or hyper?

What about a time library? time, chrono or jiff (how I'm even supposed to find this one)?

You get it, if you are not constantly following the latest news, your code is already technical debt before it's even written. Fragmentation is exhausting.

I just looked at the dependencies of a medium-sized project I'm working on, and we have 5+ (!) different crpyto libraries: 2 different versions of ring, aws-lc-rs, boring, and various libraries from RustCrypto. All of this because our various dependencies have picked a different one for their own cryptographic usage. This is insane, first because it introduces a lot of supply chain attack entry points, but also because there is no way that we will audit all of them"

Source: https://kerkour.com/rust-stdx

My moderate-sized Rust web service project requires 587 third-party crates which seems ridiculous.

Fortunately, cargo makes it easy to manage the dependencies, but unfortunately I don't know how well supported or maintained the dependencies are. How well will they be maintained in five years from now? Will I need to find newer libraries and rewrite portions of my project to provide the same features that I have now? I don't know.

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

#444

Post by therealdrag0 »

Seb-C wrote: post #307
abtinf wrote: post #25

Earlier quoted context omitted.

Having programmed for over 30 years, including nearly a decade of C#, I would say exceptions are one of the worst ideas in all of programming. They are just horrific gotos that any library can invoke against your code. They are pretty much never, ever handled correctly. And nearly always, after an exception is “handled”, the application is actually in an unknown state and cannot be reasoned about. Even junior enginee…

I agree about implicit exceptions, but I think that there is a sweet spot with explicit exceptions like Swift (and maybe Java): where you cannot not-handle one, it is part of a function's signature, and the syntax is still compact enough that it does not hurt readability.

I think checked exceptions are noise. They usually never provide value, and are often just caught and rethrown as runtime exceptions to avoid the boilerplate. Scala did right to remove them.

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

#445

Post by lionkor »

clausecker wrote: post #423
lionkor wrote: post #313

Earlier quoted context omitted.

Have you tried the approach that Zig has, or the approach that Rust has? They are easy to debug and do not use any crazy stuff, just simple syntax like `try x()` (Zig) or `x()?` (Rust)

Yes and that syntax sucks.

That sounds like your opinion rather than a "it sucks because it encouraged bad practices" or something

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

#446

Post by zwnow »

thot_experiment wrote: post #375
zwnow wrote: post #145

Earlier quoted context omitted.

Commercial software is what pays my rent though. Why would I bother about open-source software other than personal interest?

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?

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

#447

Post by mrbadguy »

guappa wrote: post #384
mrbadguy wrote: post #361

Earlier quoted context omitted.

I’m not sure I understand the packed structs complaint. I have used Go to read binary data and it’s quite easy. You just need to ensure that all of your struct fields have fixed sizes e.g. int32 or [4]int64 or whatever. Unless I’ve misunderstood what you mean?

Yes it works, but you can't state the endianness and you have no control to decide if the compiler will decide to insert padding. It's undefined. You HOPE it works.

I don’t know about the padding (certainly it never inserted any when I’ve used it) but you can definitely state the byte order upon reading or writing. That would definitely be an oversight. Take a look at the encoding/binary package:

https://pkg.go.dev/encoding/binary

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

#448

Post by the_gipsy »

9rx wrote: post #429
the_gipsy wrote: post #422

Earlier quoted context omitted.

I meant weird/useless in the sense of that it's used virtually nowhere in practice. There is a nice func Must(value, err) { if err { panic(err) } else { return value } that you can use in tests to get around the inane regular error handling. But that's about it, to my knowledge. Sad that there isn't more to it. If literally everything returns error as last return value, there could well be some syntax sugar there.

I see it used often, even in languages that don't formally support multiple return arguments – with some hacked up array/object single value return to try and emulate what would be better represented as multiple return arguments. Like I mentioned in another comment, Go does seem especially prone to attracting developers familiar with other languages who insist on trying to continue to program in those other languages…

The pragmatically "right" choice is to have some tuple type built-in. Because they are not only very good for function in/out, they can be used in many more places. Lists of tuples, tuples in structs, etc.

If the language doesn't have tuples, then you have to "roll your own" and emulate them every single time, but it's not a functor so you can't do all the useful stuff.

Go didn't do the pragmatically right choice, because it's only right from a type perspective. But go doesn't care about types at all, they're just a side effect. Go only needed to return multiple values, so that you don't have to pass in one (or more) "out" pointer as argument, and check an errnum. So go is right but only from its narrow perspective: it's better than C.

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

#449

Post by guappa »

AnimalMuppet wrote: post #412
guappa wrote: post #383

Earlier quoted context omitted.

A segfault is a security vulnerability :) I expect a modern programming language that has a runtime to not do that, correct.

> A segfault is a security vulnerability :) Fair enough. > I expect a modern programming language that has a runtime to not do that, correct. But how do you define "has a runtime"? Java clearly has one - the JVM. Go produces standalone code, though. Or do you say that it has a runtime because it has a garbage collector that is running while the program runs? The original Pascal didn't have a runtime (if you weren't u…

> Go produces standalone code, though.

So if I put the jvm and my .jar file inside a single .zip file java no longer has a runtime?

And since C applications load .so files they do have a runtime?

Having a runtime is independent of the amount of files you need to read to run the program.

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

#450

Post by guappa »

raverbashing wrote: post #240
stavros wrote: post #51

Earlier quoted context omitted.

If it was created on purpose for poor programmers, it seems to have been created to enable poor programmers to write the poor code they wanted to write, instead of making it impossible for poor programmers to write any code. I guess that's the difference, if you want code, no matter the quality, you have one choice, if you want code that's correct, you have another.

Yeah I feel Go is simple in the way people say "C is simple" (without the footgun part) It was created for one purpose and it kinda works but it's clunky. Like there are no fancy front loaders or backhoes and there's a limit on how much out of that form you can get.

But go has plenty of footguns. For example the most common pattern is to just ignore errors.
Post reply on HN