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

171–180 of 508 posts

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

#171

Post by tedmielczarek »

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…

I'm not sure there's a meaningful distinction to be drawn there for the vast majority of usage, to be honest. A language's standard library is generally considered to be part and parcel of the language. Everyone's first sample program is "Hello World" which involves printing text to standard output.

That being said, languages that do offer the ability to work without the standard library give you a lot of flexibility for places where you need it (like embedded systems). Rust has a pretty good story there. I don't think C or C++ really do.

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

#172

Post by marwatk »

Karunamon wrote: post #107
Seenso wrote: post #103

Earlier quoted context omitted.

> Well you should handle the error in the first place. That's like saying you should just write bug-free code in the first place.

Go goes out of its way to ensure you handle the error. You have to do something with that err return, otherwise it's a compile error. If you're just throwing it away without checking, we've gone from the mere mistakes everyday developers make to irresponsibility. There's a reason most go code is littered with "if err != nil" on nearly all function calls.

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

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

#173

Post by bfrog »

jsjddbbwj wrote: post #112
blattimwind wrote: post #109

Earlier quoted context omitted.

Strongly typed: >>> "foo" + 3.141 TypeError: can only concatenate str (not "float") to str >>> object() + 3.141 TypeError: unsupported operand type(s) for +: 'object' and 'float' Weakly typed: > "foo" + 3.141 "foo3.141" > Object() + 3.141 "[object Object]3.141" > [] + {} "[object Object]" > {} + [] 0

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

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

#174

Post by throwaway894345 »

HideousKojima wrote: post #118
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…

>Go has faults. The "OMG Go has no generics so it's total trash" argument is just silly. Generics are coming. Until it has them it's a valid complaint. And the fact that they're finally coming 11 years after the language's creation is another matter

This is silly. Lots of people are very productive in Go without generics. Even more productive than many languages that have generics (including Rust). Lots of people are very productive in languages without static typing at all. Generics will significantly improve a relatively small proportion of use cases.

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

#176

Post by Cyph0n »

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

Your choice was fine imo. Besides, you can never satisfy everyone.

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

#177

Post by Cyph0n »

marcus_holmes wrote: post #97
asdkhadsj wrote: post #85

Earlier quoted context omitted.

It's not, imo. It's an example of extremely differing philosophies - of which Rust is a great example of the opposite spectrum of Go. I imagine there may be a couple other examples, maybe something like Haskell (I wouldn't know), but I'm guessing the author just knew Rust better for this comparison. It's easier to illustrate problems that shouldn't be problems (in your eyes) if you have solutions for them - especiall…

I'd buy that if there hadn't been approximately 48764576459674 "Rust vs Go" (well, more usually "this is why Rust is way better than Go and you're some kind of moron if you're not switching to Rust today") articles in the last few months.

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

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

#178

Post by thestoicattack »

tedmielczarek wrote: post #171
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…

I'm not sure there's a meaningful distinction to be drawn there for the vast majority of usage, to be honest. A language's standard library is generally considered to be part and parcel of the language. Everyone's first sample program is "Hello World" which involves printing text to standard output. That being said, languages that do offer the ability to work without the standard library give you a lot of flexibility…

C and C++ don't have good stories for working on embedded systems without a standard library?

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

#179

Post by anthony_doan »

pmarreck wrote: post #152
thedance wrote: post #104

Earlier quoted context omitted.

There aren't any abstractions in any language or library that don't leak everything about what they are trying to hide as well as everything about their own implementation. That's just life. It's impossible to hide complexity. Whatever wraps one thing will be strictly more complex than the wrapped thing was.

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 many awesome people have contributed (POW package is just lovely).

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

#180

Post by uhoh-itsmaciek »

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

Not to mention that sql.Result (the return value of Exec) has a LastInsertId() that's an int64, so if you're using uuids, you can't use that at all and have to call Query instead and manage generated IDs yourself.
Post reply on HN