Lies we tell ourselves to keep using Golang • Hacker News Board

Re: Lies we tell ourselves to keep using Golang

#451

Post by zozbot234 » Sat, Apr 30, 2022, 7:31 AM UTC

HerrmannM wrote: post #418

2014 Story Time, when I was a phd student working on programming languages (apologies for my broken English, non native speaker here). The multidisciplinary lab I was in had a "Go or Rust" dilemma. As the language guy, I was asked for my opinion. I had no experience with Go, and a small bad one with Rust: there was weird stuff going on with pointers, and even seemingly simple programs would fail to compile due to a l…

Rust was very much half-baked in 2014. Version 1.0 was released in 2015, and critical features for dev UX like non-lexical lifetimes or async weren't supported at all until late 2018. In fact, Rust would've been a terrible choice back then. Lots of people seem to miss that, but it's also why this whole anti-Golang flamewar is so pointless: a lot of the Golang stuff out there is not greenfield, but was written back when there was hardly any reasonable alternative to it, and certainly nothing like modern Rust was available.

Re: Lies we tell ourselves to keep using Golang

#452

Post by erik_seaberg » Sat, Apr 30, 2022, 7:32 AM UTC

aw4y wrote: post #46

alkonaut wrote: post #34

Earlier quoted context omitted.

The point of these articles and other opinion-making (such as right here on HN) is that we don’t choose tools. We are given the popular tools. They are popular because other developers chose them at the companies were we work. And they chose them because they thought they would be suitable for the purpose. So if you want to do everything in your power to prevent a tool you think is terrible from being more popular -…

Why should I care if Go/Rust/anything else becomes popular? I don't expect that if I don't "fight" against a language I'll be forced to use it in 2 years: there will be space for different techs, tools and so on. I can agree with you if we talk about "tools" that attacks our privacy, our rights and our freedom: spend you time convincing people to abandon facebook or something similar and you'll do something good. But…

> I don't expect that if I don't "fight" against a language I'll be forced to use it

I didn’t used to worry about this until it started happening to the sharp, experienced Scala/Java team I’m on by preference. Other teams are now deploying half-finished platforms on which only Go is supported fully, or sometimes at all.

Re: Lies we tell ourselves to keep using Golang

#453

Post by erik_seaberg » Sat, Apr 30, 2022, 8:15 AM UTC

cglan wrote: post #254

noisy_boy wrote: post #234

Earlier quoted context omitted.

> 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

It’s worth remembering that Spring Boot didn’t exist for the first nineteen years we used Java.

Re: Lies we tell ourselves to keep using Golang

#454

Post by kristoff_it » Sat, Apr 30, 2022, 10:17 AM UTC

Thaxll wrote: post #363

formerly_proven wrote: post #362

Earlier quoted context omitted.

> it's very powerful and I don't know a single language that does it out of the box like go does. zig build -Dtarget=x86_64-windows

I'm talking about mainstream language not stuff in dev. And go has been doing that for 10years+

well, not exactly. Zig is also crosscompiling C/C++ code, not just Zig. CGo doesn't do cross-compilation.

Re: Lies we tell ourselves to keep using Golang

#455

Post by atombender » Sat, Apr 30, 2022, 10:32 AM UTC

foldr wrote: post #58

fasterthanlime wrote: post #50

Earlier quoted context omitted.

I moved some words around to make the nit less confused - thanks for the feedback!

Still not seeing it. You don't have to use interfaces to make an opaque type. A package boundary is sufficient. Not sure why you would want a fully opaque type internally to a package anyway. A regular `type Foo Bar` declaration is sufficient to give you a `Foo` that can't be accidentally interchanged with a `Bar`.

One impediment is that Go cannot prevent the construction of invalid values, because every type has an implicit zero value:

  type NonZeroInt struct {
    v int
  }

  func (n NonZeroInt) Get() int {
    return n.v
  }

  var n NonZeroInt  // invalid!

You could of course validate on read:

  func (n NonZeroInt) Get() (int, bool) {
    if n.v == 0 {
      return 0, false
    }
    return n.v
  }

…but that's hardly good design.

