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

221–230 of 508 posts

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

#221

Post by nonbirithm »

bluejekyll wrote: post #82
SlowRobotAhead wrote: post #68

Earlier quoted context omitted.

> at which point many of the readers got bored I don’t know Go or Rust, and yes, I did almost get bored and quit the article. However... glad I powered through because the 169 dependency packages that ended up bringing in GRPC and this Protobuffers and the kitchen sink was worth the read. In a 0.00% acceptable conclusion. The language shouldn’t encourage this imo. I get the idea. But I’m coming from embedded so when…

> 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 designed from the start with Unix paradigms and Windows was not even considered because there was no reason to at the time - it started as a language internal to Google and their development priorities likely excluded Windows. When it became public and more widely used Windows support became a necessity for cross platform support, but there was no going back to redesign everything so it had to be bolted on within the paradigms the stdlib's interface allowed for.

When it comes to the stdlib I feel you have to be extremely careful about these things and plan for Windows users ahead of time if you intend for cross platform support - and that should be a goal if it's to be widely used. I feel like Rust only accomplished what they did because they made sure to include Windows as a first-class platform in their philosophy from the start.

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

#222

Post by hope-striker »

bfrog wrote: post #173
jsjddbbwj wrote: post #112

Earlier quoted context omitted.

a = 3 a = 'abc' There goes your strength, Samson. Just because there's something worse, that doesn't make python strongly typed

name shadowing isn't the same as strong typing, you can do the same thing in rust today https://play.rust-lang.org/?version=stable&mode=debug&editio...

Reassignment isn't shadowing. See https://news.ycombinator.com/item?id=22444824 .

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

#223

Post by masklinn »

Karunamon wrote: post #188
marwatk wrote: post #172

Earlier quoted context omitted.

If multiple functions you call return an error golang only cares if you've checked the last one.

Holy crap, seriously? I guess that makes sense since everyone calls the return 'err', I'd just never noticed before.

Yup, the compiler is perfectly happy with

    a, err := Foo()
    b, err := Bar()
    c, err := Baz()
    check(err)
    doSomethingWith(a, b, c)
because "err" is ultimately used so doesn't trigger the "unused variable" compile error. The Go compiler doesn't care that it's written to thrice and only checked once.

In fact thinking about it that's a perfect example of "solving 90% of the problem, badly" the article talks about (though it's probably closer to 70% here): the Go compiler doesn't really try to understand that errors are a thing and are relevant. To avoid developers writing

    val, err := Foo()
then going on to use `val` without checking `err` the devs decided to… require using variable.

This solves that specific issue but does nothing if, say, you miss that the function returns just an error, or you don't care about the result so you just ignore everything it returns. Or as above if you've got multiple calls binding to the generic (and conventional) `err` and think to check the last one (possibly because the calls above were only added later and the compiler never complained).

Meanwhile it makes Go throw a fit and literally refuse to compile your code because you wrote an innocent:

    val := 5
and hadn't come around to use it yet, or removed the one print you didn't care for anymore.

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

#224

Post by Cyph0n »

marcus_holmes wrote: post #213
Cyph0n wrote: post #177

Earlier quoted context omitted.

> "this is why Rust is way better than Go and you're some kind of moron if you're not switching to Rust today" I didn't see that anywhere in this article. Rust was just used to show an alternative approach.

[citation] last two lines of the article: "At this point in time, I deeply regret investing in Go. Go is a Bell Labs fantasy, and not a very good one at that."

So he thinks that Go is a bad language. What does that have to do with Go users being morons for not using Rust?

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

#225

Post by hope-striker »

jsjddbbwj wrote: post #100
palerdot wrote: post #78

Earlier quoted context omitted.

Python is 'strongly' typed `dynamic` language!!!

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

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

#226

Post by masklinn »

hota_mazi wrote: post #129
Thaxll wrote: post #60

"With a Go function, if you ignore the returned error, you still get the result - most probably a null pointer." Well you should handle the error in the first place.

The language should make you handle the error and the compiler should refuse to compile your code until you have done so.

Sorry, can't do that, too hard.

We will make sure you remove that innocent unused import though, can't have those lying around being all importey.

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

#227

Post by joeldg »

The short of this seems to be that golang isn't a scripting language which is what the author seems to need.

Maybe I am wrong here but it sounds like he got a hammer and decided everything was nails and painted (hammered) himself into a corner.

He could always submit a PR on all the windows specifics he is discussing, but those are not going to be priority for most people in my experience.

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

#228

Post by swat535 »

anthony_doan wrote: post #179
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…

Elixir is a fantastic and small language. Jose Valim kept it reasonable. It just have so much depth with concurrency. The actor model is amazing and easy to think about too. I'm not entirely sure they overlap completely but the concurrency model is superb. I will probably only use Elixir for web application from now on (unless they don't have packages for certain API). Chris have made web development possible and man…

Elixir is Erlang anyway. The only difference between the two is basically syntax and a couple of bonuses in the Elixir STDLib, most of which wraps existing Erlang functions.

You're praising Erlang's concurrency model, there's no such thing as Elixir concurrency model.

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

#229

Post by michael_j_ward »

klodolph wrote: post #164
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.

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…

Doesn't address the OsString complexity- but the author has another post on strings in Rust that you might be interested in [1]. It at least addresses how Rust does hide a lot of regular `String` complexity that `C` doesn't.

[1] https://fasterthanli.me/blog/2020/working-with-strings-in-ru...

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

#230

Post by ClumsyPilot »

totalperspectiv wrote: post #210
dilap wrote: post #23

If you imagine a spectrum of languages from sloppy-but-"easy" to precise-but-"hard", with something like Python or Ruby way off on the left and something like Rust way off on the right, Go is sitting somewhere in the middle. And so if what you're craving is absolute precision and maximal avoidance of errors or incorrect behavior, then Go is not going to be your jam. I sympathize w/ that. That said, these specific com…

> And so if what you're craving is absolute precision and maximal avoidance of errors or incorrect behavior If you are being paid to develop software, doing anything other than aiming for absolute correctness seems negligent, at best. I think this is part of what leads to obsession with Rust. We build so many things on a daily basis with a long long list of 'it depends'. But Rust aims to make you write something as c…

You statement about absolute correctness doe snot really make sence -vast majorulity of bugs in all software I've ever used are not due to the language design, but are due to blatant mistakes of the application developers.
Post reply on HN