Hacker News Reader

Comment by kasey_junk | Hacker News Reader

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 existing language designers that want to increase the popularity of their language) it seems like things like language ergonomics, power, etc are less important than having a standard batteries included development stack coupled with out of the box "good enough" performance.

View on HN

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

No, it's not safe. It's basically a way to disable compiler checks, so it is by definition, not safe.

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"

True, now imagine that program was controlling some kind of device and due to the panic it wasn't able to turn the device off.

That's "shitty programmer", not bad language. You can catch panics, and there's a panic safe "val, ok := ival.(type)" assertion.

Same thing could happen due to bailing out of a function with a return, after checking some condition.

  if (bad_thing)
    return ERR_BAD_THING;

  ... code here to turn off controlled device ...

From my understanding from prior HN discussions, panic is paired with recover; it's a kind of typeless non-local jump and unwind mechanism which can be intercepted. If the device must be turned off, then any panics must be intercepted and code must be executed to put the device in that state.

> 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 you ship code that is provably incorrect and that will not work once deployed (it will exit, like you say).

This is why I said "it's unsafe".

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

> It is usually better for a program to crash than for it to continue having corrupted its data

And it's even better to no let this program get corrupted data in the first place, which languages with a weak type system (such as Go) allow to happen whenever you use `interface{}`.

> I said "it's unsafe", not "it's not safer than void".

I'm sorry, but then you're simply in the wrong thread. You where replying to a interface{} vs. void comment, so that's what you should be talking about.

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.

I don't care what we call it, it's still confusing as hell.

Yeah, indirection can be confusing to new programmers, but its absolutely fundamental, so it's better to get used to it than to complain about it.

Except I have 32 years of daily practice and plenty of experience from most paradigms/languages/kinds of software out there. I'm guessing similar goes for some of the hundreds of people who complain about the same thing.

This attitude is exactly why many choose to stay away from Go and its community. The constant denial of any problems and claims that everyone else got it wrong. I don't know where it started, most probably Pike & co; but its not very constructive.

If you think that's my attitude, you don't know me. I have lots of criticism for the language, but pretending a pointer isn't a pointer isn't the solution to people not understanding indirection.

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.

Your mental model for an interface is incorrect--an interface is just a pointer. A pointer can be nil, but some pointers point to other nillable types. If we paper over this for nil checks, we destroy states that are semantically valid/important. Abstracting as you propose creates more surprising behavior than it fixes. On the other hand, all it takes to avoid the problem altogether is the understanding that interfaces are just (fat) pointers.

My mental model is just fine, thanks; I've written about 70k lines of Go, and I'm perfectly aware of how it works. I'm saying it's a misfeature. interface{} is a leaky abstraction.

It's definitely a leaky abstraction, but not for the reasons you mentioned. Your proposal just adds more leakiness on top of it.

> Here, both x and y are conceptually nil, but y cannot be compared to nil.

I disagree with the "conceptual nilness" of y. x is a perfectly fine and usable implementation of io.Closer. It doesn't even panic. Having a nil-check (i.e. "does this interfaces contain a value?") return true seems dishonest to me.

I agree, that it was a bad choice to call both the zero-value of pointers and the zero-value of interfaces "nil". But in general, the possibility of nil-pointers being valid values and implementers of interfaces is useful. For example if you have a linked list or graph-structure.

I also asked about it on reddit and got this answer: https://www.reddit.com/r/golang/comments/6sktsr/typed_nils_i...

Memory safe, yes. Type safe, no.

Yes, Type safe. You can not interpret something as a different kind of type via the use of interface{}. Contrast that with void-pointers, which make that so easy as to be a common bug-source.

It's not statically type-checked, yes. That's fine too, in my opinion, but also irrelevant for a comparison with void-pointers (because they also don't provide that).

In summary, interface{} is strictly better than void-pointers. Which was exactly my point. Equating the two is intellectually dishonest.

> Yes, Type safe. You can not interpret something as a different kind of type via the use of interface{}.

Interesting; for some reason, I was under the impression that you could cast an `interface{}` arbitrarily, but from trying it out, you're absolutely correct. (I should definitely make sure to try these things out before confidently asserting about them...)

> interface{} is strictly better than void-pointers

No arguments here; even if for some reason they weren't type safe (which they are, much to my surprise), I'd still agree with you there.

interface{} carries runtime type information in its internal double-word (type + pointer) structure, unlike void*.

Distinction without a difference, talk about Object if you prefer, the only difference is that downcasts are runtime-checked, it remains a huge hole into the typesystem.

> Distinction without a difference

This seems pretty misleading to me. Sure, it's a hole in the type system, but not a hole in memory safety, unlike void*.

(Even the fact that it's a hole in the type system isn't particularly interesting. Most languages have holes in their type systems, by design. What's important is the amount of use it gets, which is of course somewhat-frequent in Go. Same with void in C, so at the type system level, I agree that there isn't too much to distinguish other than quibbling about frequency of use.)

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

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.

> But interestingly, while I program go every day, I sort of hate it as a language.

I have the exact same feeling. There's a lot wrong with Go, but it makes up for its problems by having very nice tooling (though of course there's problems with that too).

