Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Want Off Mr. Golang's Wild Ride

fasterthanli.me

Post reply on HN
Print view View original

281–290 of 508 posts

Re: I Want Off Mr. Golang's Wild Ride

#281

Post by zug_zug »

_bxg1 wrote: post #83

I think the mistake may be assuming that Go is meant to be a general-purpose language. From what I can tell, it's purpose-built to be a "web services" language, and its design-decisions center around that. What does that mean? - It's expected to be run on Linux servers (not Windows) and developer workstations (probably not Windows). - It needs to be fast but not blisteringly fast. Micro-performance concerns like the…

Except docker is written in go. Guess they never got the memo to not use go for non-webservices...

Re: I Want Off Mr. Golang's Wild Ride

#283

Post by apta »

Karunamon wrote: post #107
Seenso wrote: post #103

Earlier quoted context omitted.

> Well you should handle the error in the first place. That's like saying you should just write bug-free code in the first place.

Go goes out of its way to ensure you handle the error. You have to do something with that err return, otherwise it's a compile error. If you're just throwing it away without checking, we've gone from the mere mistakes everyday developers make to irresponsibility. There's a reason most go code is littered with "if err != nil" on nearly all function calls.

No it won't:

    fmt.Println("foo")
You're not forced to handle the error. Not to mention more obscure cases like

    a, err1 := foo()
    if err1 != nil { return err1 }
    b, err2 := bar()
    if err2 != nil { return err1 } // bug

Re: I Want Off Mr. Golang's Wild Ride

#284

Post by jjoonathan »

kodablah wrote: post #167
jjoonathan wrote: post #59

Earlier quoted context omitted.

He presented them as typical examples, not as issues of such importance as to independently make him off the "wild ride." He also compared them to alternatives that he found favorable, which specifically addresses the idea that alternatives are worse. It could be reasonable to disagree with the content of his argument, but it didn't have either of these structural problems.

> it didn't have either of these structural problems. Disagree...the volume/importance of grievances should be directly proportional to willingness to abandon. That a few examples can be provided isn't an indictment of the ecosystem anymore than it would be if I did the same to those the OP found favorable.

He chose to go deep instead of broad. That was an editorial tradeoff to keep the length this side of an encyclopedia, and I don't think it's fair to criticize him for it unless you're also going to argue that the generalization he asked us to take on faith doesn't hold -- in other words, that the example he gave in which a simplifying API decision backfired is atypical.

I haven't used much Go, but the bit that I've played with gave me the distinct impression that "opinionated simplification" wasn't just common, it was the defining quality of the entire language, which would strongly suggest that OP's complaint would easily generalize to a hundred other APIs. Is that not the case?

Re: I Want Off Mr. Golang's Wild Ride

#285

Post by apta »

shazow wrote: post #211
hota_mazi wrote: post #132

Earlier quoted context omitted.

Go does absolutely nothing to ensure you handle the error. The only thing in Go source code that you see more often than the boiler plate "if err != nil" is "a, _ = foo()". It's all too easy to ignore an error in Go.

> Go does absolutely nothing to ensure you handle the error. Go has many community linters available, https://github.com/kisielk/errcheck is popular for checking unhandled errors. If you'd like a combo-pack, check out https://github.com/golangci/golangci-lint which includes all of the popular linters in a configurable way.

Those linters won't catch everything. There are cases that will slip by. Rust's error handling, as well as exceptions are both strictly superior to golang's error handling.

Re: I Want Off Mr. Golang's Wild Ride

#286

Post by AnimalMuppet »

akavi wrote: post #98
delusional wrote: post #94

Earlier quoted context omitted.

It's curious that after pretty universally rejecting checked exceptions, they have now returned as result.

Result types are genericizable in a way that checked exceptions aren't (IIRC), which is huge for ergonomics.

Can you give an example of how you think this helps?

Re: I Want Off Mr. Golang's Wild Ride

#287

Post by apta »

Thaxll wrote: post #216
hota_mazi wrote: post #132

Earlier quoted context omitted.

Go does absolutely nothing to ensure you handle the error. The only thing in Go source code that you see more often than the boiler plate "if err != nil" is "a, _ = foo()". It's all too easy to ignore an error in Go.

This is fud, I've never seen in Go code people dropping the err with _. The reason why you don't see that is because you have to be explicit about that, it's not something you forget it's done on purpose which obviously no one does.

Just because you haven't seen it doesn't mean it doesn't exist. It's very easy to mishandle errors in golang, I've seen it several times now.

Re: I Want Off Mr. Golang's Wild Ride

#288

Post by alexhutcheson »

twic wrote: post #237
whatever_dude wrote: post #37

Earlier quoted context omitted.

This. I like, and agree, with the conclusion, and wish more people would get to it: > Over and over, Go is a victim of its own mantra - “simplicity”. (...) > It constantly lies about how complicated real-world systems are, and optimize for the 90% case, ignoring correctness. > This fake “simplicity” runs deep in the Go ecosystem. I've always liked simplicity and on my own design, I tend to go for abstraction; trying…

A post about fixing Date in JavaScript got me thinking about why it took so long for languages to get good date/time APIs. I think it's because it took so long to accept that date and time really is complicated. If you sit down and work it out carefully, you end up with Joda-Time (more or less - not in all the details, but in the set of abstractions). If you balk at that and make something simpler, you make a subtly…

The author of Joda-Time actually thinks that even Joda-Time didn't get it quite right, and believes the java.time libraries in Java 8 and above (aka JSR-310[1]) are better than Joda-Time: https://blog.joda.org/2009/11/why-jsr-310-isn-joda-time_4941...

It turns out that abstractions for time are really hard to get right.

[1] https://jcp.org/en/jsr/detail?id=310

Re: I Want Off Mr. Golang's Wild Ride

#289

Post by Tyr42 »

0xdeadbeefbabe wrote: post #145
fhood wrote: post #35

Earlier quoted context omitted.

I surprises me that most people here aren't up in arms in agreement with this point. Code that is silently incorrect is an absolute disaster on an enterprise level. I spend a lot of time writing seemingly redundant double and triple error checking into my code, only to have the designers of the LANGUAGE say, "yeah, most filepaths are utf-8 so seems good enough to me".

Isn't that the standard library and not the language?

Go the language lets the Go the standard library play with things that nothing else can. If you can't implement it yourself, is it really a library and not just part of the language runtime?

Re: I Want Off Mr. Golang's Wild Ride

#290

Post by pmarreck »

Thaxll wrote: post #262
hajile wrote: post #239

Earlier quoted context omitted.

Erlang is a stable language that has been around for a long time (almost 35 years now). It's used for way more mission-critical code than golang is ever likely to be used for. It's weird syntax and performance tradeoffs are very well known, but you still won't see anywhere near the number of complaints that you see against golang.

Erlang is less and less used in telecoms and it's the only place if was really used, lot of things have switch to C/C++/Java. As for the reason why it has less complains it's pretty simple no one uses Erlang and it's a niche, it's not a generic purpose language. I can't even tell a single known application or library written in Erlang.

Ah yes. Whoever's heard of Whatsapp, Pinterest, Discord, and Goldman Sachs? https://codesync.global/media/successful-companies-using-eli...
Post reply on HN