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

431–440 of 526 posts

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

#431

Post by uzerfcwn »

flir wrote: post #190
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…

I see a lot of people say this about exceptions, and I don't have that problem. The exception bubbles up the stack until something catches it. Ok it's a different code path, but it's a very simple one (straight up). So you either catch the exception nearby and do something specific with it, or it bubbles up to a generic "I'm sorry there was a problem please try again later" handler. Honestly makes me wonder what I'm…

Exceptions are difficult to discuss because different languages implement exceptions differently, each with their own downsides. That said, I don't think anyone has an issue with bubbling. Even sum type proponents love Rust's ? shorthand, because it makes it easier to propagate Results up the stack.

The big issue with exceptions in C#, Python and JS is that they're not included in function signatures, which means you have to look up the list of possible exceptions from documentation or source code. This could be amended with checked exceptions like Java, but it allegedly doesn't mesh well with the type system (I haven't personally written Java to confirm this). And then there's the C++ crowd that slaps noexcept on everything for possible performance gains.

Personally, I like the way Koka does exceptions with algebraic effects and type inference. It makes exceptions explicit in function signatures but I don't have to rewrite all the return types (like in Rust) because type inference takes care of all that. It also meshes beautifully with the type system, and the same effect system also generalizes to async, generators, forking and other stuff. Alas, Koka is but a research language, so I still write C# for a living.

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

#432

Post by pas »

eikenberry wrote: post #386
pas wrote: post #234

Earlier quoted context omitted.

> what makes someone go such a great length to bash ... """ Inherent complexity does not go away if you close your eyes. When you choose not to care about complexity, you're merely pushing it onto other developers in your org, ops people, your customers, someone. Now they have to work around your assumptions to make sure everything keeps running smoothly. And nowadays, I'm often that someone, and I'm tired of it. """…

That quote sounds like an argument against Rust, not GO. Rust is a complex language and that complexity doesn't go away if you close your eyes to it either. All complexity adds to project complexity.

The implicit argument is that there's some irreducible non-negotiable project complexity in real-world software, and the explicit argument in the post is that you can either put it into the language/compiler or keep it in wetware.

The supporting argument in the text is that even simple things like downloading a file can get hairy very fast. Networks are complex, HTTP, IPv4/v6, DNS - it's always DNS! - filesystems, permissions, running out of space, computer runs out of battery, etc.

Probably a better argument would be to focus only on application logic (type system, error handling, syntactic-semantic ergonomics) and show that a complex piece of Go [like the k8s persistent volume controller] can be written in a nicer, more maintainable, safer way in Rust.

