Live data from Hacker News

Why Go is my favorite programming language

michael.stapelberg.de

161–170 of 256 posts

Re: Why Go is my favorite programming language

#161
post #55

Earlier quoted context omitted.

One thing I've been looking at lately is the various strands of engineering (civil, electrical, mechanical). I've been looking for common threads and general principles that apply to software engineering that otherwise haven't been. A part of what inspired that search is what you discuss: a huge amount of rework. Tools that shift like sand dunes. Many principles and best practice based on "this is what worked for us"…

Maybe the other engineers would love to be able to do more rework, but since they deal with hardware, changing things is a lot more expensive. Why do you think that their ways are superior? Construction projects too run way over budget and sometimes even fail, just like software.

You make a good point. Maybe their ways aren't superior - I didn't consider this. In that case, perhaps the issue isn't because we need to be more like other engineering disciplines but less like.

I'm feeling for answers. I'm not saying I know what we need. I am, like I think everyone else is, still in the observation stage looking for hypotheses.

I did find evidence based software engineering. This offered some interesting papers. I recommend this. There isn't much and it's far away from a cohesive theory but hopefully we can get there, as a field, soon.

If someone is further along, or has some ideas, I'd love to speak with them.

Re: Why Go is my favorite programming language

#162
post #121

Earlier quoted context omitted.

Why learn a new language just to learn a new language for production stuff? I looked at at switching to Go from Java for my flagship product. I couldn't find enough compelling reasons to switch. It didn't offer enough benefits to outweigh the benefits of Java + Spring Boot. As a result, Java it is. Now for a new product that I might sell as traditional installed software, Go makes some sense here since it simplifies…

> My clients wouldn't need to install and maintain the VM Why should they? One can always deliver everything together. Not much different than static linking. Also there are AOT compilers and with Java 9 we are getting a linker to create customized JREs.

I'm waiting for the 9 features. That should make things easier. Since I'm targeting small physician practices, I need to make everything as simple as possible. I've even toyed with Raspberry Pi as the install device. From what I've read, Go is a good option for this.

Re: Why Go is my favorite programming language

#163

Earlier quoted context omitted.

It is way safer than void * : A void * can be cast to (and then used as) any arbitrary type, leading to all sorts of undefined behavior. On the other hand, the following code will just panic() (i.e. exit cleanly without corrupting memory). var x int = 5 var i interface{} = &x *(i.(*string)) = "boom"

> It is way safer than void * I said "it's unsafe", not "it's not safer than void*". > (i.e. exit cleanly without corrupting memory). This makes no sense. If it exits, who cares if the memory of the process is corrupted? Also, this is the point: it exits instead of the compiler telling you this code will crash before you ship it. That's the point of static type safety (which Go doesn't provide in this case): it lets…

> If it exits, who cares if the memory of the process is corrupted?

People care when memory is corrupted without the process exiting. It is usually better for a program to crash than for it to continue having corrupted its data. The former gives you x-ray machines which sometimes won't start, whilst the latter gives you x-ray machines which sometimes give the patient cancer.

I say better, not best. Best, obviously, is for as many failure modes as possible to be detected before the code is deployed. Particularly if you're programming a machine that can kill people. But in the comparison between Go's interface{} and C's void*, neither language has that option.

Re: Why Go is my favorite programming language

#164
post #107
post #21

I have said it before and I will say it again - for all the deficiencies Go has, it is somehow highly compatible with the way my brain works. One point the article does not mention is the documentation. I think Go's documentation is excellent, it does not overwhelm the reader with its volume, but mostly anything one might want to know about the syntax and semantic can be answered by carefully reading through the docu…

Go is an alternative for C (for services), PHP, and server-side JS. I don't understand why people keep comparing it to languages like C++, C#, D, Java, Rust, or Scala. The problems these two sets of languages solve are fundamentally different.

>The problems these two sets of languages solve are fundamentally different.

I'm afraid I fail this intelligence test. What problems are solved by C, Go, PHP and server-side JS but not by any of Java, C++, C#, D, Rust or Scala (and vice versa)?

This seems like a completely arbitrary classification to me.

Re: Why Go is my favorite programming language

#165

> There is a cost to introducing an abstraction layer. Go code is usually rather clear, at the cost of being a bit repetitive at times. Go programmers say this a lot and every time I see it I wince. We've had all sorts of flights of fashion and fancy in the programming world, but one observation has emerged that seems closer to fact every time we test it: more code is more bugs. The more code you write, the more chan…

I love the error handling in Go. Every other language I've used led to the inevitable and useless "An error was encountered" message. Go is the first language where I can actually access the original socket permission error because it was actually passed up.

Pretty much every language has this: Java, Python, Ruby, Haskell, OCaml, C++... The only major language that I can think of that doesn't have a standard error propagation mechanism is C.

Re: Why Go is my favorite programming language

#166

Earlier quoted context omitted.

