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

471–480 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#471

Post by mumblemumble »

kaba0 wrote: post #439
mumblemumble wrote: post #410

Earlier quoted context omitted.

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…

I just gave you an example from the top of my head. Here is another more realistic one, which occurred to me during the time I wrote a toy JVM: a Java class file contains a constant pool with different kinds of types. During the loading process this pool can be references by other entities as well, but they require the necessary type. Assuming verified byte code, this will be the case, but if we care about verificati…

I could believe that, but implementing JVMs is such a very specific use case, far removed from what most programmers do day-to-day. Not just because it's a VM. Because you're implementing a pre-existing specification, so you're not at liberty to make your own design decisions around something like classloader semantics. It feels like a red herring example to me. "Here's how we should think about dealing with error conditions in 2022." "But what if I've got a spec that forces me to do it 1994-style?"

Re: Lies we tell ourselves to keep using Golang

#472

Post by mumblemumble »

pvg wrote: post #429
mumblemumble wrote: post #427

Earlier quoted context omitted.

A rule and its implementation are two separate matters. With all due credit to rmasters, "I suspect it would not have been flagged if the topic were different."

Well, yeah, that's your suspicion but it is not an argument, it's just a suspicion that something nefarious is going on. I don't think you've really responded to any of the explanations of why HN works this way. That doesn't mean the way HN works is right but you have to bring something more to it than aspersions if you want to argue for change.

"nefarious"? "nothing more to it than aspersions"?

Please don't strawman me like that. If you're going to make "the rules of HN dupery" the place where you want to make your stand, then this seems like a peculiar response. These rules for HN dupery are not actually published anywhere outside of HN mod team comments when debates like this come up. By contrast, though, the published commenting guidelines clearly state "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."

Which, I realize that this whole tangent is then in contrast with the very next guideline in the list, which exhorts us to "Avoid unrelated controversies and generic tangents." But, since HN lacks the meta-discussion channels that other comparable community sites have, these sorts of frustrations can't really do aything but boil over into public every so often, so I'm self-consciously allowing myself the conceit. In my defense, I've also been following and engaging in what I thought was some of the more interesting HN discussion I've seen in a minute. Including having my opinion on a programming language and its community go through some positive changes. So I do somewhat feel, then, that HN moderation deciding to flag the article and then bury it on the 2nd page because they think it's just a flamewar is tacitly an unfair accusation against which I must defend myself. And, frankly, the alternative defense that it's because it isn't interesting comes across as dismissive and condescending.

Re: Lies we tell ourselves to keep using Golang

#473

Post by kaba0 »

mumblemumble wrote: post #471
kaba0 wrote: post #439

Earlier quoted context omitted.

I just gave you an example from the top of my head. Here is another more realistic one, which occurred to me during the time I wrote a toy JVM: a Java class file contains a constant pool with different kinds of types. During the loading process this pool can be references by other entities as well, but they require the necessary type. Assuming verified byte code, this will be the case, but if we care about verificati…

I could believe that, but implementing JVMs is such a very specific use case, far removed from what most programmers do day-to-day. Not just because it's a VM. Because you're implementing a pre-existing specification, so you're not at liberty to make your own design decisions around something like classloader semantics. It feels like a red herring example to me. "Here's how we should think about dealing with error co…

There is nothing inherent to JVMs here, it is just the all around most common error type. It simply don’t make sense to handle many type of errors at call site, because it misses the big picture and for these, return types are not a good fit.

Re: Lies we tell ourselves to keep using Golang

#474

Post by mumblemumble »

dylanowen wrote: post #457
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…

I was pretty skeptical of this and yes I'd rather not have null at all. In practice though I've found the boundary with Java for my scala projects to be very small. This is definitely a function of what you're building but there are a lot of great scala libraries so we rarely need to reach for java.

Yeah, that's absolutely fair, a greenfield Scala project can avoid a lot of Java nowadays.

But, at the other end of things, teams that were already using Java and want to start incorporating Scala don't have that option. And 10 year old Scala projects didn't originally have that option, and doing something about it now may be a lift on the scale of a complete rewrite.

Re: Lies we tell ourselves to keep using Golang

#475

Post by mumblemumble »

the_gipsy wrote: post #458
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…

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 in a functional language, and perhaps even a procedural one. But it's the opposite of good object-oriented design.

To quote Dr. Mark Crislip, when you serve cow pie with apple pie, it does not make the cow pie better. It just makes the apple pie worse.

Re: Lies we tell ourselves to keep using Golang

#476

Post by mumblemumble »

kaba0 wrote: post #473
mumblemumble wrote: post #471

Earlier quoted context omitted.

I could believe that, but implementing JVMs is such a very specific use case, far removed from what most programmers do day-to-day. Not just because it's a VM. Because you're implementing a pre-existing specification, so you're not at liberty to make your own design decisions around something like classloader semantics. It feels like a red herring example to me. "Here's how we should think about dealing with error co…

There is nothing inherent to JVMs here, it is just the all around most common error type. It simply don’t make sense to handle many type of errors at call site, because it misses the big picture and for these, return types are not a good fit.

So, the idea is basically that of the impureim sandwich: push everything that can fail out to the periphery. If it's difficult to handle errors at the call site, it's a sign that the call site is in the wrong place.

Re: Lies we tell ourselves to keep using Golang

#477

Post by ohgodplsno »

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…

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

Re: Lies we tell ourselves to keep using Golang

#478

Post by mumblemumble »

azth wrote: post #436
mumblemumble wrote: post #430

Earlier quoted context omitted.

I have barely touched Go, but, from what I've seen, I think I might be able to add a couple more to that: Java is more intimidating to get in to. It starts with "Oh dear, which JDK do I use?", proceeds to, "Oh dear, now I have to pick a build tool and every single one has a near-vertical learning curve by modern standards." Then you're on to, "I want to do X. Why are there 28 competing libraries for X, and why are th…

> but I just wanted to emphasize that I doubt that Java's concurrency story can ever be a match for Go's Project Loom is already targeted for preview for JDK19. Not only does it match golang's concurrency story, it is superior to it.

It's technically very impressive and I'm looking forward to it.

But my point around ergonomics still stands. There will still always be all the legacy stuff, and there's not necessarily any way around having to understand how that works, too, because there's generally going to be some pre-existing library or legacy code or whatever that forces you to.

Re: Lies we tell ourselves to keep using Golang

#480

Post by [deleted] »

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

[deleted]
Post reply on HN