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

141–150 of 508 posts

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

#141

Post by carapace »

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

Did you look at Haskell, and, if so, what do they do?

Good article BTW, IMO.

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

#142

Post by steveklabnik »

Macha wrote: post #137
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

fn main() { let x = 1; let x = "foo"; } Does this make rust not strongly typed? Here's a Rust program with no types in the source code. It seems the issue you're objecting to is that python doesn't differentiate variable declaration from assignment (The fact we need let twice in this code is a result of Rust doing this). Which is a fair thing to complain about (and why Python had the "nonlocal" and "global" keywords)…

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

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

#143

Post by pjmlp »

maximente wrote: post #123
gameswithgo wrote: post #18

A lot of people seem to be missing an overarching point, which is the benefits of a language having Sum types, so that edge cases can be represented clearly, and in a way where the consumer of the api can't fail to know they exist, and can't fail to handle them. Anyone thinking of making a new language today, should really get some familiarity with Option and Result types. They make so many things not only safer, but…

that's true, but realize that golang is largely shepherded forward by a company with a legacy of C++ (maybe lesser C/java) heritage. you aren't getting legacy C++ programmers on board with "optional" types: they'll riot and pull the purity card (this doesn't look like "my C++"). google is probably grateful these people are no longer returning -1, -2 etc. for errors from their functions. consider things like the golan…

The authors just happened to work at Google ,while having a manager that supported their work (check Go Time podcast), most of Google's relevant products keep being done in C++, Java and Python, and they are one of the biggest contributors to LLVM/clang, and ISO C++.

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

#144

Post by gameswithgo »

maximente wrote: post #123
gameswithgo wrote: post #18

A lot of people seem to be missing an overarching point, which is the benefits of a language having Sum types, so that edge cases can be represented clearly, and in a way where the consumer of the api can't fail to know they exist, and can't fail to handle them. Anyone thinking of making a new language today, should really get some familiarity with Option and Result types. They make so many things not only safer, but…

that's true, but realize that golang is largely shepherded forward by a company with a legacy of C++ (maybe lesser C/java) heritage. you aren't getting legacy C++ programmers on board with "optional" types: they'll riot and pull the purity card (this doesn't look like "my C++"). google is probably grateful these people are no longer returning -1, -2 etc. for errors from their functions. consider things like the golan…

Yes, in fact Go's paradigm for errors is a clever half step towards option types.

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

#145

Post by 0xdeadbeefbabe »

fhood wrote: post #35
gameswithgo wrote: post #18

A lot of people seem to be missing an overarching point, which is the benefits of a language having Sum types, so that edge cases can be represented clearly, and in a way where the consumer of the api can't fail to know they exist, and can't fail to handle them. Anyone thinking of making a new language today, should really get some familiarity with Option and Result types. They make so many things not only safer, but…

I surprises me that most people here aren't up in arms in agreement with this point. Code that is silently incorrect is an absolute disaster on an enterprise level. I spend a lot of time writing seemingly redundant double and triple error checking into my code, only to have the designers of the LANGUAGE say, "yeah, most filepaths are utf-8 so seems good enough to me".

Isn't that the standard library and not the language?

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

#147

Post by sagichmal »

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

Type aliases (type X = Y) are a niche feature and not meant for this use case.

If you had done e.g. type X Y you would have had more success.

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

#148

Post by cdelsolar »

fasterthanlime wrote: post #114
tyrankh wrote: post #58

I think this post summarizes to, - I don't like the file-related packages - What's up with this random 7 star library having a lot of transitive dependencies - Rust for life - In summation, Go is the worst

Not that this is a good faith summary, but I've updated the article to point out that it's not just "this random 7-star library", but in fact, 266 publicly-available Go packages.

Your rant largely has to do with a library someone wrote that did not handle dependencies well. A few years ago you would have complained about lack of module support at all. I have a toy project that's relatively simple, and the Javascript frontend has a lockfile that is literally over 10000 lines long.

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

#149

Post by klodolph »

With the path example… just try to combine this with flags, so we do something like:

    $ ./my_program --file="$(printf "\xbd\xb2\x3d\xbc\x20\xe2\x8c\x98")"
Well, just try to write the program that does that in Rust, without using some option-parsing library that hides all the details, and then try to figure out how to get it to work equally on Windows.

To spoil the answer, it turns out that OsString only exposes a couple conversion routines and can’t be manipulated, and people have been trying to figure out a way to add a string-like API to it for years. Rust’s “do it the right way even if that exposes lots of complexity” approach here has its drawbacks.

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

#150

Post by pdq »

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…

Good point.

Also, client side in Go is usually web interfaces, which work across any platform.

Post reply on HN