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

331–340 of 508 posts

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

#331

Post by gwd »

whateveracct wrote: post #157
throwaway894345 wrote: post #135

Earlier quoted context omitted.

I agree that the standard library database tooling is really clumsy in a lot of cases, but it's the library implementation at fault, not Go itself. Notably, contrary to your last sentence, you aren't troubling yourself with "weird Go semantics", you're troubling yourself with the semantics of the database stdlib.

Is there a database library that uses reflection that properly descends into type aliases? Probably not, because it isn't always what you want. It's still fundamentally caused by Go's shitty design choices. encoding/json is at fault as well, which is also in the stdlib and a flagship library (basically part of the language - the maintainers wouldn't even extend its struct tag parsing to allow for required fields it's…

> It's still fundamentally caused by Go's shitty design choices.

I mean, come on. In your playground example, one way of using the UUID type inherits its methods and another doesn't. Inheritance is inherently complicated, and if you're relying on it you need to know what you're doing, no matter what language you're using. I wouldn't call that a poor design choice.

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

#332

Post by wronghorse »

whateveracct wrote: post #113
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 just isn't true! Haskell's json/sql marshalling do not use runtime reflection but instead ad hoc polymorphism, so when I create (or even derive automatically!) a marshalling instance, it is pretty easy for me to reason about what will happen statically. Haskell's Generic & newtype-deriving go a long way here, and are good examples of principled abstractions that do not leak. Haskell's conduit (and other streamin…

I believe Rust's serde library is similar when it comes to JSON. It also gives you the option to choose how strictly you want to enforce the types.

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

#333

Post by voldacar »

thedance wrote: post #104
hajile wrote: post #90

Earlier quoted context omitted.

Is there even a single go abstraction that doesn't leak it's guts everywhere?

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.

heh. someone hasnt used a monad.

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

#334

Post by ajross »

btilly wrote: post #190
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.

And the other one is the tendency for Go's design to say "exceptions are allowed for me but not for thee". When I worked at Google I used other languages by some of the same authors and they showed the same design philosophy. Make things with an enforced simplicity, and where there were more special use cases that the language designer needed, they created escape hatches for themselves but not the language users.

Is that wrong, though? I mean, confounding features like exceptions are... useful. That's why they found in languages in the first place. They're just footguns when used "wrongly". So why not have an "escape" hatch for experts that isn't part of the standard/official/blessed paradigm of the language?

I mean, isn't this exactly what Rust did with unsafe? Warn everyone away from it, promise that "normal" code will never need it, but... include it in the language and use it pervasively where needed in the inner workings of the runtime?

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

#335

Post by dnr »

pmarreck wrote: post #302
dnr wrote: post #231

Earlier quoted context omitted.

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

> If you were using Go for those four years, you'd also see very little of the criticisms regularly leveled at Go. That's bullshit. When I worked in the Ruby on Rails space, I saw critisms quite often... for example of the "one size fits all" way-too-large-surface-area library design (see: ActiveSupport) or the "fat model" design trend at the time... I even PRODUCED some of these criticisms myself. Heck, the bug that…

I think you might be reading an unintended meaning into that sentence. I'm talking about the experience of using Go vs. what people write about it, not about your experiences with other languages (which I have no intention of invalidating). I was pointing out that sometimes one can get a skewed perspective of the typical experience by reading blog posts and things (which by definition are written by the more vocal members of a community).

I did use Go professionally for about five years, and read lots of criticisms of it (and still do out of curiosity). Most of them struck me as just not a big deal in practice. When I had to write some list-processing code that could be greatly simplified with generics (a few times per year), I just sighed and typed it out and moved on to a more interesting thing. When I had some repetitive error-handling code, I refactored it or wrote some helper functions. The dependency stuff was annoying when starting a new project, but once you pick a dependency manager/vendoring tool it's fairly straightforward (and of course now this is included).

Certainly, the language and ecosystem has warts and frustrating things. Maybe Elixir has fewer warts, I don't know. But overall the experience of using Go is fairly smooth and boring and productive. The things that people like to complain about don't really register in day-to-day usage. That's not BS, that's my personal experience.

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

#336

Post by munk-a »

usddddd wrote: post #305
munk-a wrote: post #238

Earlier quoted context omitted.

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…

Go will most certainly notify you if a 3rd party API suddenly returns a new error. Typically you would see an assignment mismatch.

Won't this only cause an assignment mismatch if the function previously returns values that you captured? For functions that previously had no return value and suddenly have a return value (so those side effect only functions) I believe golang won't complain?

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

#337

Post by agumonkey »

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…

for js I can understand, based on history it wasn't meant to do much.. so they put a trivial model

Java on the other hand is a lot more surprising.. but maybe they expected to be a third party package from the get go..

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

#338

Post by WalterBright »

alexhutcheson wrote: post #288
twic wrote: post #237

Earlier quoted context omitted.

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

Date & Time need to be baked into the operating system so it only has to be gotten right once, and then every programming system benefits.

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

#339

Post by whateveracct »

gwd wrote: post #331
whateveracct wrote: post #157

Earlier quoted context omitted.

Is there a database library that uses reflection that properly descends into type aliases? Probably not, because it isn't always what you want. It's still fundamentally caused by Go's shitty design choices. encoding/json is at fault as well, which is also in the stdlib and a flagship library (basically part of the language - the maintainers wouldn't even extend its struct tag parsing to allow for required fields it's…

> It's still fundamentally caused by Go's shitty design choices. I mean, come on. In your playground example, one way of using the UUID type inherits its methods and another doesn't. Inheritance is inherently complicated, and if you're relying on it you need to know what you're doing, no matter what language you're using. I wouldn't call that a poor design choice.

    newtype NotRobPike'sUUID = NotRobPike'sUUID UUID deriving newtype (ToJSON, FromJSON)
^ not inherently complicated

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

#340

Post by eximius »

reggieband wrote: post #326
eximius wrote: post #325

Earlier quoted context omitted.

Rust is better _at the problem presented_. Rust not being perfect does not mean other languages can learn from its successes.

> Rust is better _at the problem presented_. What I'm suggesting is that wasn't demonstrated. Go had a real-world used-in-anger problem. That was compared to an idealized solution in Rust. It seems to me that this is an unfair comparison. Fair enough, it is hard to demand anyone who wishes to make a comparison between two programming languages to have built equivalent massive systems that stretch each language to the…

> What I'm suggesting is that wasn't demonstrated.

An in-depth analysis of the respective languages APIs for a particular targeted problem isn't enough?

I won't disagree that readers might make a leap to intuit the author thinks Rust is overall better. But that extra leap doesn't mean he failed to show Rust was better at a particular problem. In fact, that is WHY people would make that un-warranted leap.

> But the point of the article wasn't to compare languages, it was to show the kinds of problems exposed in Go when it is used in massive real-world systems.

I mean, not really. Cross platform file manipulation is, maybe not common, but not obscure. And making a web request reliably is also not something you'd expect to be only needed in massive systems.

Post reply on HN