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

321–330 of 508 posts

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

#321

Post by joshuamorton »

hope-striker wrote: post #309
joshuamorton wrote: post #295

Earlier quoted context omitted.

That's an issue of scoping, not capturing. The x in the lambda isn't scoped to the lambda, it's scoped to the surrounding environment. So the x closes not over the lambda but the outer scope. So it's as expected given shadowing. Edit: Since I'm getting throttled: No, I'm saying that scoping rules are different in python and rust. In Rust (and cpp) there's the concept of scopes/closures as a first class feature. This…

Shadowing is when you have two separate variables with the same identifier . It is beyond obvious that all the x's refer to the same variable in dilap's example. Contrast that with an actual example of shadowing[0], in which it is clear that the same identifier is being used to refer to two different variables. [0]: https://en.wikipedia.org/wiki/Variable_shadowing#Python

I'm using shadowing in the rust sense, not the python sense.

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

#322

Post by hope-striker »

joshuamorton wrote: post #321
hope-striker wrote: post #309

Earlier quoted context omitted.

Shadowing is when you have two separate variables with the same identifier . It is beyond obvious that all the x's refer to the same variable in dilap's example. Contrast that with an actual example of shadowing[0], in which it is clear that the same identifier is being used to refer to two different variables. [0]: https://en.wikipedia.org/wiki/Variable_shadowing#Python

I'm using shadowing in the rust sense, not the python sense.

They are the exact same sense!

The exact same idea of shadowing is also present in, for example, sentences in first order logic.

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

#323

Post by programmer14 »

fasterthanlime wrote: post #92
marcus_holmes wrote: post #53

Can we just stop with the "Rust vs Go" shit? If you want me to take a critique of Go seriously these days, pick another language to compare it to. Any other language. And yeah, I'm aware that 5 years ago there were a ton of "Go vs Java" articles. I didn't think much of them then, either.

Author here - I apologize for pulling Rust into this, but for the life of me couldn't find any comparable language that solves those problems "the right way". I tried really hard. I knew a lot of people would instantly have that reaction, but I couldn't find another way to show that there is another way , short of pulling it out of thin air (which would've made for an even longer, less accessible article).

You're fine, it's a good comparison, if you didn't bring it up someone in the comments probably would have.

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

#324

Post by bdnro9nn »

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.

It’s a pretty recent language to the production ecosystem.

Is it any different than Java or Python 20 years ago?

How much of this is “wrong” given the relativeness of wrong when it comes to what is effectively how to organize a syntax construct hierarchy?

You can find the same ranting all over about C, Python, etc

Oh look computer people got an opinion on the organization of computer stuff. Shock, awe

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

#325

Post by eximius »

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…

Rust is better _at the problem presented_.

Rust not being perfect does not mean other languages can learn from its successes.

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

#326

Post by reggieband »

eximius wrote: post #325
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…

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 their limits. 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. So maybe it would have been better to leave the comparison out.

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

#328

Post by admax88q »

steveklabnik wrote: post #317
samatman wrote: post #308

Earlier quoted context omitted.

Java has Optional as well, but as you well know, you can't just bolt ADTs onto the side of a language and wash your hands of it. The whole system has to be designed around it to get the benefit of it. Java programmers will be checking for null until the last line of Java is written.

Sure, but the argument was that folks would reject it, when they in fact have explicitly added it. Its effectiveness is another story; not only along the axis you were talking about, but also others, but that's a separate conversation.

The language maintainers adding new features to appeal to people newer to the language is not mutually exclusive with veterans of the language not adopting the new features.

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

#329

Post by jgon »

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

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 checked exception, which means that the caller to your method doesn't necessarily actually need to handle RuntimeException that you would throw, meaning we're back in the C world of optional error handling?

I might be missing your point, but I would think that making it so that only program-external problems throw checked exceptions defeats a lot of the forced error handling power that checked exceptions grant?

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

#330

Post by dpc_pw »

klodolph wrote: post #247
dpc_pw wrote: post #235

Earlier quoted context omitted.

If you want to half-ass it like Go you go https://doc.rust-lang.org/std/ffi/struct.OsString.html#metho... or https://doc.rust-lang.org/std/ffi/struct.OsString.html#metho... if you want to potentially get an error. If you want to deal with bytes / invalid Unicode, you go https://doc.rust-lang.org/std/ffi/index.html#conversions

I'm aware of the conversions, unfortunately, you can’t really do any processing before you convert and you can’t (unlike C++) write generic code that works on both types of converted values. On Unix you get Vec and on Windows you get an iterator over u16. This is hot garbage, to say the least, if you want to do any kind of processing. I can go into more details, but in C++ you would just be working with std::string a…

With Rust you can also convert to `Vec` where T is either `u8` or `u16` and use generics to work on any. ️

And there are probably handful of libraries that would help with all that too. Also - whatever convenient functionality you might want, can be added in the future without issues. Hardly a language flaw - just a minor unimplemented functionality.

Post reply on HN