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

331–340 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#331

Post by samhw »

mcronce wrote: post #133
rob74 wrote: post #94

Earlier quoted context omitted.

But he doesn't dive deeper! If anything, he's more shallow. This just doesn't read like an honest appraisal of Go's pros and cons to me, he already has his mind set from the beginning (ok, we knew that two years ago already) and is just heaping on invectives: "one really good bit does not a platform make", "Evidently, the Go team didn't want to design a language", "Go is not adequate for production services unless yo…

I'd choose Node or PHP over Go for a greenfield project. (Although I can't think of a case where I'd choose them over Python.) All of those languages at least give me an FFI escape hatch in case I need it that isn't absolutely horrendous, both from a dev experience standpoint and a performance standpoint.

Yeah, preach. I wrote Go professionally for a couple of years, and I write Python now (I know, I know, but they pay me a ridiculous amount to do it). I would choose almost anything, including JS, over Go. It's a good language if you need to write highly concurrent high-level code with low-skill devs, but not for much else, and even then it requires an inordinate amount of menial boilerplate work to get simple stuff done. Having said that, I would still choose it – indeed anything - over Python.

Re: Lies we tell ourselves to keep using Golang

#332

Post by crawshaw »

Tailscalar here.

Go made prototyping our product easy. We have relatively rarely needed Go expertise on the team to make the product better, when we did it was for the exotic iOS environment (not normal iOS, the Network Extension).

It’s far from perfect (and I really should write an experience report about all the times Go has let us down!), but it gives us less trouble than Node and Swift do, for our relatively minor uses of those languages. I don’t think any other language would have been a better choice, even putting our expertise aside.

On the whole I would say you don’t need Go experts on your team to build products in the language.

Re: Lies we tell ourselves to keep using Golang

#333

Post by hajile »

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.

Can you describe a coherent and consistent multithreaded model completely in 100 pages?

Re: Lies we tell ourselves to keep using Golang

#334

Post by SeanLuke »

delta64 wrote: post #63
SeanLuke wrote: post #27

I don't know nothin' about Go. But this complaint really surprised me: > Go not letting you do operator overloading, harking back to the Java days where a == b isn't the same as a.equals(b) Does this guy really not understand that in a mutable language, (eq ...) is not the same as (equalp ...) and should never be confused with it? Also: operator overloading is the spawn of Satan.

The author definitely understands that. The point is: when you don't have operator overloading you get stuff like that which does demonstrably confuse many people In languages with operator overloading this just isn't a concern at all because == does the obvious thing

> In languages with operator overloading this just isn't a concern at all because == does the obvious thing

And what is the obvious thing? It varies wildly among languages, even within C++ itself.

Re: Lies we tell ourselves to keep using Golang

#335

Post by valcron1000 »

steaminghams wrote: post #53

I generally like go and also see its problems as the author does. However, with respect to the points about Go as a prototyping/starter language, there is not better language to start writing a project with in my opinion. Lots of languages have big communities of packages of various levels of maintenance but almost no other language has a standard library that is as usable as Go with the same guarantees between versi…

If you want a big standard library why not use something like Java or C#? I mean, you even have UI toolkits available from the get go

Re: Lies we tell ourselves to keep using Golang

#336

Post by hajile »

assbuttbuttass wrote: post #102

I feel like go hits a sweet spot between productivity and correctness. Working in Python, I constantly run into errors that static typing could have caught. Working in Rust, I feel like I'm constantly fighting the borrow checker. Maybe a more experienced Rust programmer would feel differently, but one of the strengths of Go is that it's relatively easy to learn

The sweet spot is something like StandardML. You get an actually sound type system (with genetics that aren’t a hack), but skip the complexities of direct pointer manipulation.

It can do this while also being easier to learn than go too (designed so students could learn it and implement it too).

The only reason go is popular is because google put thousands of man years and countless millions of dollars into it.

Re: Lies we tell ourselves to keep using Golang

#337

Post by SeanLuke »

ak217 wrote: post #270
SeanLuke wrote: post #27

I don't know nothin' about Go. But this complaint really surprised me: > Go not letting you do operator overloading, harking back to the Java days where a == b isn't the same as a.equals(b) Does this guy really not understand that in a mutable language, (eq ...) is not the same as (equalp ...) and should never be confused with it? Also: operator overloading is the spawn of Satan.

Without operator overloading, it is basically impossible to adapt a language for numerical computing/data science applications. Yeah, operator overloading is a powerful tool that's easy to abuse; no, it's not optional if you want the language to succeed at all in a whole bunch of applications.

Mathematica works just fine without user-defined operator overloading.

Re: Lies we tell ourselves to keep using Golang

#338

Post by __jem »

busterarm wrote: post #296
whimsicalism wrote: post #289

Earlier quoted context omitted.

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

I can install a working Haskell toolchain with my package manager instead of the farcical `curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh`. If you're an automation-oriented kind of person like it's my job to be, setting up repeatable toolchians based around the above is a total crock of shit.

Rust/rustup is in every package manager like ever. As someone who is "automation-oriented" you sound like you don't have the faintest idea what you are talking about.

Re: Lies we tell ourselves to keep using Golang

#339

Post by bovermyer »

icholy wrote: post #268
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…

The content is mostly ok, but the title suggests that there's some obvious alternative to Go that we should be using. If he's implying it's Rust, then he's totally disconnected from reality.

It's buried in the article, but I think the suggestion is "use almost any language other than Go" rather than Rust specifically.

The takeaway - if you gloss over the ranting and look for the good bits - seems to be that you should choose a language that handles a lot of the boilerplate for you (e.g., no verbose error handling) and has FFI.

It's not a bad argument, and it's making me think about how and when I use Go. For that, at least, it's worth reading.

Re: Lies we tell ourselves to keep using Golang

#340

Post by rmasters »

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…

I appreciate the extra context. For what it's worth, I was not aware of the previous discussion and I just thought it was an interesting post. (I really don't have any feelings about golang one way or another.)

I can appreciate your point about having limited resources to moderate posts that have a track record of generating big flamewars. But I didn't get the impression from the comments (many being ad-hominem) that the post was flagged for that reason and my use of the word "shameful" was directed at those comments.

Post reply on HN