You can improve on this marginally with an interface, because an interface's zero value is at least nil, which is, at least, explicit about whether there is a value or not. But it's not very elegant:

  type NonZeroInt interface {
    Get() int
  }

  type nonZeroInt struct {
    v int
  }

  func (n nonZeroInt) Get() { return n.v }

  func ToNonZeroInt(v int) (NonZeroInt, bool) {
    if v == 0 {
      return nil, false
    }
    return nonZeroInt{v}, true
  }

The biggest problem with this approach is that it adds overhead. It can also force values to be heap-allocated, though I believe Go will still optimize single-word interface values to avoid this.

Note that since Go interfaces use structural typing, naming the method Get() can cause issues:

  type AnyInt struct {
    v int
  }

  func (n AnyInt) Get() int {
    return n.v
  }

Now AnyInt fulfills the NonZeroInt interface, which is of course not something we want. So for types like these, it's a good idea to name the method explicitly:

  type NonZeroInt interface {
    GetNonZero() int
  }

Re: Lies we tell ourselves to keep using Golang

#456

Post by foldr » Sat, Apr 30, 2022, 10:46 AM UTC

atombender wrote: post #455

foldr wrote: post #58

Earlier quoted context omitted.

Still not seeing it. You don't have to use interfaces to make an opaque type. A package boundary is sufficient. Not sure why you would want a fully opaque type internally to a package anyway. A regular `type Foo Bar` declaration is sufficient to give you a `Foo` that can't be accidentally interchanged with a `Bar`.

One impediment is that Go cannot prevent the construction of invalid values, because every type has an implicit zero value: type NonZeroInt struct { v int } func (n NonZeroInt) Get() int { return n.v } var n NonZeroInt // invalid! You could of course validate on read: func (n NonZeroInt) Get() (int, bool) { if n.v == 0 { return 0, false } return n.v } …but that's hardly good design. You can improve on this marginally…

Using interfaces here seems unnecessarily complex. If the default zero value were an issue in practice, I would just define

    type NonZeroInt *int

    OR

    type NonZeroInt struct { v *int } // (if you want it to be fully opaque)

so that the program would panic on an attempt to do arithmetic on the nil value. That achieves the same effect as your code, but without the unnecessary interface definition and the resulting naming issues. (Though note that Go does make it possible to export an interface from a package that no-one outside the package can implement. All you need to do is add a dummy private method to the interface.)

It's true of course that the pointer adds runtime overhead, but two points:

(1) Go is not really advertised as a zero cost abstraction language (in contrast to e.g. C++, Rust). So yes, building nice abstractions in Go will sometimes have a runtime cost. If that is unacceptable in a given application, then Go is not the right tool for the job. I'm not a Go zealot. If you need to do this kind of thing all over the place in your code base, then sure, don't use Go.

(2) If you are dealing with large arrays of non-zero ints (such that the overhead of boxing would be significant) then you could always define NonZeroIntArray.

Re: Lies we tell ourselves to keep using Golang

#457

Post by dylanowen » Sat, Apr 30, 2022, 12:33 PM UTC

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…

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.

Re: Lies we tell ourselves to keep using Golang

#458

Post by the_gipsy » Sat, Apr 30, 2022, 12:56 PM UTC

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…

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!

Re: Lies we tell ourselves to keep using Golang

#459

Post by hu3 » Sat, Apr 30, 2022, 1:01 PM UTC

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 agree. The signal to noise ratio of these "Rust vs Go" post comments is so bad they border being mostly a pile of anecdotes.

Also not meant to diminish the blogger but if you check their posts, it almost seems they feed on Go flamewar.

I could read every one of the 443 comments and still come out with zero knowledge gained because that's the kind of comment these posts incentivize.

Startups were built with less man-hours than what was collectively wasted on this thread.

Re: Lies we tell ourselves to keep using Golang

#460

Post by delta64 » Sat, Apr 30, 2022, 1:11 PM UTC

SeanLuke wrote: post #334

delta64 wrote: post #63

Earlier quoted context omitted.

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.

The obvious thing is to check if the contents are equal. I don't know what cursed C++ you're looking at if you're finding a ton of string implementations not doing exactly that...