Live data from Hacker News

I want off Mr. Golang’s Wild Ride (2020)

fasterthanli.me

231–240 of 477 posts

Re: I want off Mr. Golang’s Wild Ride (2020)

#231
Go's main selling point is that it is extremely easy to deploy and it has good standard libraries for most routine programming problems. It works really well for providing web services running on Linux, but I can see why you wouldn't like it if you were running on Windows.

Re: I want off Mr. Golang’s Wild Ride (2020)

#232
post #39

Golang is great because it was the first to include excellent tooling in addition to the language (strict compiler, linting, non-customizable gofmt, package manager, good html docs, online playground, etc.) It’s undeniable that it brought a lot of good ideas that languages like Rust borrowed. Golang is still undefeated in terms of battery included. Its standard library is top notch and full featured. On the other han…

I don't believe Go was the first language to include "excellent tooling." Ruby on Rails, for instance, has had excellent tooling since the dawn of time, and I'd argue that Ruby on Rails' and Elixir's tooling are superior to Go's.

Re: I want off Mr. Golang’s Wild Ride (2020)

#233

Earlier quoted context omitted.

This is how the system already works...

The FAQ does mention a karma threshold to flag links, so sorry about that. Perhaps that threshold should be raised. It doesn't mention revocation of flagging permission for abuse, and I think that would be helpful.

No post body was provided.

Re: I want off Mr. Golang’s Wild Ride (2020)

#234
post #39

Golang is great because it was the first to include excellent tooling in addition to the language (strict compiler, linting, non-customizable gofmt, package manager, good html docs, online playground, etc.) It’s undeniable that it brought a lot of good ideas that languages like Rust borrowed. Golang is still undefeated in terms of battery included. Its standard library is top notch and full featured. On the other han…

I don't believe Go was the first language to include "excellent tooling." Ruby on Rails, for instance, has had excellent tooling since the dawn of time, and I'd argue that Ruby on Rails' and Elixir's tooling are superior to Go's.

Elixir is a FL so it is in a category of its own. I’ve done some Ruby and I don’t remember the tooling as being exceptional like Golang’s

Re: I want off Mr. Golang’s Wild Ride (2020)

#235
post #80
post #39

Golang is great because it was the first to include excellent tooling in addition to the language (strict compiler, linting, non-customizable gofmt, package manager, good html docs, online playground, etc.) It’s undeniable that it brought a lot of good ideas that languages like Rust borrowed. Golang is still undefeated in terms of battery included. Its standard library is top notch and full featured. On the other han…

What is meant with expressiveness in this context?

Generics, sum types, macros, functional programming stuff, basically things that allow you to do more things

Re: I want off Mr. Golang’s Wild Ride (2020)

#236
post #18

* * *

> toxic The author presents things about the language that they don't like. How on earth is that "toxic?" Have we reached the point where "toxicity" is just "things I don't like hearing?"

Yes. Can we go back now?

Re: I want off Mr. Golang’s Wild Ride (2020)

#237

Earlier quoted context omitted.

I don’t get the “abusive relationship” metaphor. It just seems like the “abuse” metaphor is an attempt to stir up emotions. Every language has its own weird way of doing things. You decided Go wouldn’t work for you? Ok, I get it. People who stick with Go are in an “abusive relationship”? Seems like an attempt to stir up a flame war more than anything else. I’ve never encountered a language that I’m 100% happy with. I…

It sounds like you enjoy Go. That is great. I am referring to TFA/post which sounds similar to many experiences with Go. Of course all languages have pros and cons. I am referring to the specific situation where people are expecting a modern language and ecosystem heavily influenced by its user community. Go is not such a language. People should have different expectations. > The history of language design is the his…

> I am referring to TFA/post which sounds similar to many experiences with Go.

Lots of people have bad experiences with Java, C++, Rust, Python, or JavaScript. I've had bad experiences with all of those languages, as well as bad experiences with Go. I don't think you've managed to articulate what makes Go different.

I'm not saying you should use Go. I will say this: it sounds like you have opinions about Go, and I can't tell if you're trying to imply that those opinions are somehow universal or common, or reflect some actual design flaw in Go that you can articulate.

"Many are not happy" about Go generics but that's inevitable, IMO. I don't think there's any possible language design decision that won't make many people unhappy. You might as well be asking for pizza toppings that make everyone happy.

> I agree completely, which is why it is so surprising that people adopted Go when it seemed to learn very little from history.