My team just chose golang instead of java or dotnet core for a new crud app. I'm not especially fond of go, but mean length of feedback loops are worth it (so far). We have a bunch of tests, and they all run in a few hundredths of a second. Same coverage in java is usually several seconds at least. Often up to 30s if running tests with maven. Standing up the app is also instantaneous. Spring boot apps with hibernate…

There are lighter options in java world, my dropwizard server with JDBI starts in 1.2sec.

I'm genuinely unsure if this is a joke. If you're running that on a modern computer, your server is spending billions of clock cycles starting up. What on Earth is it doing? :)

If I write a Go server, I'm unhappy if it takes more than 0.2 seconds to start.

Re: Why Go is my favorite programming language

#167

If I were to build a list of the reasons I use go, it wouldn't be terribly different than this one. But interestingly, while I program go every day, I sort of hate it as a language. You'll note this list doesn't actually have much to do with the language per se, the only point directly related to that is that go has a short list of reserved words (which is true of most languages). So for future language designers (or…

> language ergonomics, power, etc are less important than having a standard batteries included development stack To programmers under twenty five. And that explains not only Go, but volumes of computing history.

There could be a valley around 30 where you prefer purity. It's possible though that you soon get tired of language wars and prefer something that makes it easy for you to get things done, i.e. a complete standard library and a good package manager. (And no, I personally don't use / particularly like go but I think your statement is wrong.)

Re: Why Go is my favorite programming language

#168

If I were to build a list of the reasons I use go, it wouldn't be terribly different than this one. But interestingly, while I program go every day, I sort of hate it as a language. You'll note this list doesn't actually have much to do with the language per se, the only point directly related to that is that go has a short list of reserved words (which is true of most languages). So for future language designers (or…

> language ergonomics, power, etc are less important than having a standard batteries included development stack To programmers under twenty five. And that explains not only Go, but volumes of computing history.

That seems a little unfair. I have better things to do with my programming time than reinvent the wheel every time I need to manipulate common data structures, or make an HTTP request, or query a database, or parse a CSV file, or do some mathematics efficiently, or draw a picture showing the results of that mathematics.

I’m some way past 25 these days, but if there is one lesson I’ve learned about programming languages over the years, it is that a good supporting ecosystem usually is worth more than even quite substantial improvements in the language itself. It’s not that language improvements aren’t welcome — I think some programming languages are much better than others. However, you’re always going to be limited in how productive you can be with a language that lacks comprehensive libraries or good tools or enough people using it to discuss interesting issues or hire a full team of staff, no matter how brilliant the design of the language itself might be.

I don’t know what the worst mainstream programming languages are today, but in purely technical terms surely C, Java and JavaScript all make the shortlist. Compared to many other contemporary languages, these three all lack features, often take a lot of code to get quite simple things done, and are full of easy ways to make mistakes. And yet, in terms of how much useful software has been written in them, they are among the most successful languages we’ve ever had. Why? At least in part, I think it’s because they have three of the most well-developed ecosystems around them.

Re: Why Go is my favorite programming language

#169

Earlier quoted context omitted.

> go has a short list of reserved words I use go a lot now. However, I must admit I find the use of interface{} "aka empty interface, aka void*" a weird one. It's technically correct, but it's an odd semantic.

I know this is repeated often, but only because it apparently still has to: interface{} is very different from void*. It carries type-information with it. That makes it safe.

Memory safe, yes. Type safe, no.

Re: Why Go is my favorite programming language

#170
post #78

Earlier quoted context omitted.

Safe as in nil not even being equal to nil any more, I know I'll sleep better.

nil is always equal to nil. You might be confusing it with comparing a nil pointer to a pointer to a nil pointer, which are not equal.

The nil-interface wart actually does result in comparison issues, and it's something that trips people up all the time:

    package main

    import (
      "fmt"
      "io"
    )

    type Thing struct{}

    func (t *Thing) Close() error { return nil }

    func main() {
      var x *Thing
      var y io.Closer = x
      fmt.Printf("x == nil -> %#v\n", x == nil) // true
      fmt.Printf("y == nil -> %#v\n", y == nil) // false
    }
Here, both x and y are conceptually nil, but y cannot be compared to nil.

Go is a strict language, but it's curiously lax about many things, including this. "go vet" won't even warn you that you're unintentionally wrapping nil in an interface. This goes way beyond just a trivial example like the above one, though: Any general-purpose code that has to deal with arbitrary interface{} values can't just check for nils, but need to do things like this:

    func UnwrapReflectValue(v reflect.Value) interface{} {
      if !v.IsValid() {
        return nil
      }
      if v.IsNil() {
        return nil
      }
      if v.Kind() == reflect.Ptr {
        v = v.Elem()
        if v.IsNil() {
          return nil
        }
      }
      if v.Kind() == reflect.Interface {
        v = v.Elem()
      }
      return v.Interface()
    }
I don't know why Go doesn't let "y == nil" return true here; boxed values are supposed to have the same high-level semantics as unboxed ones, and off the top of my head I can't think of any code where changing the current behaviour would cause breakage.
Post reply on HN