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

341–350 of 508 posts

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

#341

Post by WalterBright »

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…

> Resource Acquisition Is Initialization is fine

It doesn't work well at all for transactions, where both A and B must succeed or neither.

https://dlang.org/articles/exception-safe.html

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

#342

Post by agumonkey »

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.

> , they created escape hatches for themselves but not the language users.

man, seriously disappointing..

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

#343

Post by lanius »

For those unaware, the title is a reference to a hilariously long user-created ride in Roller Coaster Tycoon 2 titled "MR BONES WILD RIDE" [1]. The ride's exit connected to its entrance, so passengers were forced to repeatedly ride the roller coaster forever.

[1] https://knowyourmeme.com/memes/mr-bones-wild-ride

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

#344

Post by munchbunny »

jgon wrote: post #329
pron wrote: post #271

Earlier quoted context omitted.

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

Maybe I am misunderstanding your point here, but isn't making RuntimeException be the base for internal problems the issue the parent poster was talking about? Divide by zero is an obvious case, but what about when invalid or misconfigured data of some type is passed into a method? This is "internal", ie inside the program, unless I am misunderstanding your terminology? It isn't an external problem, so it isn't a che…

You can always make input validation errors a checked exception with your own exception type. It'll accomplish what you're trying to accomplish. It's not perfectly clean because it'd be nice if you could stick it under the "IllegalArgumentException" part of the inheritance tree, but it does what you're asking for.

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

#345

Post by throwaway894345 »

whateveracct wrote: post #339
gwd wrote: post #331

Earlier quoted context omitted.

> 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

I'm not sure you're making the point you think you are.

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

#346

Post by reggieband »

eximius wrote: post #340
reggieband wrote: post #326

Earlier quoted context omitted.

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

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

It isn't the same. There is another cheeky quote I can paraphrase: Everyone has a plan until they get punched in the face. He is comparing a Go implementation that has been punched in the face in a real-world use case against a Rust implementation that was sitting on the sidelines.

If the point of the article (and the title) was "Go file system API vs Rust API, an in-depth analysis" I would not have made my comment. The thesis of the article appeared to be "pains I felt in Go when I used it on hard real-world problems". All of his points seem to stand completely fine when you remove the comparisons to Rust. For that reason I would have preferred to remove them.

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

#347

Post by dellinspiron »

(Comparing a function in Rust's sdtlib to Go's:) > Of course there's a learning curve. Of course there's more concepts involved than just throwing for loops at byte slices and seeing what sticks, like the Go library does. > But the result is a high-performance, reliable and type-safe library. > It's worth it.

When I first saw Go, I was blown away. Not by its features, but rather the lack thereof. It seemed like one last "Hail Mary!" from the C programming community to get "back to basics". But, as the author showcases, the time when programming was about manipulating arrays with pointers is, if not behind us, hopefully on its way out.

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

#348

Post by jgon »

munchbunny wrote: post #344
jgon wrote: post #329

Earlier quoted context omitted.

Maybe I am misunderstanding your point here, but isn't making RuntimeException be the base for internal problems the issue the parent poster was talking about? Divide by zero is an obvious case, but what about when invalid or misconfigured data of some type is passed into a method? This is "internal", ie inside the program, unless I am misunderstanding your terminology? It isn't an external problem, so it isn't a che…

You can always make input validation errors a checked exception with your own exception type. It'll accomplish what you're trying to accomplish. It's not perfectly clean because it'd be nice if you could stick it under the "IllegalArgumentException" part of the inheritance tree, but it does what you're asking for.

Right but if you derive it from Error it isn't checked and same as if it is derived from RuntimeException. Deriving from Exception is checked but then you aren't fitting in with the hierarchy that pron is recommending, or at least what I think they are recommending, which is why I asked for clarification.

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

#349

Post by whateveracct »

throwaway894345 wrote: post #345
whateveracct wrote: post #339

Earlier quoted context omitted.

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

I'm not sure you're making the point you think you are.

My point is if you Do Better than cargo cult stuff that feels nice, you can solve the original problem nicely.

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

#350

Post by strbean »

hope-striker wrote: post #225
jsjddbbwj wrote: post #100

Earlier quoted context omitted.

No, Python is not strongly typed by any serious definition of the concept.

Here is the most common definition of strong typing, and below it an assertion that "Smalltalk, Perl, Ruby, Python, and Self are all strongly typed". https://en.wikipedia.org/wiki/Strong_and_weak_typing#Implici...

That is quite a disingenuous quote... the actual content is:

> Smalltalk, Perl, Ruby, Python, and Self are all "strongly typed" in the sense that typing errors are prevented at runtime and they do little implicit type conversion, but these languages make no use of static type checking: the compiler does not check or enforce type constraint rules. The term duck typing is now used to describe the dynamic typing paradigm used by the languages in this group.

That is quite a qualified usage.

The only feature distinguishing Python from Javascript here is that Python does less implicit type conversion (where it is reasonable v.s. where it is insane). In every other dimension it is the same.

Post reply on HN