Of course not all Go code achieves Kubernetes-level complexity. And I think it makes sense to pick the right tool for the job, which is whatever the team/programmer is productive with. (And here productivity is measured based on how well the resulting code/software solves the business case. And basically if there's no need for Rust-level safety/quality/maintainability, or if there's an explicit need for Go-level cheaper hackability, then that's a great result business-wise.)

The important corollary of this is that business requirements tend to change, yet software has inertia and that's roughly how we ended up with insert famously bad software that got wildly popular unexpectedly (for example Windows, Macromedia/Adobe Flash and the infamous plugin, random low-level crap in appliances, and adjacent to that the Bluetooth stack that got rewritten in Rust for Android).

So - of course - for society it would be amazing if software would be better from the start. (Duh!)

Also, one more thing I think worth mentioning, is that the argument about the lack of information in code at callsites in Go (is something passed by reference or by value), how hard it is to keep boundaries (immutability) is basically an argument for making this complexity up-front and visible. Hence Rust looks complex. (And again, the argument is that it's there even if Go hides it.)

https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html

https://github.com/kubernetes/kubernetes/blob/60c4c2b2521fb4...

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

#433

Post by B-Con »

nulld3v wrote: post #101
richbell wrote: post #75

Earlier quoted context omitted.

I wish the discourse that Go is a "simple" language would die. Despite its veneer, once you start writing Go it quickly becomes apparent that it isn't simple. Hidden complexity and footguns are abundant (e.g., https://archive.ph/WcyF4 ). It's nevertheless a useful language, and I use it quite a bit, but it's not "simple".

This 100%, I was just about to type a long rant up about this. There are so many weird parts of the language that took me forever to grasp, and in many cases, I still don't have an intuitive grasp of things. And plenty of other examples that aren't in that article: - You have a struct with an embedded interface. Does the outer struct satisfy the embedded interface? And can I type assert the outer struct into whatever…

The first is simply a question about what an embedded interface is. Any way in which you learned about this feature should also answer the question.

The second isn't related to Go.

The third I can see as being a bit confusing, but isn't it something you try once and then remember forever?

Here's one: Creating a new variable via shorthand that shadows a variable in an outer scope - that can be confusing and an easy mistake to make.

But broadly, I would strongly advocate that it is simpler than most other languages, even if it has some quirks. In the same vein of "If I had more time, I'd write a shorter letter", sometimes it takes a bit of time to understand why something is simpler than the alternatives. No language has zero ramp-up. Go doesn't exist in a vacuum, you have to compare it's learning curve and complexity to other languages.

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

#434

Post by 9rx »

the_gipsy wrote: post #420
wbl wrote: post #415

Earlier quoted context omitted.

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.

> I'm saying that this tenet is misleading.

Doesn't that go without saying? There is no tenet that isn't misleading when presented to a general audience. Fair that if you come from a position where you understand the full context and nuance under which the tenet was built then you should be able to free yourself from being mislead, but, of course, this time is no exception.

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

Where several packages find interface commonality, there is no doubt a set of "primary" functions that roll up shared functionality around that interface. The package of shared functions is understood to be the consumer under that scenario.

Where several packages stumbled upon the same interface without any shared functionality, copy/pasting is warranted. In this case, while the interfaces may look the same, they do not carry the same intent and that needs to be communicated. Another oft-misunderstood tenet, do not repeat yourself, does not imply avoid repetitive code.

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

#435

Post by OtomotO »

jll29 wrote: post #427
quotemstr wrote: post #323

Earlier quoted context omitted.

One of my dream projects is creating a Rust stdlib based solely on panics for error handling. Sure, it'd be incompatible with everything, but that might be a feature, not a bug.

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"

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

#436

Post by rand_r »

swiftcoder wrote: post #43
rand_r wrote: post #41

Earlier quoted context omitted.

> never handled correctly I’ve seen this argument, but if you look at real golang code and examples, it’s just a bunch of “if err nill” copy pasta on every line. It’s true that handling errors is painstaking, but nothing about golang makes that problem easier. It ends up being a manual, poor-man’s stack-trace with no real advantage over an automatically generated one like in Python.

Which could be solved in one swipe by adding a Result sum type, and a ? operator to the language. This is more a self-inflicted limitation of Go, then a general indictment of explicit error handling.

Nothing prevents explicit error handling in Python either. Forcing explicit error handling just creates verbosity since no system can functionally prevent you from ignoring errors.

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

#438

Post by coldtea »

jchw wrote: post #353
coldtea wrote: post #257

Earlier quoted context omitted.

> If anyone tells you C is "boring", that's just plain and simple bullshit. C gives you undefined behavior, buggy compilers (yes even for simple C code, MSVC is especially bad at plain C but there are other offenders) and the world's worst standard library for manipulating strings. Boring doesn't mean "has no issues" or "takes care of everything for you". It means, stable syntax, lots of mature tooling and compilers,…

> It means, stable syntax, lots of mature tooling and compilers, and any problems the language has are well known. In case of C what it really means is that the compiler codebases are extremely old and sometimes in rather bad shape. Speaking of stable, C hasn't just stayed still: The C23 standard adds plenty of fun new things, like an annotation for unreachable code. Modern C has threads and synchronization primitive…

>In case of C what it really means is that the compiler codebases are extremely old and sometimes in rather bad shape

Statistically nobody writing C code gets to worry about a compiler error.

>Speaking of stable, C hasn't just stayed still: The C23 standard adds plenty of fun new things, like an annotation for unreachable code. Modern C has threads and synchronization primitives, #embed, complex numbers, and plenty more.

Compared to any other modern language, this is so still that C could make a living as a living statue...

>By any standard you can come up with, C is just plain-and-simple not a boring reliable solution.

C is the de facto language that's considered a boring and reliable solution.

The points made are less substance and more pedantic nit picking ("yeah, it's a language with the most mature and relied upon compilers, but the code is old dawg", "yeah, it's one of the most convervative languages to change, and you can compile decades old code just fine, but they added some stuff in C99, C23, etc").

And Rust is still very niche, single compiler, quickly changing affair. Compared to C and C++ adoption (which is a big yardstick of a tech being "boring") it doesn't even register.

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

#439

Post by coldtea »

surgical_fire wrote: post #320
coldtea wrote: post #201

Earlier quoted context omitted.

> I don't understand why people get so passionate about programming languages. They are tools. Because when you're a professional programmer, tools are a huge part of what you do and how you do it, same like a race driver would need to be passionate about cars. It's just that for an e.g. carpenter, tools are more or less standadized and simple enough to evaluate. If saws and hammers and routers had as much variety as…

> Because when you're a professional programmer, tools are a huge part of what you do and how you do it, same like a race driver would need to be passionate about cars. I am a professional programmer. Have been one for more than two decades. And perhaps for professionalism, I think there is no space for passion when it comes to choosing the tools of the trade. Passion would make me pick unsuitable tools because well,…

Being passionate about using the right tools for the job is still being passionate about tooling.

Passionate with tooling is not synonymous to irrational about tooling. It means invested in the matter of the tools you use.

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

#440

Post by [deleted] »

stouset wrote: post #388
LinXitoW wrote: post #261

Earlier quoted context omitted.

One very subjective, very irrational factor for my borderline hate for Go is that for years the Go zealots gaslighted everyone about every single part of Go. Anything that Go did, no matter if it was the most basic implementation or if other languages already did it (better), was essential, the best and only way to solve that issue. Anything Go did not do was superfluous and downright a conspiracy by Big Complexity t…

Dear christ yes. “Go is designed as a systems programming language” has been retconned so that “systems” is redefined to mean programs talking over a network? “Real programs won’t use repetitive error handling, but build on top of it.” I don’t think this one needs further explanation. “Go doesn’t need xyz.” This is just the slow and painful process of the golang community realizing one at a time why other languages h…

[deleted]
Post reply on HN