Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lies we tell ourselves to keep using Golang

fasterthanli.me

Post reply on HN
Print view View original

221–230 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#221

Post by foldr »

howinteresting wrote: post #129
foldr wrote: post #58

Earlier quoted context omitted.

Still not seeing it. You don't have to use interfaces to make an opaque type. A package boundary is sufficient. Not sure why you would want a fully opaque type internally to a package anyway. A regular `type Foo Bar` declaration is sufficient to give you a `Foo` that can't be accidentally interchanged with a `Bar`.

You generally want newtypes as proofs that a value has gone through some validation.

And what prevents you using them this way in Go? Just make a package and export a constructor function that does the validation.

Re: Lies we tell ourselves to keep using Golang

#222

Post by gjsman-1000 »

dragonwriter wrote: post #193
gjsman-1000 wrote: post #187

Earlier quoted context omitted.

Who cares if it is a legitimate criticism and makes unique points in both cases (also, they were both written two years apart!)? Some call it "inflammatory" but it has scientific and critical value nonetheless.

> Who cares if it is a legitimate criticism and makes unique points in both cases? Clearly, the people flagging it care, whether because they disagree with your assessment of it providing legitimate criticism and unique points in both cases, or because they think some other quality it has outweighs that in assessing it against the bar for belonging on HN. > Some call it "inflammatory" but it has scientific and critic…

If you find it does not have value to you, don't upvote it and ignore it. Don't flag it to try to hide it from people who it may have value for. It's clearly not spam, so it's not your job to determine whether it has value for other people.

Re: Lies we tell ourselves to keep using Golang

#223

Post by yjftsjthsd-h »

evo_9 wrote: post #158

The flagged feature needs to be tweaked on HN; it's being used far too often to censure opinions others simply do not agree with.

It's also being used to try and avoid another flamewar, which this article seems practically guaranteed to cause.

Re: Lies we tell ourselves to keep using Golang

#224

Post by foldr »

fasterthanlime wrote: post #113
foldr wrote: post #58

Earlier quoted context omitted.

Still not seeing it. You don't have to use interfaces to make an opaque type. A package boundary is sufficient. Not sure why you would want a fully opaque type internally to a package anyway. A regular `type Foo Bar` declaration is sufficient to give you a `Foo` that can't be accidentally interchanged with a `Bar`.

That's not the only/main reason to want a newtype though - it's also about restricting what the value can be, see something like NonZeroU64: https://doc.rust-lang.org/stable/std/num/struct.NonZeroU64.h... numeric literals (mentioned by paskozdilar in a parent comment) being untyped is another footgun I hadn't even thought of including - it makes it impossible to achieve in TypeScript/Java-level enums.

You can define NonZeroU64 in Go exactly the same way it's defined in Rust – as a struct with a private field. No interfaces required.

But I was wondering why you would want an opaque type internally to a package. Presumably not to ensure that the value has passed some validation, since in that case you would want to encapsulate that validation logic in its own package. It's not like Go imposes a tax on packages. Packages are the unit of encapsulation in Go, just as modules are the unit of encapsulation in Rust.

Re: Lies we tell ourselves to keep using Golang

#225

Post by naikrovek »

Thaxll wrote: post #154

I'm just wondering why the author keeps making those articles about strongly disliking Go, ok we get it your favorite language is Rust, you don't like Go. Why does the author does not move on, exactly? "Fine. It may well be that Go is not adequate for production services unless your shop is literally made up of Go experts (Tailscale) or you have infinite money to spend on engineering costs (Google)." This is really w…

this article was written specifically to address the comments that came up when the two-year old article made the rounds again.

that's why he didn't move on; we resurrected the topic.

Re: Lies we tell ourselves to keep using Golang

#226

Post by metadat »

josephcsible wrote: post #212
metadat wrote: post #141

Earlier quoted context omitted.

Are there nasty divergences between official go and cgo?

As it turns out, Go's spec is 105 pages long, not just one as was claimed upthread: https://go.dev/ref/spec So the answer to your question is "not that I know of", but that's not evidence that a one-page spec is workable after all.

