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

81–90 of 508 posts

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

#81

Post by irishsultan »

SlowRobotAhead wrote: post #68
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.

> at which point many of the readers got bored I don’t know Go or Rust, and yes, I did almost get bored and quit the article. However... glad I powered through because the 169 dependency packages that ended up bringing in GRPC and this Protobuffers and the kitchen sink was worth the read. In a 0.00% acceptable conclusion. The language shouldn’t encourage this imo. I get the idea. But I’m coming from embedded so when…

> Your gripes with x should be independent of “y lang does it better” aside from just knowing it is possible to be better.

And what better way to demonstrate it's possible to do better by having an example ready?

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

#82

Post by bluejekyll »

SlowRobotAhead wrote: post #68
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.

> at which point many of the readers got bored I don’t know Go or Rust, and yes, I did almost get bored and quit the article. However... glad I powered through because the 169 dependency packages that ended up bringing in GRPC and this Protobuffers and the kitchen sink was worth the read. In a 0.00% acceptable conclusion. The language shouldn’t encourage this imo. I get the idea. But I’m coming from embedded so when…

> the author would have been well to leave Rust out of it most of the time.

Initially I thought the same, but then I realized that it was being used as a means of expressing that it doesn’t have to be this way. That there are better choices, and here’s an example of better choices. Probably too much detail on the Rust, but using it to contrast with some of the poor decisions pointed out in Go is useful.

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

#83

Post by _bxg1 »

I think the mistake may be assuming that Go is meant to be a general-purpose language. From what I can tell, it's purpose-built to be a "web services" language, and its design-decisions center around that. What does that mean?

- It's expected to be run on Linux servers (not Windows) and developer workstations (probably not Windows).

- It needs to be fast but not blisteringly fast. Micro-performance concerns like the Time object thing are devalued.

- Embedded use-cases are probably not given too much attention.

- Agility in working with dynamic data (because that data is often foreign) is valued over flawlessly safe types.

By deciding not to worry about certain use-cases, the language can be more developer-efficient for its intended use-cases. In this light, for better or worse, I think the decisions made make a lot more sense.

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

#84

Post by hajile »

crimsonalucard wrote: post #54
hajile wrote: post #48

Earlier quoted context omitted.

Ocaml and SML are not the Haskell dream world. They allow imperative code, side effects, and mutation. The difference is that they have sane defaults (eg, immutable until you specifically ask for mutations) and an actually sounds type system (no null exceptions, exhaustive pattern matching, good generics, etc) SML in particular was designed to be easy to learn and implement and succeeds rather well on both counts. It…

Interesting. What is your opinion is preventing SML from filling the vacuum in terms of adoption? Is it just marketing?

There are three major implementations polyML, SML/NJ, and Mlton (the last two are used together a lot as Mlton's whole code optimizer can take some time). Most of those coders work at universities and the biggest projects (for polyML at least are large theorem provers). They don't really focus on the software problems of more typical businesses.

There are very few languages that rise to prominence without corporate intervention. SML is a solid foundation, but the ecosystem is somewhat lacking. I don't really know aside from that. Even though SML syntax isn't difficult or particularly radical, it isn't in the C family which (I believe) makes it a no go for lots of companies.

EDIT: to answer more clearly, we simply need more dev time to create and improve the library situation and that basically demands a corporate patron.

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

#85

Post by asdkhadsj »

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.

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 - especially solutions that you believe work well. Rust's take on these nitpicks is something that the author clearly thinks Go is lacking on.

In my view, this post is a critique on Go and the "simplicity" mantra it has; and only that.

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

#86

Post by Aissen »

staplung wrote: post #71
madhadron wrote: post #64

> The Go way is to half-ass things. This used to be known as the New Jersey school, and is the underlying philosophy of Unix: build a bunch of little pieces that work a lot of the time and kind of fit together if you remember the gotchas, then call it a day. There is an essay on this that I am unable to locate right now which mentions the horror of someone working on ITS when they asked how Unix solved a rollback on…

https://www.jwz.org/doc/worse-is-better.html

jwz is redirecting this link based on referer, you might want to not click on it (copy/paste works).

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

#87

Post by wrs »

skrebbel wrote: post #67
madhadron wrote: post #64

> The Go way is to half-ass things. This used to be known as the New Jersey school, and is the underlying philosophy of Unix: build a bunch of little pieces that work a lot of the time and kind of fit together if you remember the gotchas, then call it a day. There is an essay on this that I am unable to locate right now which mentions the horror of someone working on ITS when they asked how Unix solved a rollback on…

Sounds like it might be straight from the original "worse is better" essay: http://dreamsongs.com/RiseOfWorseIsBetter.html > The MIT guy did not see any code that handled this case and asked the New Jersey guy how the problem was handled. The New Jersey guy said that the Unix folks were aware of the problem, but the solution was for the system routine to always finish, but sometimes an error code would be returned th…

Ironically, that is referring to the EINTR error code that I predict is about to cause a bunch of unexpected failures when people switch to Go 1.14. [0]

[0] https://golang.org/doc/go1.14#runtime

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

#88

Post by SlowRobotAhead »

irishsultan wrote: post #81
SlowRobotAhead wrote: post #68

Earlier quoted context omitted.

> at which point many of the readers got bored I don’t know Go or Rust, and yes, I did almost get bored and quit the article. However... glad I powered through because the 169 dependency packages that ended up bringing in GRPC and this Protobuffers and the kitchen sink was worth the read. In a 0.00% acceptable conclusion. The language shouldn’t encourage this imo. I get the idea. But I’m coming from embedded so when…

> Your gripes with x should be independent of “y lang does it better” aside from just knowing it is possible to be better. And what better way to demonstrate it's possible to do better by having an example ready?

Because you may turn anyone who would otherwise be empathetic of your gripe with their reluctance to accept your proposed solution.

I’m reminded that “not every problem needs a solution”. Or at least needs one right now.

I agree, in this case it made good points, but too many of them. It just didn’t need so many examples of why “Rust is better”. If you were invested in Rust or Go, this article reads differently to you than me who is invested in neither.

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

#89

Post by fasterthanlime »

jerf wrote: post #44
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 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 there's really no need to go ahead and redo the work. Unless you need something it explicitly doesn't support (and doesn't promise to support!), in which case there's a wealth of crates at your disposal, which also benefit from a rich type system and strict compiler checks to ensure correctness at compile-time.

People don't just switch to Rust and write code like they did before. It's different enough that it makes everyone rethink how they approach a problem. But it doesn't just get in your way - not only are the compile errors excellent (and the core team is working tirelessly to improve them even further), it gives you the tools to build solutions you'd never pull off in other systems languages.

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

#90

Post by hajile »

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?
Post reply on HN