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

361–370 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#361

Post by j3s »

prirun wrote: post #260
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…

I haven't used Go or Rust seriously, but have written some Go toy code. This part of your post struck a nerve with me. I modified it slightly, to relate to Go's error handling, for me at least: > often it's not worth taking on that burden just to theoretically handle cases that rarely occur and even more rarely cause any problem. Programming is a means to an end, and the cost of [Edit] adding if err != nil to every l…

> If something blows up in production in an unexpected way, sometimes that's okay. You log the problem, fix it, and it's fine.

as the person on call for such events, it's really not fine.

would you rather handle these errors upfront during development time or unexpectedly and uncontrollably, during runtime? having been on-call in one way or another for ~10 years, i know which i'd prefer.

after having used golang in production, i will never go back to using a dynamically typed language if i can avoid it. almost 0 thought or effort is required to handle errors correctly in go, and it's still possible to ignore them (just use `_`). not that i'd recommend ever doing that.

Re: Lies we tell ourselves to keep using Golang

#362

Post by formerly_proven »

Thaxll wrote: post #356
adhoc_slime wrote: post #48

Earlier quoted context omitted.

This has perhaps been my biggest pain-point with Golang.. Woe unto those who do not follow the idiosyncrasies of how golang handles versioning, package management, tooling etc. if this is really your most important part of a language I would whole-heartedly recommend looking at rust which has been a breathe of fresh air in terms of package management and tooling.

Go tooling is awesome compared to other language ( Rust included ). Everything is built it and you don't need something external, everything works out of the box dependencies included, it has been the case for 4 years with go mod. The fact that you can cross compile a win10 .exe on a raspberry pi with a single command as easy as "GOARCH=amd64 GOOS=win go build ." it's very powerful and I don't know a single language…

> it's very powerful and I don't know a single language that does it out of the box like go does.

zig build -Dtarget=x86_64-windows

Re: Lies we tell ourselves to keep using Golang

#363

Post by Thaxll »

formerly_proven wrote: post #362
Thaxll wrote: post #356

Earlier quoted context omitted.

Go tooling is awesome compared to other language ( Rust included ). Everything is built it and you don't need something external, everything works out of the box dependencies included, it has been the case for 4 years with go mod. The fact that you can cross compile a win10 .exe on a raspberry pi with a single command as easy as "GOARCH=amd64 GOOS=win go build ." it's very powerful and I don't know a single language…

> it's very powerful and I don't know a single language that does it out of the box like go does. zig build -Dtarget=x86_64-windows

I'm talking about mainstream language not stuff in dev. And go has been doing that for 10years+

Re: Lies we tell ourselves to keep using Golang

#364

Post by bigbillheck »

samhw wrote: post #316
DrMeepster wrote: post #244

Earlier quoted context omitted.

"pronoun people" What, you cant handle queer people existing?

Quoted post unavailable.

There's still a lot of people out there who consider 'they/them' to be nonstandard when used for a specific person (as opposed to 'they/them' as a replacement for the generic 'he'; almost everybody opposed to that has come around or died).

Re: Lies we tell ourselves to keep using Golang

#365

Post by paskozdilar »

fasterthanlime wrote: post #168
bheadmaster wrote: post #120

Earlier quoted context omitted.

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, with tokio: https://play.rust-lang.org/?version=stable&mode=debug&editio... - I don't have time to come up with Java/C++ examples, but I'm sure others will. (If your point was about it being _built into the language_, then it definitely stands, see the other discussion in the parent comment thread)