I can understand why you would think that way, but Go seems to me completely different. When I look at Go, I see a ton of small decisions where it seems like (to me) that the Go language designers have taken some fairly sophisticated lessons from history. Things like:

- Error handling,

- Strings,

- Default garbage collector tuning,

- Generics,

- Dependencies,

- Versioning.

Just to pick an example... Java's checked exceptions are a good idea, but have some unfortunate consequences when Java is used for larger projects. One of the key problems is that when you handle an error, you don't just need to know what the error is, but where the error came from. Some errors can be handled at a distance and some errors must be handled near their origin. Errors in this second category can be made into checked exceptions in Java--at least, that's the idea--but in practice, it's a bit of a mess.

If you pull back from dividing errors into checked / unchecked variants, then you lose the ability for the language to help you distinguish between errors that can be handled locally and errors that can be handled at a distance. IMO, Go's decision to use error returns makes the decision that "local error handling is default", which is a pretty nuanced take on things that I really appreciate. I don't think anyone would have come up with Go's error handling approach without the lessons from Java's error handling approach.

Some people hate it. That doesn't mean that it "didn't learn from history".

Re: I want off Mr. Golang’s Wild Ride (2020)

#238

Earlier quoted context omitted.

> or implement the same function N times over to support the different numeric data types Did you consider using a preprocessor or suchlike

Then you wouldn't really be programming in Go. You'd be programming in whatever franenkstein's monster of a language your preprocessor is using. Preprocessors are a code smell, and indicate that the language you are using lacks the right abstractions for productive programming.

> and indicate that the language you are using lacks the right abstractions for productive programming.

Indeed go did not have generics, in fact that's explicitly stated in the post I was responding to:

"at the time the lack of generics made it so that you either had to use reflection - or implement the same function N times over to support the different numeric data types"

So, you unthinking prat, what do you recommend he should have done, carried on coding much near-duplicate code by hand or get the computer to do the repetitive job infinitely faster and more safely?

HN is riven with plodders who just spew out memes like "Preprocessors are a code smell" or "correlation is not causation" with a relentlessness that would make Sisyphus say, 'well, you know, at least I'm not him'.

Re: I want off Mr. Golang’s Wild Ride (2020)

#239

I see Go as a language for some use cases on some Unix platforms. It was clearly designed early in the current iteration of "modern" programming languages and I firmly believe that Rust, for example, learned a lot from the mistakes Go made. My impression is that Go as a language tries to make things simple, but things aren't always simple. Time and date operations are hard and simplification leads to I correctness. I…

> Take a look at C# and Java (or if you want to feel like you're writing modern code, maybe Kotlin) Every time one of these Go/Node/Rust/etc rants comes up, my brain is screaming "but why not C#?". I would not be doing what I do today if I had not discovered this realm of goldilocks experience - Approximately "just works", runs about everywhere, tooling with decades of heritage & features, fast , etc. The only 2 excu…

C# used to be quite a bad development experience for anything other than Windows Server + IIS for years. Many people who would not probably love the language abandoned it years ago and never came back with the bad 2010s era after image in their minds.

The thing about C# and Java is that they're not exactly exciting languages. They do what you want and not much more. They don't tend to break massively between releases. Their syntax was clearly designed decades ago. Their extensive package repositories are overwhelmingly filled with boring packages that solve boring business problems. I personally much prefer C# above Java, but even Java with its flaws is one of the most important programming languages for business in the world.

If you want to learn new things, you don't turn to these new languages. Up and coming languages come with interesting ideas and paradigms, even something as polarizing as Rust is now getting good market penetration. WASM is all the rage and every time you blink someone has a fancy new idea that can be hacked into Javascript.

Honestly, though, the boring languages work well for business. Yes, Go and Rust are very fast and you CAN run them as front-end frameworks if you wish to, but most applications are boring old CRUD apps that are much better served with something like C# or the JVM and its many many years of library maturity, guides, Q&As online, and books. It's not fun or exciting, but it gets the job done well.

Re: I want off Mr. Golang’s Wild Ride (2020)

#240

Go's main selling point is that it is extremely easy to deploy and it has good standard libraries for most routine programming problems. It works really well for providing web services running on Linux, but I can see why you wouldn't like it if you were running on Windows.

My main takeaway from the blog post was really how much Windows sucks, not that Go is bad haha
Post reply on HN