I Want Off Mr. Golang's Wild Ride • Hacker News Board

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

#231

Post by dnr » Fri, Feb 28, 2020, 7:36 PM UTC

pmarreck wrote: post #152

thedance wrote: post #104

Earlier quoted context omitted.

There aren't any abstractions in any language or library that don't leak everything about what they are trying to hide as well as everything about their own implementation. That's just life. It's impossible to hide complexity. Whatever wraps one thing will be strictly more complex than the wrapped thing was.

This is funny because after almost 4 years of working with Elixir and watching Go from arms’ length, I literally see NONE of the criticisms regularly leveled at Go. This is not an exaggeration. In fact, Elixir has few criticisms at all to begin with, and it’s driven very large sites already at this point. (Yeah, it can’t compile easily distributable self contained binaries. It’s not (yet) designed for that.) Not inte…

If you were using Go for those four years, you'd also see very little of the criticisms regularly leveled at Go. What you see on the internet is the union of everyone's complaints and frustrations. Each individual sees only some of those, maybe even none depending on the type of work they're doing. And the ones that are generally happy don't tend to post big rants, so the overall impression of an outsider can be pretty skewed.

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

#232

Post by munk-a » Fri, Feb 28, 2020, 7:37 PM UTC

pcwalton wrote: post #189

Karunamon wrote: post #107

Earlier quoted context omitted.

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.

Go doesn't ensure that you handle errors, if the function doesn't have a return value other than the error. The compiler will happily let you silently drop the result of os.Mkdir() on the floor.

I also generally think that writing boilerplate code is unproductive - golang's error system relies on people pedantically writing boiler plate code constantly among their logic - the result is to obscure the actual logical drive of the code.

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

#233

Post by The_Colonel » Fri, Feb 28, 2020, 7:38 PM UTC

umvi wrote: post #31

The_Colonel wrote: post #17

Earlier quoted context omitted.

What is it then if not a con? I mean, C# not running well on unix systems was immediate show stopper for a lot of projects but we can't call this a "con"?

It's only a con in the context of your use case and requirements. It's not a con for everybody, so in the general case I would instead call it a limitation. Every piece of software in the world has limitations. The limitations are only cons in the context of your requirements. Is it a con of SQLite that it is missing features when using it with the JFFS2 filesystem? Maybe, depends on your use case. If your system doe…

That's just word play.

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

#234

Post by typon » Fri, Feb 28, 2020, 7:39 PM UTC

Thaxll wrote: post #212

pcwalton wrote: post #189

Earlier quoted context omitted.

Go doesn't ensure that you handle errors, if the function doesn't have a return value other than the error. The compiler will happily let you silently drop the result of os.Mkdir() on the floor.

I'm no Rust expert, but Rust doesn't enforce that either. There is no language that enforce error checking afaik.

You have to either propagate the error up the stack or face a panic. Rust does force you to deal with the error.

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

#235

Post by dpc_pw » Fri, Feb 28, 2020, 7:40 PM UTC

klodolph wrote: post #149

With the path example… just try to combine this with flags, so we do something like: $ ./my_program --file="$(printf "\xbd\xb2\x3d\xbc\x20\xe2\x8c\x98")" Well, just try to write the program that does that in Rust, without using some option-parsing library that hides all the details, and then try to figure out how to get it to work equally on Windows. To spoil the answer, it turns out that OsString only exposes a coup…

If you want to half-ass it like Go you go https://doc.rust-lang.org/std/ffi/struct.OsString.html#metho... or https://doc.rust-lang.org/std/ffi/struct.OsString.html#metho... if you want to potentially get an error.

If you want to deal with bytes / invalid Unicode, you go https://doc.rust-lang.org/std/ffi/index.html#conversions

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

#236

Post by SpaceManNabs » Fri, Feb 28, 2020, 7:41 PM UTC

I have become annoyed at go for completely different reasons than OP. I wrote my blog using go as the backend a few years ago. Deployed it on Google App Engine. Every time Go updates or the App Engine SDK updates, it is a super pain to update my site. I almost want to throw it all away now that Go is handling dependencies in a completely new matter.

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

#237

Post by twic » Fri, Feb 28, 2020, 7:41 PM UTC

whatever_dude wrote: post #37

fhood wrote: post #22

The author spent a lot of time dwelling on Window's filesystems, at which point many of the readers got bored and started commenting. There are actually a couple of excellent points in here, the majority of which relate to Go's tendency to just be silently completely wrong in its behaviors from time to time, and is absolutely packed with hidden gotchas.

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 but fundamentally broken API.

It took a long time for us to get comfortable with the level of complexity in Joda-Time, but now nobody thinks a serious date/time API can be substantially simpler.

It sounds to me like you and the author are saying that Go does this balking systematically.

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

#238

Post by munk-a » Fri, Feb 28, 2020, 7:42 PM UTC

Thaxll wrote: post #219

hota_mazi wrote: post #108

Earlier quoted context omitted.

> the majority of which relate to Go's tendency to just be silently completely wrong 100% right on. Go's handling of errors is often ridiculed for its verbosity and lack of thought, but the fact that Go makes it so easy to sweep errors under the rug has real and devastating consequences in the real world. Go programs are much less safe than programs written in Rust or Java for that reason.

"Go programs are much less safe than programs written in Rust or Java for that reason." This is plain wrong. ( Rust included )

Being unaware of an exception thrown by a function when calling it in Java will cause compilers to bark at you - while doing the same in go will work until it doesn't.

I think this is even more insidious with changes in third party code over time though - did the package your gigantic product uses to validate that a phone number is in European time just add an error return value to a function that previously had none? I hope you are reading all the change logs closely because in GoLang nothing will bop you over the head for suddenly not supporting a new `err` response that wasn't previously returned by a function, and if that error is triggered (for whatever reason) it won't be at all visible in your system until something major breaks inexplicably.

I really dislike forcing users to be proactive about handling errors, some folks with wrap a System.in call in try { } catch () {} - but these are a clear anti-pattern that can be actively flushed out, tracking down someone forgetting to check the return value of mkdir is much harder.

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

#239

Post by hajile » Fri, Feb 28, 2020, 7:44 PM UTC

Thaxll wrote: post #207

pmarreck wrote: post #152

Earlier quoted context omitted.

This is funny because after almost 4 years of working with Elixir and watching Go from arms’ length, I literally see NONE of the criticisms regularly leveled at Go. This is not an exaggeration. In fact, Elixir has few criticisms at all to begin with, and it’s driven very large sites already at this point. (Yeah, it can’t compile easily distributable self contained binaries. It’s not (yet) designed for that.) Not inte…

The reason is because Go is very popular where Elixir is not, if Elixir was standing where Go is now it would be pretty much the same, I guaranty you that.

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.

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

#240

Post by bsdubernerd » Fri, Feb 28, 2020, 7:51 PM UTC

pmarreck wrote: post #146

Go needs good criticisms like this. I will never understand why this language is so popular.

It's due to the same reason Rust is: it's backed by a large popular company investing in the language and being loud about it, which leads to a rapidly growing mindshare and ecosystem around it, which is essential for adoption.

This is not meant as a criticism toward go or rust: the history shows several cases where this happened before irregardless of the technical merits.

A language still needs to become popular, it's not like we're lacking great languages nowdays. It's certainly easier if you're big and can provide the founding around it.