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

271–280 of 508 posts

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

#271

Post by pron »

Animats wrote: post #264
AnimalMuppet wrote: post #261

Earlier quoted context omitted.

> Exceptions have a bad reputation because C++ and Java botched them. Okay... > You need an exception hierarchy, where you can catch exception types near the tree root and get all the children of that exception type. Didn't Java do exactly that?

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

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

#272

Post by hope-striker »

joshuamorton wrote: post #269
hope-striker wrote: post #265

Earlier quoted context omitted.

You seem to be confusing mutable variables with mutable references . A name, in Python, is a mutable cell that holds a reference. Python names definitely correspond to mutable, not immutable variables in Rust.

Well no, for the reason I describe above: if you have the pattern mut a = 4 f(a) print(a) In rust and python, you'll always get 4 in python, but the value in rust depends on `f`. This means that the passed variable is immutable but shadowable, as in rust. (An object in python is much more like an Box/Cell, so the contained object can be mutated, but the reference to the box itself is immutable).

The value in Rust does not depend on f.

I will be precise. There is no definition of f such that this function will print anything other than "4".

    fn main() {
        let mut x = 4;
        f(x);
        println!("{}", x);
    }
Again, you seem to be confusing mutable references and mutable variables. If I had written f(&mut x) rather than f(x), you would be right.

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

#273

Post by apta »

whateveracct wrote: post #77

Here's an example of why Go's simplicity is complicated: Say I want to take a uuid.UUID [1] and use it as my id type for some database structs. At first, I just use naked UUIDs as the struct field types, but as my project grows, I find that it would be nice to give them all unique types to both avoid mixups and to make all my query functions clearer as to which id they are using. type DogId uuid.UUID type CatId uuid.…

golang's broken interface design also encourages hacks (which lead to difficult to track down bugs) like this: https://github.com/golang/go/issues/16474

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

#274

Post by reggieband »

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 other language) as much as they have used Go, and in the same environments solving similar sized problems, they would have a completely different 1000+ word rant on all the things they hate about that language.

We have an expression "use in anger". It describes a particular kind of understanding that only becomes available when we face the real problems and not just idealized ones. I even see smaller rants within this comment section showing how the very systems he lauds in Rust have sharp corners when used in anger.

I thought this rant had many good points and highlights many shortcomings of Go. I would have preferred that it did not contain the comparison which draws an implicit conclusion that IMO is likely incorrect.

1. https://www.goodreads.com/quotes/226225-there-are-only-two-k...

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

#276

Post by pcwalton »

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 get a compiler warning.

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

#277

Post by samth »

nonbirithm wrote: post #221
bluejekyll wrote: post #82

Earlier quoted context omitted.

> the author would have been well to leave Rust out of it most of the time. Initially I thought the same, but then I realized that it was being used as a means of expressing that it doesn’t have to be this way. That there are better choices, and here’s an example of better choices. Probably too much detail on the Rust, but using it to contrast with some of the poor decisions pointed out in Go is useful.

Is there a language besides Rust that could be used instead as this example? As in, languages whose standard library was so carefully designed from previous experience that the design of features like Permissions/PermissionsExt and OsString deliberately take into account the design of both Windows and Unix-like internals. The author mentioned part of the reason the filesystem API is so awkward in Go is because Go was…

Yes, plenty of languages do this. For example, Racket exposes permissions as bitmasks but they work portably across platforms, and Racket handles all the filename encoding issues mentioned here.

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

#278

Post by apta »

DLA wrote: post #101

Windows-focused rant. Plus a few reasonable points. Every language is complex at some level and in their own ways-Rust included. Every language hides some of the complexity of layers below it like assembly and thus hides hardware details. Computers are complex. Point granted. Fact is Go is a very reasonable set of compromises that let's real enterprise-scale work get done and run with solid performance. I've done wor…

Even if golang gets generics, it has so many other flaws that make it an non-starter for serious projects. This won't stop people who are driven by hype from using it of course.

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

#279

Post by apta »

flohofwoe wrote: post #140

Isn't basically all of this shortcomings of Go's standard library, not "Go the language"? The Go standard seems to be heavily geared towards doing work on the server-side, and "server-side" essentially means "Linux" today. If I'd need to write "client-side" cross-platform code that also needs to run on Windows, Go wouldn't be my first choice, also not my second or third. And TBH, most other languages are not that muc…

golang's philosophy leaks everywhere, many things are half-baked for no good reason, even when strictly superior solutions are there (e.g. defer works at the function scope, instead of the local scope). Not to mention interfaces are badly designed, leading to issues like this: https://github.com/golang/go/issues/16474

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

#280

Post by AnimalMuppet »

whateveracct wrote: post #77

Here's an example of why Go's simplicity is complicated: Say I want to take a uuid.UUID [1] and use it as my id type for some database structs. At first, I just use naked UUIDs as the struct field types, but as my project grows, I find that it would be nice to give them all unique types to both avoid mixups and to make all my query functions clearer as to which id they are using. type DogId uuid.UUID type CatId uuid.…

> Go promised me that I wouldn't have to deal with such weird specific knowledge of its semantics.

Where, specifically, did Go promise you that? I know of no languages where you don't, sooner or later, have to have weird specific knowledge of the semantics.

Post reply on HN