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

131–140 of 526 posts

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

#131

Post by dondraper36 »

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…

I am not going to answer the questions, but this is a very strange complaint, to be honest.

For example, passing by value/passing by reference is something covered immediately in the Go FAQ document once and for all. Everything is passed by value in Go, that is it. There should be no confusion at all. If you spend 15 minutes reading Russ Cox's post on the internals of the most common data types, you will also understand what data structures have implicit pointers under the hood.

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

#132

Post by dataflow »

underdeserver wrote: post #125
wokwokwok wrote: post #83

Earlier quoted context omitted.

> I guess I feel bad for people who are particularly sensitive to the areas that Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives. Well, that’s a stellar endorsement of the article, because that’s literally the point they’re making. You’ll use go. …and then regret it. …but by then it’ll be too late, and you’re stuck with it. I think the author makes a comp…

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…

Thoughts on C#?

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

#133

Post by sureglymop »

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 something but are not CS grads nor working as programmers. If you're only gonna use the language every once in a while you won't remember what a vtable is, how and when things are dropped etc. I understand that "the perfect language" doesn't exist but I think both Go and Rust brought amazing things to the table. I can only hope someone takes inspiration from both and creates a widely usable, simple programming language.

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

#134

Post by maleldil »

quotemstr wrote: post #91
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…

Hard disagree. Exceptions are actually good. They make code clear and errors hard to ignore. I've written a ton of code over decades in both exceptional and explicit-error languages and I'll take the former every day. There's no function color problem. No syntactic pollution of logic with repetitive error propagation tokens. Also, exception systems usually come with built in stack trace support, "this error caused by…

> Have you read any real world Rust code? Junior developers just add unwrap() until things compile.

If you really don't like unwrap[1], you can enable a linter warning that will let you know about its uses to flag it during code review. You know exactly where they are and when they happen. Exceptions are hidden control flow, so you rely on documentation to know when a function throws.

> Writing exception safe code is a matter of using your language's TWR/disposable/RAII/etc. facility. A programmer who can't get this right is going to bungle explicit error handling too.

Rust has RAII, so you don't have to worry about clean-up when returning errors. This is a Go problem, not Rust.

[1] https://blog.burntsushi.net/unwrap/

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

#136

Post by josefx »

chikere232 wrote: post #56
voidUpdate wrote: post #4

I really wanted to like go, and I tried to write a discord bot using it, but the very opinionated brace style (which isn't the one I prefer to use), and the fact that I struggled to much to try and split my code across two files kinda turned me off it. In the end I just went back to python

Python has the most opinionated brace style though

You can abuse list comprehensions to enclose your code in [ ] instead of having to deal with all that whitespace.

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

#138

Post by Lucasoato »

yapyap wrote: post #130

Okay so I’m wondering, if you’re not in the Golang universe yet, what language is better to start with learning?

I'm curious as well. Are there alternatives to Go in some fields completely dominated by it? (like Kubernetes controllers/operators)

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

#139

Post by OtomotO »

quotemstr wrote: post #128
OtomotO wrote: post #123

Earlier quoted context omitted.

Bah, no, I hated that you had to wrap basically every code block in a try/catch in Java, because the underlying lib could change and suddenly throw a Runtime-Exception. At the same time Checked Exceptions were a nightmare as well, because suddenly they were part of the contract, even though maybe wrong later.

Checked exceptions are more trouble than they're worth. That doesn't make exceptions in general bad.

As said, I don't like the wrapping of about everything with try/catch

Sure, you can only do it way up the stack, but that's not enough quite often.

If you can only do it all the way up, I find it ergonomic.

Maybe I should experiment more with catch unwind in Rust.

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

#140

Post by eru »

KingOfCoders wrote: post #102
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".

Yes, like "Opening Brace Can't Be Placed on a Separate Line" (from your link). Everyone can read Go code and understand what happens. There are some minor difficulties like func (*A) vs func (A).,

RiscV assembly is even easier to read by that metric.
Post reply on HN