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

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

#261

Post by AnimalMuppet » Fri, Feb 28, 2020, 8:12 PM 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…

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

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

#262

Post by Thaxll » Fri, Feb 28, 2020, 8:17 PM UTC

hajile wrote: post #239

Thaxll wrote: post #207

Earlier quoted context omitted.

The reason is because Go is very popular where Elixir is not, if Elixir was standing where Go is now it would be pretty much the same, I guaranty you that.

Erlang is a stable language that has been around for a long time (almost 35 years now). It's used for way more mission-critical code than golang is ever likely to be used for. It's weird syntax and performance tradeoffs are very well known, but you still won't see anywhere near the number of complaints that you see against golang.

Erlang is less and less used in telecoms and it's the only place if was really used, lot of things have switch to C/C++/Java.

As for the reason why it has less complains it's pretty simple no one uses Erlang and it's a niche, it's not a generic purpose language. I can't even tell a single known application or library written in Erlang.

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

#263

Post by ChrisSD » Fri, Feb 28, 2020, 8:22 PM 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…

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

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

#264

Post by Animats » Fri, Feb 28, 2020, 8:23 PM UTC

AnimalMuppet wrote: post #261

Animats wrote: post #253

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

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

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

#265

Post by hope-striker » Fri, Feb 28, 2020, 8:26 PM UTC

joshuamorton wrote: post #249

steveklabnik wrote: post #142

Earlier quoted context omitted.

That's not an identical translation, the identical Rust would be fn main() { let mut x = 1; x = "foo"; } which indeed fails to compile with a type error. (That being said there is a conflation of static/dynamic and weak/strong going on in this thread, as there always is in these kinds of discussions.)

I'd disagree that this is a better translation. In python-land, `x` is just a name binding. The closest thing might be that `x` is something akin to a Box , but I don't know that that's cleanly expressible in rust. Like in (modern) python you can totally do def foo(): x: Union[str, int] = 1 x = "foo" which would be akin to in rust ?? (sorry my rust foo isn't great). Specifically the semantics don't work here because…

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.

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

#266

Post by pron » Fri, Feb 28, 2020, 8:28 PM UTC

hinkley wrote: post #161

palerdot wrote: post #78

Earlier quoted context omitted.

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

There are two technical conversations I don't have because everybody just gets mad and nothing gets resolved. (Note to reader: if you haven't guessed already, this means I am not going to be reading replies to this thread and certainly not responding to them. Go outside and get some air.) One, the Monty Hall problem. You either get it or you will die on a hill of misunderstanding. I've never seen anyone's mind be cha…

Java uses lazy linking, but Java's static type system is sound (modulo some bugs [1]). The Java VM type system is different from that of Java the language, but it is also sound.

[1]: http://wouter.coekaerts.be/2018/java-type-system-broken

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

#267

Post by ciconia » Fri, Feb 28, 2020, 8:28 PM 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…

This is one of the things Ruby nails with its ensure statement that lets you clean up properly even if an exception was raised.

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

#268

Post by Tyr42 » Fri, Feb 28, 2020, 8:28 PM UTC

Thaxll wrote: post #257

munk-a wrote: post #238

Earlier quoted context omitted.

Being unaware of an exception thrown by a function when calling it in Java will cause compilers to bark at you - while doing the same in go will work until it doesn't. I think this is even more insidious with changes in third party code over time though - did the package your gigantic product uses to validate that a phone number is in European time just add an error return value to a function that previously had none…

It doesn't make Go much less safer than Java. Go is a safe language. Working long enough with Java I saw all the problems with exceptions and NPE and can tell you that those problems are less prominent with Go.

I think you two are using the word "safe" differently. I agree with you that go is memory safe, but I think they mean more that business logic will do something wrong because you got an err you didn't handle, vs deferences a null or something.

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

#269

Post by joshuamorton » Fri, Feb 28, 2020, 8:29 PM UTC

hope-striker wrote: post #265

joshuamorton wrote: post #249

Earlier quoted context omitted.

I'd disagree that this is a better translation. In python-land, `x` is just a name binding. The closest thing might be that `x` is something akin to a Box , but I don't know that that's cleanly expressible in rust. Like in (modern) python you can totally do def foo(): x: Union[str, int] = 1 x = "foo" which would be akin to in rust ?? (sorry my rust foo isn't great). Specifically the semantics don't work here because…

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

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

#270

Post by totalperspectiv » Fri, Feb 28, 2020, 8:31 PM UTC

ClumsyPilot wrote: post #230

totalperspectiv wrote: post #210

Earlier quoted context omitted.

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

The premise of the article is about incorrectness in a language. So while I agree that most bugs are likely caused by the developer and not the language they are using, I think my comment makes sense in reference to the main post.