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

251–260 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#251

Post by sph »

BaseballPhysics wrote: post #248
sph wrote: post #242

Earlier quoted context omitted.

Flagging posts that would not fit on HN or would just cause pointless flamewars is acceptable. Given the state of this thread, I think it's even more justified. "Users [flag] post as breaking the guidelines or otherwise not belonging on HN." https://news.ycombinator.com/newsfaq.html

I've seen far more inflammatory commentary/criticism in the tech community over the years. This post is honestly pretty mild if you look at it objectively. The fact that a small subset of the Go community is triggered by this post and can't behave in a civil manner isn't a reason to flag it.

Can we do without the finger pointing as well? I am not part of the Go community, and I would prefer not seeing any reaction posts and divisive opinion pieces on this forum, whatever the language or topic.

Honestly I just hope @dang nukes this thread from orbit, and maybe it'll be posted again and get a cooler reaction from everybody.

Re: Lies we tell ourselves to keep using Golang

#252

Post by pphysch »

busterarm wrote: post #117
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…

I use Go. I'm not a Rustacean. I've also used a whole bunch of things that are not Go. In reading this article, I'm finding myself agreeing with 100% of the author's criticisms. I've seen every specific problem mentioned be a thing that bogs companies I've worked for down and erode productivity. A lot of time the ops peoples' (aka: my) productivity specifically. I haven't worked at a single company where teams of dev…

> GRPC and protobufs are f'in messy and full of footguns.

Distributed data modeling is inherently messy and IME gRPC is one of the least messy, most scalable solutions to it. Or do you have a better alternative?

Re: Lies we tell ourselves to keep using Golang

#253

Post by atombender »

innagadadavida wrote: post #42
kitd wrote: post #12

The author obviously doesn't like Go. Ok, he can have his own opinions. I've been coding professionally since 1987, using everything from mainframe assembler, Fortran, C, VB, Java, C++, to most recently Go. IMHO, the language itself plays a smaller role in its usefulness than most think. As important is the tooling, stdlib, ecosystem, community and "StackOverflow"-ability. Go has a few warts, like every language, but…

A couple of things to add to this: the language spec is like a page long and very readable. Also the entire compiler toolchain and everything is written in Go and doesn’t depend llvm etc. This doesn’t help the developer but is a pretty unique aspect of Go.

The language spec (https://go.dev/ref/spec) is about 96 pages when printed on A4 paper. Certainly not a page long.

Re: Lies we tell ourselves to keep using Golang

#254

Post by cglan »

noisy_boy wrote: post #234
cglan wrote: post #61

I just don't see the issue with Go. After dealing with inscrutable errors in some python code that interfaces with OpenSSL. Or dealing with impossible to trace errors in Spring Boot. Or Javascript? An absolute nightmare from start to finish. There's something extremely nice to get an error, place a breakpoint and trace exactly (even if it's a third party library) that error is happening. I will take all the footguns…

> 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

Re: Lies we tell ourselves to keep using Golang

#255

Post by dang »

benreesman wrote: post #128

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.

It's normal for users to flag meta follow-ups to recent big threads, especially when they contain a lot of flamebait.

If users didn't flag these, HN's front page would largely consist of meta flamebait follow-ups.

Here's the principle: curiosity withers under repetition and fries under indignation; also, meta is the crack of internet forums. Repeat+indignant+meta is definitely worth flagging.

Re: Lies we tell ourselves to keep using Golang

#256

Post by arccy »

fasterthanlime wrote: post #72
unethical_ban wrote: post #37

> Why does the Go compiler suddenly care if we provide explicit values now? If the language was self-consistent, it would let me omit both parameters, and just default to zero. Without analyzing the rest of the post (which I read without having the skill to fully comprehend), this stuck out to me. Perhaps the language behaves one way and not another by design? It's abstraction. By using a Struct, I'm telling the func…

It is a very minor point and could easily be removed from the article, but I had that realization while writing those samples and it stuck with me. I really think that if we follow the "zero values by default" philosophy, it wouldn't be shocking for Go to accept omitting function arguments and just zero them. The fact that it doesn't, and insists on you passing the right number of arguments, makes the point that you…

that's a trade-off with catching user errors, are you more likely to forget to pass an argument or need to pass a zero value?

Re: Lies we tell ourselves to keep using Golang

#257

Post by jcelerier »

paskozdilar wrote: post #135
jcelerier wrote: post #124

Earlier quoted context omitted.

here's some documentation on how to do it in C++ with boost in 2008, before go even existed: in this example two threads pull events from a single queue. https://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/tu... (of course it was possible before)

I'm not really experienced with Boost so I'm having a hard time understanding what that snippet does. Is there any example that is completely self-contained (or at least limited to STL)?

Boost's io_service (since then renamed as io_context) is an implementation of a thread-safe event queue. Threads can put events in the queue (timer events, asynchronous read and write requests for networking, but one can also just push a generic lambda).

This example sets up two timers which will regularly push events in the queue, while two threads processes these events. It's from before c++ had lambdas - nowadays it can be written much more tersely.

I'll try to write a short example after when I'm not on my phone - it should be reduceable to 5-6 lines of setup at most

Re: Lies we tell ourselves to keep using Golang

#258

Post by Diggsey »

Thaxll wrote: post #174
busterarm wrote: post #117

Earlier quoted context omitted.

I use Go. I'm not a Rustacean. I've also used a whole bunch of things that are not Go. In reading this article, I'm finding myself agreeing with 100% of the author's criticisms. I've seen every specific problem mentioned be a thing that bogs companies I've worked for down and erode productivity. A lot of time the ops peoples' (aka: my) productivity specifically. I haven't worked at a single company where teams of dev…

"Why are my TCP connections not closing? Why am I encountering port exhaustion?" This has nothing to do with Go. You're implying Go has a bug in its TCP implementation which I assume is false. Networking works just fine in Go and it's actually easy to use. https://pkg.go.dev/net Edit: I'm getting downvoted but please share with TCP issues in Go.

> You're implying Go has a bug in its TCP implementation which I assume is false.

No, the parent is implying that Go's TCP implementation is easy to use incorrectly. Specifically in ways which cause the aforementioned issues.

Re: Lies we tell ourselves to keep using Golang

#259

Post by mcronce »

bobbylarrybobby wrote: post #238
busterarm wrote: post #140

Earlier quoted context omitted.

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)...

What did you think those warts were?

I use Rust for just about everything and I can definitely think of plenty of warts, but none of them make it "not quite ready for serious work" for my definitions of "serious work". I guess my point is that I'm curious what serious work this user is doing that Rust is unsuitable for - that kind of information is useful for language evolution, among other things.

Re: Lies we tell ourselves to keep using Golang

#260

Post by prirun »

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 line of code [/Edit] (increased development time) is often not worth it.

I basically like Go, I really want to like Go, but as a Python person who has used exceptions with good success for 13 years in HashBackup, I can't see myself adding an if test to practically every line of Python code, just to catch an exception that might occur once in a blue moon.

A lot of software is not so mission critical that lives depend on it. If that is the case, sure - add error checking to every line of code. But for a lot of software, IMO, it's too much work for too little reward. If something blows up in production in an unexpected way, sometimes that's okay. You log the problem, fix it, and it's fine.

I re-read the Go error handling page before posting, because maybe it's not as bad as I had initially thought. Nope, still looks pretty cryptic to me:

https://go.dev/blog/error-handling-and-go

Post reply on HN