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

491–500 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#491

Post by pphysch »

azth wrote: post #445
pphysch wrote: post #252

Earlier quoted context omitted.

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

protobuf has issues with optional fields, as was pointed out in the post. Couple that with a language with a weak type system like golang (no sum types), and it's very verbose and slow to develop in. Targeting better languages helps alleviate the latter.

Ok, what's your alternative?

Re: Lies we tell ourselves to keep using Golang

#492

Post by lupire »

mumblemumble wrote: post #382
cytzol wrote: post #229

Earlier quoted context omitted.

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

I don't really use Go, I think mostly because I'm not in the target market, but this article's complaints (and some of these comments) actually got me thinking that I should take another look at it. A long time ago, in a Haskell community chat, I saw someone dismiss Go with a pithy comment along the lines of, "Go isn't a programming language, it's a DSL for writing network services." I think I may need to re-assess t…

> Sometimes I wonder if we are all suffering unnecessarily because of our incessant demanding that all languages try to be all things to all people.

Programmers aren't. Programmers are building stuff and talking about that. Opinion bloggers are suffering for clicks.

Re: Lies we tell ourselves to keep using Golang

#493

Post by lupire »

ay wrote: post #404
andai wrote: post #402

Earlier quoted context omitted.

I was struck by ThePrimeagen[0] saying that it took him 5x longer to write a game server in Rust than in Go—despite having significantly more Rust experience. They performed about the same (I think Go actually did better due to how much easier it was to get concurrency working?). Personally I lean towards strict compilers (I suppose years of JavaScript has traumatized me), but 5x dev time is a big tradeoff! Of course…

My experience in writing a small side project in both (on the order of 2-3 KLOC) was that the time to a working project is significantly shorter with golang. The time to the correctly working project was about the same between the two. Golang gets out of the way in me doing what I want. Rust actively resists me doing things I will later regret. Also, unexpectedly, I have gotten some positive comments on my C coding s…

99% of people don't need "correctly" working projects.

Trillion dollar companies run on "incorrect" software.

Re: Lies we tell ourselves to keep using Golang

#494

Post by lupire »

mumblemumble wrote: post #425
dylanowen wrote: post #419

Earlier quoted context omitted.

Java has immutability and more powerful types than go. Also considering how easy it is to intermix jvm languages you could add in scala or kotlin for truly powerful type systems without null.

