Hacker News Reader

Comment by steinuil | Hacker News Reader

I really dislike Go as a language, it has very few means of abstraction and it feels depressing that people think you have to throw out decades of PLT research to achieve perceived clarity like this.

That said, these reasons are almost all linked to tooling, which is something that I have to admit Go gets right, but they're not intrinsically linked to the language itself and its feature minimalism. I wish there were better languages that had such nice tooling, but unfortunately not all langs have the luck of being backed by Google.

View on HN

Re: getting tooling "right" and that driving adoption/popularity.

I'll argue that Java and the JVM are very similar in this respect. Few will argue Java is a "good" language and the JVM has many shortcomings.

However the ecosystem of IDEs, JVM tools, and decades of big company investment (Sun, IBM, Oracle) have created an amazingly productive environment.

Yes, my impression is that Go was created partly to be used in corporate environments to replace Java with a less verbose language that scaled well, and it seems to be doing well in that regard.

Sadly, it ends up far more verbose than Java when you have (as I did after trying to port a project from java to go) over 200 copies of the same observable, sorted, copy-on-write set implementation, because Go doesn’t have generics. And then you change one thing in one place, and gotta change it everywhere again.

No thanks.

Surely you could have used interfaces for this case, no?

And how do I get the same type out that I put in? I'd end up with Java 1 style programming, no generics, and having to cast atuff from Object/interface{} everywhere.

interface{} is like Object, if it even exists once in your code, it's broken.

> And how do I get the same type out that I put in?

You can only get out the same type you put in. Presumably in your code you know that collection of Foo objects contains Foos, so you can just do:

    if foo, ok = collection.get().(Foo); !ok {
      return errors.New("expected a Foo")
    }

Write a few wrapper functions and you're done.

So, we’re back in Java 1.0, and using Object and just casting back again?

Seriously, this is why generics exist. I want to write it once, use it everywhere again, and want to have the compiler know if I made a mistake.

A couple reasons that wouldn't work well (there may be more, I haven't thought about this much):

1. Using an interface would nuke your performance. Data structures where every data structure operation requires one or more vtable lookups on items in the structure can really hurt your time and space performance. To get good performance, you need true type-level generics so the compiler can specialize at compile time.

2. Anyone could put anything that followed the interface in the data structure, even if it was of the wrong type. To get any form of static type safety, you'd still have to define a wrapper type and a bunch of functions for every type you'd want to put in the data structure. You could save a bit of work by re-using your (slow) code you wrote generically using interfaces.

Ultimately, programmers fall in a bell curve. Most languages which benefit extensively from that research target people on the right of that bell curve. Go, with its lack of complicated mechanics targets the middle of the bell curve.

I don't have the luxury of working exclusively with people on the far right of the bell curve, so I'll end up picking Go with its simplicity for most projects. I can be assured that almost anyone can pick up code written in Go, and be productive much faster as a result.

> Go, with its lack of complicated mechanics targets the middle of the bell curve.

No, it targets the less experienced - interns, as the language creators said.

I don't think Go targets the less experienced. Could you provide a resource, where the language creators have stated that Go targets interns?

Go is a safe programming language, but it is not simple. Go has very rigid rules.

I don't see any difference in complexity between programming in C and programming in Golang. Programming in Golang may even be harder than C.

If you format your code wrong, Golang screams at you.

If you import a package and never use it, Golang screams at you.

If you redefine a defined variable, Golang screams at you.

If you don't use a variable you defined, Golang screams at you.

C is much more forgiving :).

Golang makes dynamic memory management safe, but in nowhere easy. You still use the good old void* via an empty interface. For an intern, garbage collection doesn't matter, an intern is intelligent enough not to leak so much memory so that it will get noticed :).

I sometimes think Golang resembles the early versions of Java. Creating a safer C-like language, with great ideals. With Java the complexity kicked in after a while. Golang still resists the urge to please everyone.

> I don't think Go targets the less experienced. Could you provide a resource, where the language creators have stated that Go targets interns?

"They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." - Rob Pike

> C is much more forgiving :).

I think this is confusing being permissible with difficulty. Because C is permissible, it makes writing correct code in it hard. The fact that the Go compiler has a (relatively) simple type system and is able to point out mistakes like the ones you mentioned makes it much easier to write correct code.

