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

411–420 of 526 posts

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

#411

Post by 9rx »

the_gipsy wrote: post #408
wbl wrote: post #379

Earlier quoted context omitted.

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

The actual first paragraph states:

> This page collects common comments made during reviews of Go code, so that a single detailed explanation can be referred to by shorthands. This is a laundry list of common style issues, not a comprehensive style guide.

The document does not assert that you must not return interfaces or that it is incorrect to return interfaces. It only indicates that returning interfaces at inappropriate times has been a recurring issue found during code review. Sometimes returning an interface truly is the right choice, but when it isn't...

Like most adages in programming, the aforementioned tenet holds validity in many cases, but, as always, "use your noggin" applies.

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

#412

Post by AnimalMuppet »

guappa wrote: post #383
AnimalMuppet wrote: post #347

Earlier quoted context omitted.

A general purpose language must be one that you cannot cause to segfault? That's a rather... unique perspective.

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 using UCSD, which generated p-code), and yet you couldn't segfault it.

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

#413

Post by [deleted] »

the_gipsy wrote: post #346
9rx wrote: post #325

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 Go functions also accept a tuple on input. While theoretically you could pass an error, or a pointer to an error for assignment, it is a stretch to claim it is for errors.

Yes exactly, that rather useless feature just makes the whole thing even weirder.

[deleted]

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

#414

Post by 9rx »

the_gipsy wrote: post #346
9rx wrote: post #325

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 Go functions also accept a tuple on input. While theoretically you could pass an error, or a pointer to an error for assignment, it is a stretch to claim it is for errors.

Yes exactly, that rather useless feature just makes the whole thing even weirder.

A function that passes tuples, or multiple arguments as they are more commonly referred to as, is not particularly weird, and has pretty much been the norm since the addition of functions to programming languages. But you are right that languages whose functions only accept tuples, but not return tuples, is a strange curiosity. In practice, you end up with developers packing multiple, unrelated items into a single variable to work around the limitation, which then questions why not do the same for input?

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

#415

Post by wbl »

the_gipsy wrote: post #408
wbl wrote: post #379

Earlier quoted context omitted.

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

It does matter that packages and functions are different.

It also matters what the io package actually does. https://pkg.go.dev/io . The io package has a very limited number of functions that return Readers. The vast majority of its functions take Readers or Writers as arguments and do useful things with them: e.g. Copy or LimitedReader. Most of the interfaces it defines (ReedSeeker, ReadWriteSeeker, etc) aren't instantiated by anything in it.

os implements Reader and Writer for filehandles. net does the same for sockets etc.

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

#416

Post by packetlost »

miki123211 wrote: post #391
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 was a proposal for a `try`, which I still think should have been adopted. Under that proposal, `someComplicatedExpression(try(functionReturningError()))` would be converted to `foo,…

You would need some form of compile-time reflection/specialization to implement that properly (what if the second return value isn't an error? What if there's only 1 return value?). Further, you would lose the ability to add context to the error branch via fmt.Errorf, which seems rather critical to understandable error conditions.

I'm not sure I would be satisfied with any implementation of try as the language is now, I assume the Go language team would probably feel the same.

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

#417

Post by dfawcus »

guappa wrote: post #151
underdeserver wrote: post #125

Earlier quoted context omitted.

Uhh, maybe. Where is the tradeoff analysis? Yeah, you might regret using Go when some zero value you forget to fill in somewhere pops up later and ruins your pipeline. But are you considering all the issues that didn't pop up because you chose Go? Java's boilerplate code? Rust and C++'s lifetime analysis and memory management? C's lack of tooling? Python/Typescript's runtime errors? Functional languages' tiny employe…

Go is very boilerplate. It requires at least 3 lines of error checking every 1 line of actual code. Also it doesn't have packed structs so it's completely incapable of doing low level networking or to handle binary files (you can of course do all the bitwise operations yourself… but is it sensible to use a language that is more error prone than C in 2024?). Also due to its lack of A LOT of system calls, you will need…

How low level a networking use do you desire?

I certainly managed to use it to implement a protocol over UDP without any issues, that having byte and bit packed values.

Or do you wish to have something similar to C with structs and (endian dependent) bitfields overlaid on packet buffers?

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

#418

Post by dfawcus »

sterlind wrote: post #250
radicalbyte wrote: post #52

Earlier quoted context omitted.

Go is an iteration of C, not of Java. It's a really bad choice for situations where Java is a good choice as not only is the language limited, the ecosystem around it is also very limited when compared to say Java. I'm maintaining Go, C# and TypeScript as my main languages as that gives me excellent coverage. I'll add Rust to the mix when I have 6 months where I can accept the productivity drop or have a project wher…

How is Go an iteration of C? You can't use Go to write a kernel, or program a microcontroller, or for high-frequency trading or a web browser or a tensor library or a language run-time. It's either a bad idea or simply impossible, depending. Someone please explain to me what's C-like about Go other than vaguely the syntax and that it compiles to machine code.

C -> Alef -> Limbo -> Go ?

With influences from other languages along the way.

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

#419

Post by amai »

zaptheimpaler wrote: post #392
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.

The present is already mobile but the backends serving those mobile devices run on servers. There's also no reason mobiles can't run Rust/Go/Python - Android already runs Java.

You are right there is no reason mobiles can't run Rust/Go/Python. But actually they don't, because there is no infrastructure and no tooling to build mobile apps using these languages. And this is the big oversight of the creators of these languages. All these languages we love so much as developers will die. Not because they are missing generics or error handling or coroutines or a static type system or other nifty language features. They are simply missing tools to create mobile apps.

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

#420

Post by the_gipsy »

wbl wrote: post #415
the_gipsy wrote: post #408

Earlier quoted context omitted.

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

It does matter that packages and functions are different. It also matters what the io package actually does. https://pkg.go.dev/io . The io package has a very limited number of functions that return Readers. The vast majority of its functions take Readers or Writers as arguments and do useful things with them: e.g. Copy or LimitedReader. Most of the interfaces it defines (ReedSeeker, ReadWriteSeeker, etc) aren't inst…

It doesn't matter with `error` because it's returned everywhere, both functions and from packages by proxy.

I'm not arguing that the tenet should be held true, to be clear. I'm saying that this tenet is misleading. If you can, return a concrete type. If several packages consume the same interface, then you it's not reasonable to define the interface at the consumer because you'd just have to copypaste it.

Post reply on HN