I've grown a little disgruntled by the hype surrounding Scala's and Kotlin's null handling. For starters "without null" is a myth. They both have null. They have to; there is no other practical option. The JDK uses null all over the place, so you need to have null in order to talk to the JDK. Now, they do still have mechanism to make null easier to handle. And they're both pretty impressive designs. (Especially Kotli…

Java has a library for compile-time annotations static nullness checks, so if you use that, null only comes from legacy libraries, not new code.

Re: Lies we tell ourselves to keep using Golang

#495

Post by lupire »

mumblemumble wrote: post #475
the_gipsy wrote: post #458

Earlier quoted context omitted.

Had the same experience with Scala. Oh, Option types? Cool! Wait, why am I getting NPEs??? Oh, we're using some java library, nulls galore!

I've come to the conclusion that, for the most part, option types make no sense in object-oriented languages. There are exceptions, but they tend to fall into "proves the rule" territory. OCaml, for example. Not just because of the null problem. It's also that option types push you toward a "conditional logic everywhere" way of doing things, because that's how you handle the options. That's all well and good and holy…

How does an OO language handle a case like "Do you want fries with that?" Without conditional logic?

BurgerWithFriesMeal subclasses BurgerMeal?

"Object oriented design", in the religious sense, is an obsolete 1980s fad that took a good idea (encapsulation of mutable state) to comical extremes.

Re: Lies we tell ourselves to keep using Golang

#496

Post by lupire »

ohgodplsno wrote: post #477
mumblemumble wrote: post #425

Earlier quoted context omitted.

I've grown a little disgruntled by the hype surrounding Scala's and Kotlin's null handling. For starters "without null" is a myth. They both have null. They have to; there is no other practical option. The JDK uses null all over the place, so you need to have null in order to talk to the JDK. Now, they do still have mechanism to make null easier to handle. And they're both pretty impressive designs. (Especially Kotli…

Kotlin is quite explicit about nulls. Kotlin code requires you to use Type? if the value can ever be null. Java code that is annotated by @Nullable/@NonNull will automatically map to Type?/Type (and it is up of course to the developer to not fuck up their nullability promises.) Java code that is not annotated is a Type!, and encourages you to be wary about what could happen. The nullability story is miles better than…

If you enable nullness checks, Java is the same.

Re: Lies we tell ourselves to keep using Golang

#497

Post by b3morales »

pvg wrote: post #421
b3morales wrote: post #408

Earlier quoted context omitted.

I really don't see how "two critical articles about a particular programming language on consecutive days are flamebait and detrimental to the site" can be squared with the handling of US political and COVID articles over the last two-three years. Programming content should be the bread and butter of the site, and popular language critique is par for the course on any hacker-themed board. And tomorrow we'll have move…

two critical articles about a particular programming language on consecutive days are flamebait and detrimental to the site I'm not sure who you're quoting here but it's not me. US political and COVID articles These also get moderated quite a bit but it's a little different with ongoing hot topics - many more submissions, angles, etc. One person's take on Go, however interesting, is not an ongoing hot topic. Plus it'…

It was meant as a summary of what you and dang seem to be saying, rather than a direct quotation; I probably shouldn't have used quote marks in this context. Apologies for the confusion.

Re: Lies we tell ourselves to keep using Golang

#498

Post by delta64 »

AnimalMuppet wrote: post #484
delta64 wrote: post #462

Earlier quoted context omitted.

How is that any different to some opaque method call? By the same logic `a.equals(b)` might be doing something funky under the hood

True. But people think about it a bit differently. People don't always expect == to be a function call.

Sure, but I think '== might be a function call' is a lot less confusing than '== sometimes compares for equal value and sometimes doesn't'

Re: Lies we tell ourselves to keep using Golang

#499

Post by lanstin »

mumblemumble wrote: post #410
kaba0 wrote: post #379

Earlier quoted context omitted.

It’s a big assumption that you can even handle the error at the callsite, or that you will actually handle it correctly there, or just write some low-effort attempt because the overall picture is more important for now, but later on you won’t notice how it is not correct and it will just silently fail. Exceptions are in my honest opinion better on every single front. Checked exceptions would be the panacea but Java’s…

For reliability, the absolute best discipline I've ever experienced, is "Either handle the error at (or very close to) the callsite, or crash the process." But only if you make sure that everyone on the team understands that (A) this is the only way to do it, and (B) there is no other way to do it, and (C) you will do it no other way. I think because it sets up the right psychological incentives. Because almost any o…

With the basic idea that you should never crash due to something outside your process call stack (whether that be disk full or network problems or bad messages or bad values in a database) and always abort immediately with an email and stack trace to yourself or equiv on internal logic errors.

Re: Lies we tell ourselves to keep using Golang

#500

Post by layer8 »

prirun wrote: post #417
layer8 wrote: post #312

Earlier quoted context omitted.

> If something blows up in production The problem is if it doesn’t quickly blow up, but instead silently corrupts data or causes other problems down the line that are hard to backtrack to that specific missing check.

But because exceptions bubble up the stack frame, there can be no missing checks. I'm not suggesting things be coded as: try: do something except Exception, err: pass If a piece of code is has a try/except, then it's because there is the expectation that it might fail and certain kinds of failures can be handled. If a failure is not one of the expected failures, then do a raise and let the exception go higher up. It'…

I was responding to your scenario of having to “add error checking to every line of code” due to the absence of an exception mechanism, and your assertion that “it's too much work for too little reward”. My point was that in that situation (no exception mechanism available) it’s often irresponsible to not do that work, because the possible consequences are unpredictable. I fully agree that having an exception mechanism is the way to go, so that adding error checks every other line isn’t necessary anymore.
Post reply on HN