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

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

#421

Post by dehrmann » Sat, Feb 29, 2020, 4:42 AM UTC

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

Props to him for not having an ego with that. Jodatime even recommends using JSR-310 time for new development.

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

#422

Post by erik_seaberg » Sat, Feb 29, 2020, 4:59 AM UTC

ben509 wrote: post #384

dralley wrote: post #353

Earlier quoted context omitted.

So long as they actually get it "right". Compare to Windows' APIs originally taking UCS-2, then UTF-16, when now we would all rather be using UTF-8.

In fairness to Windows and Java, they weren't wrong. There was no UTF-16, rather, UCS-2 was the accepted standard because the plan for Unicode was to encompass languages in use, not emojis and historical langauges. That changed and we're stuck with that legacy.

Even without emoji, mashing up Chinese, Japanese, and Korean to fit in 21k was never going to happen. It’s sort of like asking Danes to stop spelling their names correctly because we can't afford the extra codepoint for “å”.

https://en.wikipedia.org/wiki/Han_unification#Rationale_and_...

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

#423

Post by nif2ee » Sat, Feb 29, 2020, 5:26 AM UTC

physicles wrote: post #403

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

I’ve written go full-time for the last 3.5 years and it still amazes me that by default the linter doesn’t at least warn about unused/uncaptured return error values.

Golang is such a joke of a language. The compiler won't even compile if there is an unused variable but won't warn you if there is an unchecked error! This language is meant to produce buggy incorrect code that can only be mitigated with writing excessive repetitive tests that have nothing to do with business logic itself.

Golang is probably the biggest embarrassment of a modern programming language ever conceived. Again, if you don't believe me, just start writing your first Kubernetes controller.

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

#424

Post by remus » Sat, Feb 29, 2020, 5:39 AM UTC

taylodl wrote: post #358

yashap wrote: post #306

Earlier quoted context omitted.

Agreed, the author’s main argument is summarized nicely at the end, and it’s a good one: > It constantly takes power away from its users, reserving it for itself. > It constantly lies about how complicated real-world systems are, and optimize for the 90% case, ignoring correctness. > It is a minefield of subtle gotchas that have very real implications - everything looks simple on the surface, but nothing is. “Our use…

That's indicative of a serious attitude problem - I am so smart and can handle the power but you can't. Contrast this with C where everybody is on equal footing. Thanks for posting. This tells me everything I need to know to not get on Mr. Golang's Wild Ride.

I don't think it's necessarily an attitude problem, I think it's a fairly inherent part of writing libraries and APIs. You always need to make trade offs between complexity (or lack of) and correctness, the authors of the go standard library have swung the needle a bit more in the simplicity direction while the authors of the rust standard library have gone a bit more in the correctness direction.

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

#425

Post by nif2ee » Sat, Feb 29, 2020, 5:43 AM UTC

reggieband wrote: post #274

Classic: “There are only two kinds of languages: the ones people complain about and the ones nobody uses.”[1] The thing that bugs me is the comparison to Rust. I mean, the author did caveat that he chose it because Rust provided the best available counter examples to his specific gripes. But my issue is that comparison seems to make a false conclusion: Rust is better. My intuition says if the author used Rust (or any…

>There are only two kinds of languages: the ones people complain about and the ones nobody uses

Repeating this quote again and again won't make it correct.

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

#426

Post by anonsivalley652 » Sat, Feb 29, 2020, 5:56 AM UTC

Animats wrote: post #253

btilly wrote: post #190

Earlier quoted context omitted.

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.

And the other one is the tendency for Go's design to say "exceptions are allowed for me but not for thee". Yes. Exceptions are kind of a pain, but the workarounds for not having them are worse. Passing back "result" types tends to lose the details of the problem before they are handled. Rust is on, what, their third error handling framework? Exceptions have a bad reputation because C++ and Java botched them. You need…

Rust has panic (and unwind_stack) for when things are truly borked.

Exceptions for error conditions are for the birds because they lead to bugs either in the code or in the compiler, and they lead to messy code.

Rust has functional-style error handling where it's possible to run other code, handle or ignore errors whereas exceptions create messy try catch blocks for every caller.

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

#427

Post by edflsafoiewq » Sat, Feb 29, 2020, 5:58 AM UTC

steveklabnik wrote: post #182

klodolph wrote: post #164

Earlier quoted context omitted.

That said… I feel that Rust’s use of WTF-8 for OsString on Windows has resulted in some really nasty problems, especially since OsString doesn’t expose any useful methods for string manipulation. As far as I can tell, Rust’s approach fails to hide any of the complexity, and then adds the additional complexity of a new encoding and conversions on top. I can see that there’s some end goal of being able to work with OsS…

I have felt this pain for sure, but only really once. This is because, in languages with strings as paths I tend to use string manipulation to do operations on paths, but given that virtually all of my OsString usage is paths, which have specific manipulation functions already it’s lesser. This is also why the interface isn’t so rich, there just hasn’t been a lot of demand. That said I think some things are in the pi…

The most common use for string manipulation on OsString is parsing CLI args like --output=/some/path. See eg. clap/#1524.

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

#428

Post by edflsafoiewq » Sat, Feb 29, 2020, 5:58 AM UTC

ChrisSD wrote: post #263

steveklabnik wrote: post #182

Earlier quoted context omitted.

I have felt this pain for sure, but only really once. This is because, in languages with strings as paths I tend to use string manipulation to do operations on paths, but given that virtually all of my OsString usage is paths, which have specific manipulation functions already it’s lesser. This is also why the interface isn’t so rich, there just hasn’t been a lot of demand. That said I think some things are in the pi…

Do you have any more info about what's in the pipeline?

https://github.com/rust-lang/rust/issues/49802

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

#429

Post by Groxx » Sat, Feb 29, 2020, 6:03 AM UTC

masklinn wrote: post #215

delusional wrote: post #94

Earlier quoted context omitted.

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

Checked exceptions were universally rejected not because they are intrinsically bad but because the language support was awful (e.g. could not wrap or abstract over a nested object possibly rethrowing), they were sitting right next to unchecked exception with limited clarity, guidance and coherence as to which was which, and they are so god damn ungodly verbose, both to (re)throw and to convert. Results are so much m…

A very large part of that though is Java not being 'generic' over checked exception types. So if you e.g. build something that supports end-user callback code, you need to either throw Exception (accepting all code but losing all signal as to what's possible) or nothing (forcing RuntimeException boxing).

That's Java. And I agree it is a wildly painful and incomplete implementation. I wish we'd stop conflating it with checked exceptions as a language feature.

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

#430

Post by dwohnitmok » Sat, Feb 29, 2020, 6:11 AM UTC

pron wrote: post #271

Animats wrote: post #264

Earlier quoted context omitted.

They tried, but the hierarchy is not well-designed. You want a clear distinction between "program has an internal problem" and "external thing (network, file, database, remote service, etc.) had a problem". You usually want to catch "external thing had a problem" in whatever wanted to talk to the external thing. "Program has an internal problem" usually requires restarting the program.

There is a clear distinction. RuntimeException (and descendants) is an internal problem (e.g. divide-by-zero); Error (and descendants) is a VM-internal problem (stack overflow, OOM); checked exceptions are external problems (e.g. IO exceptions).

Yeah... but checked exceptions are controversial within the Java community to say the least. Some codebases eschew checked exceptions altogether, rewrapping any checked exceptions they find.

This is in contrast to how sharp of a divide the community observes around Error vs Exception.

In practice there's a lot of Java code that collapses "internal" and "external" errors into unchecked exceptions.