Thank you for showing us the light, jospehcsible!

Re: Lies we tell ourselves to keep using Golang

#227

Post by autarch »

bheadmaster wrote: post #120
fasterthanlime wrote: post #57

Earlier quoted context omitted.

> As far as I know, no other popular language allows you to read from multiple queues at the same time Off the top of my head, that's certainly possible in Rust, C++ and Java - probably many others I just don't know about. That particular bit of concurrency goodness comes from the 70s, so you can be sure other languages picked it up.

If you could spare some time, would you please demonstrate an example? Any language of those mentioned would be OK.

Here's a rust example - https://github.com/autarch/channel-select

Re: Lies we tell ourselves to keep using Golang

#228

Post by seba_dos1 »

streblo wrote: post #56

I didn't care in the last post and I don't care about this one either. I care about my productivity, I care about my team's productivity, and I care about getting stuff shipped. Those are the things I care about, and go works great for that. If you care about those things too, and you're using go, you shouldn't stop using go. My whole career people have been telling me to stop using languages or tools I've been produ…

The article's author has written and shipped tons of quality Go code that is still used in production by many people, myself included.

Sometimes, a poor language is a good tool for specific task despite of being generally a poor language. Sometimes, knowing and liking a bad language makes you use it for tasks it's not suited for. Go is in the same category as JavaScript and PHP there, which have their valid uses, but also a lot of valid reasons to stay away from. You only learn how and when to choose them once you become experienced enough in several languages to notice the differences between them over long term usage and project maintenance.

Re: Lies we tell ourselves to keep using Golang

#229

Post by cytzol »

HL33tibCe7 wrote: post #98

The author writes well and makes compelling points. His "I want to get off Mr Golang's Wild Ride" post is good too. But I don't find myself agreeing with his position, which is "you shouldn't use Go for production services" (he explicitly says this in one of his Go posts, I forget which one and don't have time to look right now). The better alternative to Go is Rust. Okay, sure, I'm willing to admit that in the examp…

> Programming is a means to an end, and the cost of using Rust (hiring, increased development time) is often not worth it.

I agree with this. I learnt Rust before Go, and using Go makes me feel like The Oatmeal piracy guy[1]:

"I'm not sure if I should use Go to write this HTTP service. I'd lose immutability tracking, I'd lose compiler-enforced thread safety, I'd lose the powerful type system, I'd lose the comprehensive error handling, I'd suffer from a million little papercuts, I'd have to use the weird date formatting system, I'd have to check nil pointers, I'd...

...oh, it's seven days later and I've already accomplished more writing networking servers and clients in Go than I ever have in years with Rust."

This isn't to say the points raised about Go aren't true. They are true, and if a better language were available, I wouldn't stand my ground and argue their benefits, I'd switch to it. The last comment I happened to post on this website is about how Go is insufficient without its army of linting tools [2]! Yes, I'm incredibly happy to have learnt both Go and Rust as their combination has expanded my skillset and the range of programs I'm willing to write tremendously. But if someone said to me "you should just use Rust instead of Go for your production services", I'd think the "just" was doing some incredibly heavy lifting.

An article that I'd like to see is one comparing the two languages for this niche (networking servers and clients), contrasting not just the language pitfalls but the third-party libraries necessary, the iteration speed, and the choices you'll have to make up-front. My guess is that the languages would be judged more closely together.

[1]: https://theoatmeal.com/comics/game_of_thrones [2]: https://news.ycombinator.com/item?id=30749921

Re: Lies we tell ourselves to keep using Golang

#230

Post by yjftsjthsd-h »

mcluck wrote: post #105

I'm honestly surprised at the response to this article. I'm not involved in the Rust or Go spaces enough to have any strong opinions. This article was, yes, a little aggressive in tone but presented very honest and accurate information about a language that the author clearly has experience in. It seems like a lot of the people complaining in the comments didn't actually read the article. The author even explains how…

Sure, the baby is ugly. That's perfectly fine. The problem is when you continuously insist that the only reason anybody could ever love the baby is because they're delusional and in denial.
Post reply on HN