I'd also just like to point out most of the things you list about Go won't cause a crash or undefined behaviour if you were able to leave them in anyway.

As pointed out elsewhere in this thread, interface{} isn't the same as void. void will let you reference anything as a type unsafely leading to undefined behaviour. interface{} carries type information, and while it does cause crashes, it doesn't lead to undefined behaviour.

Also, how is memory management in C easier? Leaking memory is the least of your worries, you could double free, null ptr access, invalid free, have dangling ptrs, etc. Lots of these things are taken care of by Go's GC so you don't have to worry about it.

There is a Go talk where Rob Pike states that.

EDIT:

Found it, https://talks.golang.org/2012/splash.article

"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical."

You just gave some reasons why correctly programming in Go is easier than in C, like paint by the numbers or training wheels (restrictions) versus a blank canvas; it's easier to make mistakes in C, ergo harder to program in. Golang screaming at you is like having a coach.

The compiler complaining when you do things wrong makes it much easier than C to write correct programs, if anything.

Can testify that other people do limit the tools you can use. I was on a project that I couldn't use even use interfaces, streams, classes, or generics because the other programmer was incapable of understanding how they worked. I eventually just switched to a tool that did the work we were working on to solve the problem without programming because that guy despite having a masters degree in CS and ton of certifications was incapable of understanding anything remotely outside of procedural programming.

> ton of certifications

That gave it away.

> I wish there were better languages that had such nice tooling

Have you considered that the reason why go has such great tooling is precisely because of its desperate grip on simplicity and non-configurability -- the very things you might call upon as why it's "bad".

Maybe this correlation is more than coincidental.

While I neither love nor hate Go - I'm really confused about "Go gets tooling right". Is it mostly about the built-in gofmt and compiling to binary? Dependency management is far from right, for example, and so are stuff like hot code reloading, remote debugging, containerized development, etc. How does Go get tooling right compared to, say node/npm or java?

Tooling in regards to formatting: I guess you get to appreciate it when using gofmt automatically with your editor, eg. with Go extension for Visual Studio Code or vim-go.

Turns out pretty much as he says (see given example at play.golang.org). You just type in the style you always have, but with the certainty that in the end it will be the same as the other's, easy to read, easy to maintain, and uncontroversial in terms of formatting. You could agree on google-java-format, I guess. But also potentially waste plenty of time on the decision itself :-) compared to a dictate and tool originating from the language itself.

Google doesn't invest heavily in Go. It almost certainly invests more in JS, Python, Java, and C++. I think the difference is philosophical--Go doesn't pretend that every obscure edge case deserves equal support to the main case, and so its tooling is much simpler.

I'm not sure where you get your information from, but Google definitely invests a substantial amount in Go.

- Paid some of the most celebrated engineers to work on it full time. - Support it as a first class language in GCP - Support it as a first class language internally

If you want to see a language Google doesn't invest much into, look at Dart

Even dart has substantial investment. Look at flutter, the new cross-platform ui toolkit for dart, and its use in Fuchsia.

Google pays a small team to maintain the language, but developing the language is very likely not a business objective in remotely the same capacity as .Net is for Microsoft or even Swift for Apple. It's not even a major headliner for Google's I/O conference. I would like to know where you're getting your information about Google not investing in Dart, because last time I checked, Google appeared to be investing considerably in Dart (this was back before the Dart vs TypeScript battle was settled though, so perhaps Google pulled up its investment).

At any rate, Go's tools don't require significant investment because they are designed for simplicity (there is no package repository, no language-agnostic/fully-imperative build scripting language or project metadata files, no bring-your-own-unit-test-framework, no docstring syntax, etc). Go tools err on the side of supporting too few use-cases, where Java, Python, .Net, C++, etc build tooling typically emphasize explicit configuration over sane defaults.

Does someone want to give a reason for down voting this comment? There isn’t anything controversial here. For myself, lack of genetics are enough reason not to use the language. My personal style relies a lot on them and I don’t see myself sacrificing that power for above average tooling.

> For myself, lack of genetics are enough reason not to use the language.

The typo/autocorrect here turns this into a much more controversial statement...

Reply on news.ycombinator.com