After having coded tens of thousands of lines in Golang for 4 years, there are a list of probably hundreds of grievances I have about the language itself. The problem is that they're generally outweighed by the simplicity, consistency, and clarity of the language. Is the error system terrible? Obviously. Lack of abstract data types? Awful. Is Rust one thousand fold safer and more syntactically powerful by comparison? Sure.

But the fact is, in a world where we as developers often are learning and working in a new language every year or two, time-to-productivity and proficiency in a given language is one of the most important, if not the most important, metrics for a language. And Golang knocks this out of the park with its obvious syntax and great tooling. You can bring in a new junior programmer onto your Golang stack and have then turning out useful pull requests in a week or two, which I can't say for languages like Rust.

I _hate_ much of Golang's engineering, but for collaborative programming I think anyone would agree that it's a highly productive language.

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 install. My clients wouldn't need to install and maintain the VM.

In the end I wonder why switch to a new stack just because? I understand learning the languages to see if they are better tools. I understand learning for the sake of learning. But why bet a business on a new language just because it's cool?

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 often take at least ten seconds. In prod this doesn't matter. But a cheap app start means integration tests are cheap. An fs hook runs both unit and integration tests every time the code changes.

ps. all the things people hate about go are true

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.

Depends what your server is doing, java app binded to http port will take probably same amount of time.

My dropwizard server contains almost all possible batteries: ssl, logging, http filters, static content, metrics, DB connection pooling, static content serving, all kinds of URL parameter parsing and URL routing, DI framework, ORM, thread pooling. I think it just inspects and initializes all this data structures in memory, load libraries and classes, etc.

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

I noticed as well that I didn’t mention a single language feature, even though I do actually like many :).

I agree with the sentiment you expressed: the overall experience when using a language matters to me much more than individual language pros or cons.

> the only point directly related to that is that go has a short list of reserved words (which is true of most languages).

The number of keywords of a language is completely unrelated to its complexity (see Brainfuck or Lisp).

On the other hand, see ABAP. https://www.slideshare.net/PrakashThirumoorthy/complete-list...

SAP ABAP syntax includes:

+ database retrieval and manipulation as a 1st class concept. ABAP doesn't require a 3rd-party ORM and therefore, SQL statements are 1st class syntax.

+ GUI capabilities as 1st class syntax (user interface elements for forms, lists, grids, visual reports, etc)

Golang core doesn't have those, so it understandably doesn't need extra official keywords to address that functionality.

SAP ABAP has more keywords that's typical for a 4GL type of language. Like other business-domain 4GLs, the complexity isn't the language syntax -- it's navigating the gigantic data model to find where important information lives. (e.g. Out of 10,000 tables, where does the sales invoice live? If an invoice is paid, where is that status field? And to make it harder, many of the database column names are German instead of English ... like AUGRU[1] for "auftrag grund" instead of English "OREASON" for "order reason".)

If Golang language spec was revised to include a 1st-class ORM and GUI & report builder into its core syntax, it would be a more apples-to-apples comparison. Golang can have less keywords, because it has less features.

[1] http://www.se80.co.uk/saptables/v/vbak/vbak.htm

> Golang can have less keywords, because it has less features.

So, you are saying… because it's less complex?

No. I don't think Golang is "less complex" because it has less features than ABAP _if_ you plan to use Golang to write GUI applications that interact with databases to track enterprise data of sales, purchase orders, manufacturing, inventory control etc.

"Complexity" is not a useful label unless you look at what you're actually building:

- If the goal is to show "hello world", yes Golang is "simpler".

- If the goal is an ERP system, Golang is way more "complex".

Between those 2 extremes requires analysis on a case-by-case basis.

This is the same reason I rolled out Salesforce for a couple workflow apps for a few teams in our company.

I could bootstrap a .Net/Java/whatever app to do the same thing, but our team is swamped with a backlog years long - I could only afford a couple days to develop and release this so a dozen Force.com licenses ended up saving tons on development and ongoing maintenance costs.

>But interestingly, while I program go every day, I sort of hate it as a language.

I would be interested in asking you to put some of these thoughts down. This can be contentious as it's matters of taste (i.e. I don't want others to reply to you defending it), so if you wanted you could email me - my contact is in my profile. Just a few thoughts -- i.e. what you had in mind when you wrote that -- would be really helpful for me.

What makes you hate the language?

Thanks so much for any thoughts.

Reply on news.ycombinator.com