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

31–40 of 508 posts

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

#31

Post by umvi »

The_Colonel wrote: post #17
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…

What is it then if not a con? I mean, C# not running well on unix systems was immediate show stopper for a lot of projects but we can't call this a "con"?

It's only a con in the context of your use case and requirements. It's not a con for everybody, so in the general case I would instead call it a limitation.

Every piece of software in the world has limitations. The limitations are only cons in the context of your requirements. Is it a con of SQLite that it is missing features when using it with the JFFS2 filesystem? Maybe, depends on your use case. If your system doesn't use JFFS2, then it's not a con worth considering.

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

#32

Post by TheOtherHobbes »

fortytw2 wrote: post #25
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…

I absolutely agree. The one time I had the great misfortune of building software for windows I was extremely happy to see Go worked at all. Linux and OS X largely work the same way due to their shared Unix-ness and pretty much everyone I’ve ever met or talked with uses Go on one of those two platforms. If you have to develop software primarily for Windows, maybe don’t use Go - it’s easily the least actively maintaine…

No one expects iOS to run on Windows. But given that there's a Windows version of Go, it's reasonable that it should work.

And also, the points about metadata and path management are spot on. It's 2020. Languages should not be assuming that paths are byte strings.

Unix-think is a bug, not a feature. A good language should abstract the file system, not just put a teeny tiny wrapper of modesty around it.

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

#33

Post by h2odragon »

I'm sure there's real issues; but this reads as an extended whinge on "Windows and Unix are Different and languages wrap those differently whaaa!"

If you want OS interfaces that look the same wherever; then choose a portability layer that abstracts that for you.

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

#34

Post by skywhopper »

dickeytk wrote: post #11

> (Note that path/filepath violates Go naming conventions - “don't stutter” - as it includes “path” twice). That guideline is for package/content name, not package directory names. https://blog.golang.org/package-names

Yeah, the author misunderstands the naming scheme which actually suggests this sort of repetition. See also, io/ioutil.

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

#35

Post by fhood »

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

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

#37

Post by whatever_dude »

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.

This.

I like, and agree, with the conclusion, and wish more people would get to it:

> Over and over, Go is a victim of its own mantra - “simplicity”. (...)

> It constantly lies about how complicated real-world systems are, and optimize for the 90% case, ignoring correctness.

> This fake “simplicity” runs deep in the Go ecosystem.

I've always liked simplicity and on my own design, I tend to go for abstraction; trying to make it easier for consumers of my API. But nowadays more often than not I find myself preferring to be explicit about the underlying idiosyncrasies when needed. This is partly due to my recent experiences with Rust, and this post seems to concur:

> Rust has the opposite problem - things look scary at first, but it's for a good reason. The problems tackled have inherent complexity, and it takes some effort to model them appropriately.

In that sense, I especially like the approach to `Permissions`/`PermissionsExt` that Rust takes. It makes it clear what the tradeoffs are, and allows consumers to implement their own high-level, abstracted API without compromises.

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

#38

Post by jhoechtl »

hajile wrote: post #26
crimsonalucard wrote: post #21

Rust is great it follows modern programming techniques and theory but it focuses a little too much on zero cost abstractions and because of that the abstractions are a bit complicated. Go is easy to learn but poorly designed with an incomplete type system hence all these strange issues. There is a vacuum that exists between Rust and Go. A language that utilizes modern Algebraic Data Types (like rust) but does not nec…

It's not a void. StandardML file the niche well and Ocaml is getting close (just waiting for multicore support). The issue is a company that wants to put in resources.

Came here to say OCaml wojld be the sweet spot.

Sorry about multicore. It's like Perl6. A dream which will never come true or your accept F#.

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

#39

Post by alex4864 »

crimsonalucard wrote: post #21

Rust is great it follows modern programming techniques and theory but it focuses a little too much on zero cost abstractions and because of that the abstractions are a bit complicated. Go is easy to learn but poorly designed with an incomplete type system hence all these strange issues. There is a vacuum that exists between Rust and Go. A language that utilizes modern Algebraic Data Types (like rust) but does not nec…

Yes, thank you! Going without ADTs and pattern matching after having them is unbearable. All I really want is Rust but easier to use, maybe I should just bite the bullet and dive into Rust?

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

#40

Post by crimsonalucard »

hajile wrote: post #26
crimsonalucard wrote: post #21

Rust is great it follows modern programming techniques and theory but it focuses a little too much on zero cost abstractions and because of that the abstractions are a bit complicated. Go is easy to learn but poorly designed with an incomplete type system hence all these strange issues. There is a vacuum that exists between Rust and Go. A language that utilizes modern Algebraic Data Types (like rust) but does not nec…

It's not a void. StandardML file the niche well and Ocaml is getting close (just waiting for multicore support). The issue is a company that wants to put in resources.

Functional is ideal, but these languages are harder to learn and not intuitive (like rust). Outside of idealism we need a language that can be procedural simply because that is what people are use to.

Something like Go with ADTs.

Post reply on HN