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

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

#101

Post by DLA » Fri, Feb 28, 2020, 5:26 PM UTC

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 work on mostly Nix systems but have cross-compiled for Windows when needed. These are wildly different OSes and some adjustments are needed thusly in the code.

Go has faults. The "OMG Go has no generics so it's total trash" argument is just silly. Generics are coming.

Personally, Go has never let me down with anything I've asked it to do -- ETL flows, servers, streaming data processing, CLI programs, networking tools, etc. Use whatever tool fits your needs.

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

#102

Post by zgramana » Fri, Feb 28, 2020, 5:28 PM UTC

umvi wrote: post #2

Maybe I'm a zealot, but I don't really consider "doesn't work as well on windows" a con of a language. C# is (or at least used to be) utter garbage on Linux compared to Windows. I don't hold that against C#, but rather recognize that Linux/Windows are very different, and that compiler maintenance and development is non-trivial (and obviously Microsoft is going to prioritize Windows). This article is basically a rant…

Given than Mono-the first open source C# implementation-was used to build banshee going back 15+ years, C# on *nix deserves more credit than is given here.

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

#103

Post by Seenso » Fri, Feb 28, 2020, 5:29 PM UTC

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.

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

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

#104

Post by thedance » Fri, Feb 28, 2020, 5:32 PM UTC

hajile wrote: post #90

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

Is there even a single go abstraction that doesn't leak it's guts everywhere?

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.

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

#105

Post by Karunamon » Fri, Feb 28, 2020, 5:33 PM UTC

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.

Isn't the existence of TypeError and the various things you're not allowed to do implicitly (eg: 1 + "a", something Javascript will happily let you do) a definition of strongly typed?

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

#106

Post by msla » Fri, Feb 28, 2020, 5:35 PM UTC

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.

It is in that you can't "peel off" the type system using casts, as you can in C and Java.

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

#107

Post by Karunamon » Fri, Feb 28, 2020, 5:35 PM UTC

Seenso wrote: post #103

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.

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

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

#108

Post by hota_mazi » Fri, Feb 28, 2020, 5:35 PM UTC

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.

> the majority of which relate to Go's tendency to just be silently completely wrong

100% right on.

Go's handling of errors is often ridiculed for its verbosity and lack of thought, but the fact that Go makes it so easy to sweep errors under the rug has real and devastating consequences in the real world.

Go programs are much less safe than programs written in Rust or Java for that reason.

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

#109

Post by blattimwind » Fri, Feb 28, 2020, 5:36 PM UTC

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.

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

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

#110

Post by gavinray » Fri, Feb 28, 2020, 5:37 PM UTC

fasterthanlime wrote: post #89

jerf wrote: post #44

Earlier quoted context omitted.

The problem is... and a lot of people aren't going to like this, including the original author... a lot of those particular gotchas are there for a reason. The author overestimates how much of them are intrinsic to the language, in my opinion. This is a cross-platform file interface, and we've had those for years. What we tend to discover is that if you do write something precisely correct on each platform, you lose…

I share your conclusion that "the perfect cross-platform library" does not exist, and I also agree that we could use Rust to make one that's worse than the Rust standard library, and we could use Go to make one that's better than the Go standard library. However, Go's limitations make it hard to make one that is much better than the Go standard library. And the Rust standard library is so carefully designed, that the…

Can I give you an utterly useless comment that I am dying to get out of my system now that I see your HN username?

I saw the domain name and thought it was a clever phonetic hack, using the dot character literally pronounced to make "faster than li (dot) me", which sounds like "faster than light (dot) me" when you say it out loud.

I now see this is not the case at all. Alright, that's all I've got.