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

481–490 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#481

Post by dylanowen »

mumblemumble wrote: post #474
dylanowen wrote: post #457

Earlier quoted context omitted.

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.

Yeah good point. I would not enjoy adding Scala throughout an established Java project unless I could really compartmentalize it

Re: Lies we tell ourselves to keep using Golang

#482

Post by azth »

mumblemumble wrote: post #478
azth wrote: post #436

Earlier quoted context omitted.

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

The whole point of Loom is to keep using legacy (blocking) calls, and the JVM will automatically take care of things for you.

> and there's not necessarily any way around having to understand how that works

Same with golang, you have to understand how things work. The entire narrative that golang is "simple" is just not true. The moment things start to go wrong, you're going to have to understand how things are working behind the scenes.

Re: Lies we tell ourselves to keep using Golang

#483

Post by hu3 »

jhugo wrote: post #469
hu3 wrote: post #467

Earlier quoted context omitted.

And others are free to disagree with your opinion. I read the content as lacking maturity, emotionally loaded and not the kind of content that fosters productive conversation in HN (as can be evidenced by the caliber of most comments in this thread). The post is not explicitly flagged but nowhere to be seen in HN first pages. Take that as a hint.

> The post is not explicitly flagged but nowhere to be seen in HN first pages. Take that as a hint. It's been almost 24 hours since it was posted, a majority of posts are buried by then. The post seems to have followed a fairly normal lifecycle. I am not a huge fan of the tone of the OP either, but it does have substantive content and discusses genuine issues (though it probably is not the best way to trigger discuss…

> It's been almost 24 hours since it was posted, a majority of posts are buried by then.

No. Here's a post with much less upvotes, much less comments still on page 2: https://news.ycombinator.com/item?id=31205139

There are many other examples if you care to compare.

Meanwhile this post is nowhere to be seen because most conversation here is not up to HN standards.

Flagging is detrimental to post ranking. And rightfully so.

Re: Lies we tell ourselves to keep using Golang

#484

Post by AnimalMuppet »

delta64 wrote: post #462
AnimalMuppet wrote: post #303

Earlier quoted context omitted.

== should do the obvious thing. But with operator overloading, it's not clear that it does , unless you need to read the implementation of == very carefully.

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.

Re: Lies we tell ourselves to keep using Golang

#486

Post by nottst »

DrMeepster wrote: post #244
collegeburner wrote: post #35

Earlier quoted context omitted.

Also honestly it's very toxic to anybody right of center. It's the type that says "we're so accepting" when really they only are of certain stuff. Lots of pronoun people and making the mascot "non binary" is needlessly shoving their ideology down people's throat. Not a problem in the U.S. because it fits with the corporate woke ideology but sure as hell gonna be if they want more worldwide community. It's also way to…

"pronoun people" What, you cant handle queer people existing?

No post body was provided.

Re: Lies we tell ourselves to keep using Golang

#487

Post by dragonwriter »

samhw wrote: post #316
DrMeepster wrote: post #244

Earlier quoted context omitted.

"pronoun people" What, you cant handle queer people existing?

Quoted post unavailable.

> Their comment is about the (almost universally straight) people who demand to be called 'xe' or 'qwerty' or whatever.

The vast majority of people I’ve seen using neopronouns, or “it” or “they” pronouns (either exclusively or alternatively with classical gendered pronouns, e.g., “she/they”) have nonbinary gender identity or agender identity, and the vast majority of the exceptions are trans, and all the rest (i.e., the cisgender ones) I’ve encountered are one of bisexual, pansexual, asexual, or same-gender attracted, usually also with gender non-conforming presentation.

I have yet to encounter a cisgender heterosexual with nontraditional pronouns for their gender, though I am sure there are some somewhere doing it.

Re: Lies we tell ourselves to keep using Golang

#488

Post by prirun »

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…

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

Here's a counterexample from HashBackup (I'm the author):

A filesystem is being backed up. Some weird error occurs, let's say it tries to read an extended attribute and gets some goofy error that raises an exception and it's not in a try/except. That error bubbles up to the try/except for "save a file", prints the exception message, and continues by backing up the next file.

Is it more reliable to crash when reading an extended attribute, aborting the whole backup? Or is it better to just tell the user about the error, finish the backup, fail at the end of the backup with a non-zero exit code, and report it in an email?

At the time of failure, the only way I can see that the error could have been handled at the call site would be to return an empty extended attrbute. To me, that's more like the "silent but wrong" solution. And there are many of these situations for saving a single file: get the flags, read the extended attribute, read the permissions and times, figure out if it's sparse, etc. Instead of having error handling at each of these steps, they can have no error handling and just raise exceptions and the high-level "save a file" handler will do everything.

Of course, along the way there are some low-level try/except blocks around code that needs cleanups, like:

  fd = None
  try:
    fd = os.open(...)
    do some stuff
  finally:
    if fd != None:
      os.close(fd)
But you have the same thing with defers in Go.

Re: Lies we tell ourselves to keep using Golang

#489

Post by bayesian_horse »

sophacles wrote: post #322
bayesian_horse wrote: post #233

Earlier quoted context omitted.

Many people say Go is a better language to scale a codebase than Python, mainly because of typing, but I really doubt it. I can't tell for sure, because I haven't done a lot of Go coding. But to me the stated problems and the general lower-level nature suggest a productivity loss compared to Python, on average.

I've written lots of python. Biggest codebase had ~100Ksloc of it. I currently have a ~80Ksloc codebase in Go. I like python. I dislike go. I still hold the position that scaling a codebase is easier in go than in python. * Goroutines + channels are generally easier for someone besides the author to reason about than their python equivalents, leading to a more consistency and better boundary definition. * Python has…

For me it is hard to attribute such differences to a programming language rather than the people creating and maintaining the code.

At the moment I am maintaining a C# codebase which doesn't feel maintainable at all, and I don't think C# is the only problem there.

Re: Lies we tell ourselves to keep using Golang

#490

Post by jhugo »

hu3 wrote: post #483
jhugo wrote: post #469

Earlier quoted context omitted.

> The post is not explicitly flagged but nowhere to be seen in HN first pages. Take that as a hint. It's been almost 24 hours since it was posted, a majority of posts are buried by then. The post seems to have followed a fairly normal lifecycle. I am not a huge fan of the tone of the OP either, but it does have substantive content and discusses genuine issues (though it probably is not the best way to trigger discuss…

> It's been almost 24 hours since it was posted, a majority of posts are buried by then. No. Here's a post with much less upvotes, much less comments still on page 2: https://news.ycombinator.com/item?id=31205139 There are many other examples if you care to compare. Meanwhile this post is nowhere to be seen because most conversation here is not up to HN standards. Flagging is detrimental to post ranking. And rightful…

... really? Come on. As of this writing, 29 out of 30 posts on page 2 are younger than this post. 30 out of 30 posts on page 3 are younger than this post. 29 out of 30 posts on page 4 are younger than this post. I could keep going. The fact that you can find one outlier and then wave your hands and say "there are many more" doesn't make your argument reasonable.

> Flagging is detrimental to post ranking. And rightfully so.

As I understand it, flagging is to get moderator attention to posts that don't follow the HN guidelines. It's not the general way to punish posts that upset you, that's called downvoting. Treating flags as a "stronger downvote" basically makes the very concept of flagging worthless.

Post reply on HN