Yeah, I guess I overestimated the complexity of such mechanisms. I mean, still, you need some kind of runtime for the asynchronicity, but the Rust version seems fairly OK (apart from the function coloring, but that's another story).

I guess I just like it being built into the language. Plus no function coloring (everything is asynchronous, but appears synchronous) really makes it easy to build complex systems.

Re: Lies we tell ourselves to keep using Golang

#366

Post by paskozdilar »

moralestapia wrote: post #145
paskozdilar wrote: post #123

Earlier quoted context omitted.

If you could spare some time, would you please demonstrate an example?

Abusing notation a bit, var a = new Queue(); var b = new Queue(); a.read(() => some callback); b.read(() => some callback); And code continues here without blocking. To be honest, I think you could do the same in any (slightly) modern language.

Is the read() call running a task in the background? In that case, that's equivalent to launching two threads. For n queues, you'd need n tasks, and they'd hang in the background in case they never get a result and take up memory.

Re: Lies we tell ourselves to keep using Golang

#367

Post by bombcar »

zanellato19 wrote: post #330
bombcar wrote: post #144

Earlier quoted context omitted.

> Building a successful company has very little to do with tech choices. This is what Hacker News doesn't want to hear, and so needs to hear. Like obsessing over the school supply list at the beginning of the year and getting everything perfect; it's not the whole of success, nor is it even really a huge part. But it can be fun.

So many companies succeed _despite_ their tech choices and so many fail also despite their tech choices. In the end, even at mostly software companies, if you don't have a good sales model, a good sales team, a good marketing team, its likely you will out of business soon.

Two step profit plan:

1. Get a sales team that could sell shit on a stick.

2. Get a programming team that can do a bit better than shit on a stick.

Re: Lies we tell ourselves to keep using Golang

#368

Post by lilyball »

dang wrote: post #263
rmasters wrote: post #151

Flagging this post strikes me as shameful censorship of an unpopular opinion. You may say it's the snark/anger/frustration that got flagged, but I suspect it would not have been flagged if the topic were different. Presuming the author is making bad-faith arguments for internet blog points goes against the spirit of HN. I prefer to draw my own conclusions, thank you. I normally expect HN to take the higher ground wit…

> You may say it's the snark/anger/frustration that got flagged, but I suspect it would not have been flagged if the topic were different. HN has had plenty of threads about Go over the years. What's different here is that there was just a big Go flamewar yesterday ( https://news.ycombinator.com/item?id=31191700 ), from the same site. Having another big Go flamewar the next day is a really bad idea, because then on t…

This strikes me as very odd. The post yesterday is about a 2-year-old article. This post is about a brand new article, from the same author, written more or less as a response to all of the responses to the original article over the past 2 years.

If a flamewar is a problem, then that's what moderation is for, including potentially locking. I know you've posted comments on divisive articles before cautioning everyone about not wanting the comments to devolve into a flamewar, that would have been a great first step here.

But instead of doing that, you're saying that because of the old article popping up again yesterday and rehashing the same old flamewar, you've chosen to suppress the author's own response. I would think that the old article popping up yesterday makes this new post especially timely and even more important. It's not a rehash of the old flamewar, it's the author's own words with a well-written and fairly comprehensive response to the common criticisms, and it's highly relevant to the HN audience. And especially in the context of the discussion yesterday it seems a good idea to ensure visibility of the author's own response so anyone who saw yesterday's flamewar can see this. It took 2 years from the old post for the author to write this response, I'm pretty sure you don't have to worry about having a third post tomorrow.

Re: Lies we tell ourselves to keep using Golang

#369

Post by samhw »

bigbillheck wrote: post #364
samhw wrote: post #316

Earlier quoted context omitted.

Quoted post unavailable.

There's still a lot of people out there who consider 'they/them' to be nonstandard when used for a specific person (as opposed to 'they/them' as a replacement for the generic 'he'; almost everybody opposed to that has come around or died).

Yeah, I should have clarified that I don’t consider that non-standard. Well, it’s semi-standard, I suppose. But yeah, I had in mind the ones more like ‘xe’ and ‘xer’.

Re: Lies we tell ourselves to keep using Golang

#370

Post by ianbutler »

cytzol wrote: post #229
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 comprehensi…

Checkout Elixir, I think it's better than GO for a lot of the use cases GO handles.
Post reply on HN