Live data from Hacker News

Lies we tell ourselves to keep using Golang

fasterthanli.me

281–290 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#281

Earlier quoted context omitted.

I interpreted "at the same time" as "without blocking", But sure you could also add parallelism using a few built-in Node modules (there's cluster and worker threads, also don't know if atomics are already in Node, they are in V8), It's not trivial anymore but also not that hard. A newcomer could figure it out in ~30 mins from the docs.

Gotcha, sounds like we interpreted it differently. I appreciate you taking the time to clarify, I am an old hand as JS but didn't know true parallelism had become feasible these days. Thank you, sincerely!

Don't worry, JS has come a long way.

During my PhD we had to crunch some numbers and my group usually makes use of C++ with libs for that. I tried doing it in Node using cluster and let it spread through our whole cluster of nodes (funny how it plays on words) and performance was worse obv. but not that bad, it was about 2x slower, but with that I was able to write code and test it in hours instead of days, and it didn't matter to me if a program that was going to take 2 hours was now taking 4 as I was going home anyway and check it out next morning ¯\_(ツ)_/¯. Plus, my experiment had a REST API for free (well, like 8 lines of code) and when I showed that to them they were :O.

Re: Lies we tell ourselves to keep using Golang

#282
post #263

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…

As someone coding in Go (and having doubts about the language) I find articles like this professionally valuable.

They don't have to be correct, they just need to provoke meaningful discourse, which for me means crowdsourcing the insights of hundreds of fellow devs.

Re: Lies we tell ourselves to keep using Golang

#283

Earlier quoted context omitted.

As an operations person who cares about deploying repeatable systems at scale, Rust's package management (and the toolchain's "packaging" itself) is an absolute nightmare. But at least I with MUSL can I have a 100% statically linked binary, which really should have been easier but that's another argument. Seriously though, Rust team needs to have its Come To Jesus moment about not piping shit off the internet to sh.

I'm interested if you could elaborate on that? My company deploys many Rust (web) applications to production and I've not experienced these issues with cargo

It's either a problem that you have or you don't, but also one that you have to have a specific mindset to even recognize.

To start off with, please read this: https://lwn.net/Articles/889924/

As you start having to worry about deploying to 10^5 scale machines you want your mindset to be more like the longtime kernel development folks. You want minimal dependencies. You want to build with minimal pulls to the internet. You want repeatable static binaries built from a source tree you can reasonably audit.

At that scale of deployment your "business risk" goes up significantly.

Rust's approach to tooling/packages looks very similar to the Node.js ecosystem. It's a total free for all and dependencies are managed really poorly (in the sense that they grow in number completely out of control).

Re: Lies we tell ourselves to keep using Golang

#284
post #263

Earlier quoted context omitted.

> 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…

As someone coding in Go (and having doubts about the language) I find articles like this professionally valuable. They don't have to be correct, they just need to provoke meaningful discourse, which for me means crowdsourcing the insights of hundreds of fellow devs.

Yes. The problem here is that there was a big one of those just yesterday. HN does poorly with repetition, and throwing in the indignation aspect and the meta aspect (can you believe what an HN commenter said yesterday? the nerve!) guarantees that the thread will get high and go crazy. None of that is intentional, but it's a well-known failure mode, so the flags in this case were helpful. We've taken the [flagged] stigma off the title above, so as not to rub salt in any wounds.

The system has checks and balances to prevent such things from dominating discussion here. (Flags are part of that system; so are software bells and whistles; so are moderators). If we didn't have those, the front page would consist of nothing but sensational flamewars and endless towers of meta!

Re: Lies we tell ourselves to keep using Golang

#285
post #179

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…

Quoted post unavailable.

That post also got flagged initially FWIW.

Re: Lies we tell ourselves to keep using Golang

#286
post #279

Earlier quoted context omitted.

"Not being adequate != don't use it ever". Plenty of situations where pragmatism leads us to building things with "inadequate" tools. Besides that, you do realize that your comment is a perfect embodiment of " Others use it, so it must be good for us too ", which is the very first "lie" that he is describing?

I gave example of very successful tool used, Kubernetes works fine, did you ever heard about Kuberentes gone bad or full of bug or unusable? It's very stable and it's used by millions of people.

> Kubernetes works fine

At what cost? How many man-hours did it take? How many bugs could have been avoided? How much faster could it be done with other languages? Most importantly: if Google stops backing its development, who else could replace it?

Redis/SQLite are written in C, and it is also used by millions of people. They are also not known to be bad or full of bugs. You don't see that being used as an argument to claim that C is an "adequate" language for most people nowadays.

And if you did see anyone using that argument, we probably would say that this is just a lie they tell themselves to keep using C.

Re: Lies we tell ourselves to keep using Golang

#287

You guys flagged this? That is not the move of a vibrant, growing, confident community. I’m no fan of the Rust jihad myself, but this isn’t spam or hate speech or whatever. That is a super weak move.

> the Rust jihad

As a Rust jihadist myself ... yeah I can't disagree with this description. Even I get sick of all the Rust chatter/evangelism on HN sometimes. I love it and it's my preferred tool, but I wouldn't mind hearing about some alternative topics at least some of the time.

(As for the article: I wrote Go for several years professionally, and what he says, well - rem acu tetigit. I know a lot of people on that former team who were converted to Rust by the experience of writing Go. And then I know others, with a natural propensity to cultishness, who just responded the way so many people are responding in this thread.)

Re: Lies we tell ourselves to keep using Golang

#288
post #209

We have tens of microservices written in Go. Go is good for onboarding new devs because it's simple. Our existing PHP devs were taught Go and it was painless. Jumping from PHP straight into Rust would be pretty painful, I think. Finding Rust devs isn't easy in our town. But I agree with most of the points. You got to be very careful when writing in Go, because there are many gotchas. So many gotchas that I had to wri…

That means Go was easy for those devs to pick up, not that Go is simple . Rich Hickey gave an all time classic presentation about this seemingly nitpicky but important distinction https://www.youtube.com/watch?v=SxdOUGdseq4

[deleted]

Re: Lies we tell ourselves to keep using Golang

#289

I've used Go and Rust professionally and in side projects, and I had used Go first before Rust. When I first used Go, I was like "oh wow, this is so simple and easy", and I didn't realize that I was putting up with the language. Learning Rust was relatively harder, but once I did and wrote some non trivial programs in Rust, it was like a pathway in my brain opened up and was previously blocked, and then when I went b…

I will say that playing around with Rust was an enjoyable experience, but it still has some warts where I think it's not quite ready for serious work yet (even though serious work is being done with it). These days I find myself leaning heavily on either Haskell or Elixir/Erlang's ecosystem (with a preference for the latter). Or JavaScript (there's just an order of magnitude more jobs)...

I find it difficult to see a standard where Rust is not ready for "serious work" but Haskell is.

Re: Lies we tell ourselves to keep using Golang

#290
post #254

Earlier quoted context omitted.

> Or dealing with impossible to trace errors in Spring Boot. Spring Boot is not Java. You can debug Java just as easily. On the upside, you can probably get the same stuff done in probably one third less code + use the vast ecosystem. On the downside, compilation may be a bit slower and you don't get a nice little executable out of the box. I wrote a tool in Golang and while it did everything as advertised, the boile…

I don’t think I’ve ever seen Java used in isolation without spring boot

This comment is hilarious ^
Post reply on HN