Hacker News Reader

Comment by randomdata | Hacker News Reader

> Ignore comments about how go is simple to write.

Do people say that? I've never heard anyone claim that Go is simple to write.

Pike, I believe (may have been someone else), claimed something to the effect that new grads with limited exposure to real-world codebases were able to understand existing projects written in Go more quickly than in other languages at Google. I have seen that message distilled down into "Go is simple to read."

Go was built on the premise that people spend more time reading code than writing code and Go attempts to make tradeoffs towards reading optimization rather than writing optimization. Whether or not it is successful in that is another topic for another day.

View on HN

Go is very simple to read and to write, I'm not sure how one can argue against that.

Without prior knowledge you can jump into any code base and won't be suprised by something you never seen before or does not understand what it does. The language is simple to grasp because it has just a few concepts and keywords.

If by "read" here we mean "grok" — i.e. to read and understand well-enough to be able to modify without breaking the abstract guarantees the code makes, without documentation — then I would say that the low level of Go's concurrency primitives (relative to other languages modelling the same actor-based architecture, e.g. Erlang) means it takes more effort to "read" production-quality (concurrent, fault-tolerant, no resource-leaks, no data races) Go code relative to production-quality code written in other languages.

Sure, when reading Go, you aren't really encountering new language features; but you're often being forced to recognize things that should be language features, which are instead implemented as design patterns. (And, at that, often with those patterns reified into code by new-ish programmers who don't understand those design-patterns very well, rather than by language maintainers after much careful scrutiny.)

It's like doing OOP in C, and having to mentally parse vtable structs into the object-model they represent — with every project having done its own vtable implementation, all slightly different. Except that OOP is unusual in C, while concurrent infrastructure is near-universal in Go.

When reading Go, I'm essentially mentally "decompiling" it as I go into a higher-level representation within my mental-model. "These 50 lines are a parallel map-reduce; these 200 lines are a read-through cache with per-key synchronization to avoid duplicate work; etc." I'd rather just read that higher-level representation directly!

As someone who cut their teeth on programming via C and c++ Go did come surprisingly easy. My first interaction with it was a small change to a web thing and I had no trouble reading source code, understanding it, and making the necessary changes without ever learning to write a line of Go before. That alone is value.

To me Go feels like a "modern" C language from 90's Bell Labs. Of course that is kind of true as Go is the spiritual successor to Alef and Limbo. Though it feels like it came out 10+ years too late.

> To me Go feels like a "modern" C language

That was the stated intent at the time Go was envisioned. They missed the mark a bit by not making Go a systems language, but oh well.

Yes, Go is what Java 1.0 should have been, in 1996.

That was supposed to be Inferno/Limbo but sadly it didn't happen.

Yes, not only it did not happen, most people aren't even aware of it as they keep praising Plan 9 instead.

In any case, Go is Limbo with a bit of Oberon-2 facelift, and as such a bit too late to the party.

At least they might finally support some level of generics and catch up with CLU.

Because plan 9 was developed naturally in the Lab as an evolution of Unix research.

Inferno on the other hand was a blunt force attempt by Lucent to leapfrog Sun by halting Plan 9 development for a whole year forcing the team to instead work on Inferno. It was a commercial project to produce a product which was in stark contrast to the more academic/research oriented development of Plan 9.

Unfortunately, this hamfisted attempt by Lucent left Inferno in a state of Limbo, pun intended. The target was more along the lines of embedded systems like set top boxes and early PDA's. The Dis VM also suffers from hard coded 32bit pointer magic which means it only builds on 32bit plan 9 or in a 32bit chroot under a unix-like for hosted mode. And finally, the Charon web browser has a bug that crashes the Dis VM. I have yet to see it boot on bare metal hardware in its entirety. These reasons are why Plan 9 gets all the love, it works out of the box on 386/amd64 and arm32/arm64 (Rpi, Zynq, etc)

Though not all is lost. Someone is working on getting it to build on 64bit 9front and OpenBSD, though the code is very much a WIP (if interested, hop into #cat-v on freenode and ask about the Inferno 64 bit port). It's not completely dead. Patches welcome :-)

Interesting background history, do you have some pointers to read more about such stuff regarding Inferno?

I believe that info came from a plan 9 user who interned at Bell Labs in the 00's. Though honestly you can get much better answers from the source by posting to the 9fans mailing list. Charles of Vita Nova, current owner of the Inferno code is a regular on that list as are many of the original Bell Labs folks.

Thanks

it's simple to write ONCE you understand and learn the idiomatic code.

some people call not having native string/int/whatever sorting methods is "hard to write".

some people think the verbose `if err != nil` every other line is also "hard to write"

again, there is an upstart cost, which is to integrate yourself into the language community.

Golang does have a few simple types sorting functions such as string and int https://golang.org/pkg/sort/#Strings. Now that generics will be out, could we even have generic sort functions ?

you cannot write a generic function that returns a modified slice without losing types. that, in my book, means hard to write.

...which makes it also very easy to read.

I don't see the point of cherry picking highly specific examples because for every argument there will be just as many counterarguments from other domains.

To be more specific: the point isn't whether Go is "always" simpler to write but whether it is generally simpler to write. I think the latter is true for all the domains I've written code in Go and I've solved some pretty hard problems in Go (check out my Github repositories if you don't believe me).

The awesome thing about programming languages is that you're free to pick another language if that is a better fit for any specific domain or even personal preference. Hence why I've worked in more than a dozen different programming languages over the years. So rather than moaning that Go doesn't fit a particular pattern where you need to rely on generics, perhaps use a language that has generics to solve that problem and save Go for the occasions you don't need generics (which, if we're all honest, isn't something we need to rely on half as much as people claim when moaning about the lack of features in Go).

As a veteran developer, what really annoys me the most is people who pick a language that isn't well suited for solving the problem at hand and then moan that language needs to change, rather than developers picking the right tools for the job. I'd rather see a language lack features but focuses to serves its core demographic well than see everything and the kitchen sink is thrown at it and everyone using it even when they know they shouldn't simply because they're too afraid to learn anything new. What we need is more appreciation that "general purpose languages" doesn't mean "should be used to do practically anything in". Then I'd think we'd all get along better.

I meant it as a random example. I do not dislike go. As I've stated below, I actually am learning it (more like, the conventions around it), just for fun.

I find it especially powerful for writing tools.

That doesn't remove my rights to nitpick its shortcomings though.

I've been writing Go full-time, professionally for around 4 years now. Backend software, mostly distributed stuff, tools and services - the bread and butter of what Go's designed to be good at. On the side, I occasionally write some Rust, Haskell, and other 'good' languages.

I have kept a counter of many times I've told myself, over the past years, 'I wish Go had generics, this would really make my life easier right now'. It's currently at 5.

In my experience, the supposed issue of a lack of generics is _extremely_ overblown with regards to real world use. Sure, it would be nice to have them. I would've really liked them to exist a month ago when I was writing a generic container. But they're not going to make the language that much better for me, and there's always going to be more things PL people lust after (usually the next candidate would be GADTs, “Go does not have algebraic data types!” coming to HN comments very soon).

As a counterpoint: I also write Go in this same space. I like Go - I find most of its design goals align closely with my personal preferences (avoidance of syntactic noise, fast compile times, right-sized standard library, sufficient control over memory without having to worry about memory safety).

If I kept a similar counter for the past 3 years, it would be at least five per day.

Every time I `return x, err` and it's not a true tuple - and it almost never is - I wish I was returning an `Either<X, error>`. That's constant.

Every time I use atomic.Value (often) or sync.Pool (less often) or sync.Map (almost never because I end up rolling my own stupid map+mutex).

90% of the time I want to say a pointer can't be null. 100% of the time I want to handle optional JSON or SQL fields.

Fairly often, like > 30% of the time, when wrapping serdes or DTO conversions around data streams.

I don't believe the level of generics required to support these use cases requires compromising the other goals of Go. The deficiency should have been obvious as soon as they introduced `sync.Map`.

>Every time I `return x, err` and it's not a true tuple - and it almost never is - I wish I was returning an `Either<X, error>`.

I can't imagine having this thought every single time. I don't want to sound harsh, but I don't know how else to ask this: can't you get over it?

Turning off my "how should I design this code well?" filter would probably remove the little satisfaction I still get from my day job. Coworkers and customers would likely not be too happy either.

But it's never "well I don't have Either available, I'll work with what I got"?

I don't understand how "I'll work with what I got" (which I do) is incompatible with wishing I had Either (which I also do).

It just sounds quite painful to me.

> there's always going to be more things PL people lust after

How about non-nullable types?

Sure, put that on the pile labeled “things that sometimes bother me, but I forget they're even an issue when I talk about Go with others”, next to generics.

I would argue that it only makes it hard to write type safe generic functions that return modified slices. If you're writing generic code for the sake of writing generic code, Go is probably going to give you a bad time, but if you're trying to solve real problems, you can get a very long way with slices, maps, and interfaces/functions.

filter/map/reduce are more productive than anything I could write without them.

I’m very skeptical. This kind of argument only makes sense if your programming is bottlenecked by your typing speed. It’s trivial to write these functions as for loops, the only difference being the number of key presses.

filter is obvious at a glance, where all loops look similar. Generating a wall of boilerplate is easy, the problem is that we can’t just ignore it and read a summary. Essentially I’d like to decompile Go to what could have been written in a powerful language.

Wall?

    var out []X
    for _, x := range elts {
        if condition(x) {
            out = append(out, x)
        }
    }

That’s so easy I typed it from my iPhone and anyone looking at it can infer at a glance that it’s filtering a list. If you are deeply worried about it, throw a comment at the top of the block.

I too like terse code, but it’s because it makes me feel smart, not because it’s easier to read or more maintainable. I’m having a blast writing Rust for my hobby project, making everything super DRY and free from boilerplate, but I don’t pretend that I’m saving myself time or making things more readable or maintainable should someone else come across it.

elts.filter(condition(x)) way more readable.

In my opinion the two are very comparable. If filter() is more readable, it’s not by much, and this is all micro optimization bike shedding. I’ve never had a hard time using the idioms in a given language, and things like map/filter vs for loops were never what pushed me away from or pulled me towards a language. The important things are almost always learning curve, tooling, ecosystem, performance, maintainability, etc and Go does very well in many of those respects. The actual in-language features are generally just gravy.

Note that the Python people have map/filter/reduce (and have had them for ages) and no one uses them. It’s either for loops or list comprehensions, and people notoriously struggle with the latter.

That's because in Python comprehensions have better ergonomics than lambdas. Scala has comprehensions too

  for { i <- 1 to 10; if i % 2 == 0 } yield i

but sometimes lambdas can be cleaner

  1 to 10 filter { _ % 2 == 0 }

The limitation to lambdas is just the single expression, but the same limitation exists for comprehensions. Comprehensions aren’t particularly readable beyond one loop and a condition or so (I say this begrudgingly as someone who likes to craft complex comprehensions). Beyond that for loops are encouraged, not filter() and friends, which suggests that they are perhaps not as amazing as some in this thread suggest.

Only if you know what a filter is and how the condition is parsed.

In more cases than one the condition is a lambda-monstrosity shoved in the filter function, which makes it even harder to parse.

In the situation, even for statement also become monster.

Not if you're not used to it. Literally had this over the past few months working with a junior programmer who had a really hard time understanding stacked map()s and filter()s but understood them easily when I unrolled them into nested for loops.

The junior programmer would have been much better off learning how a filter function works so they could be productive in almost every other language besides Go.

This was Javascript. And yes, I was teaching him how filter functions worked. But the point remains that if you're not used to them, map() and filter(), especially when stacked, are not that readable.

Then you can go ahead and use one of the many code generation libraries out there to handle it for you in a type-safe way.

Here are three options that were on the first page of google:

* https://github.com/kulshekhar/fungen

* https://github.com/awalterschulze/goderive

* https://github.com/cheekybits/genny

I think the word you're looking for is "tedious". Go is both simple and tedious to write. I'd actually argue it's tedious _because_ of its simplicity.

But all that boilerplate also makes it hard to read. You have to pick out the meaning amongst a bunch of noise.

Not once you're used to it. Humans are good at spotting patterns, and once you're used to the patterns of the boilerplate it becomes easy to read and you only notice the anomalies.

The famous "if err != nil {" boilerplate becomes expected after each call and you only notice if it changes.

Then you write 2 functions, what you're talking about is a different question.

if having to write a separate function for each type of container is easy for you, then I can only respectfully disagree :)

I'm saying this as someone who is learning go for fun.

Maybe. If you have to remember two functions to _understand_ the code, is reading really easier? I imagine reading implies understanding, and while i definitely think Go is easier to read without understanding, i don't think that's the real implication.

> Pike, I believe [...], claimed something to the effect that new grads with limited exposure to real-world codebases were able to understand existing projects written in Go more quickly than in other languages at Google. I have seen that message distilled down into "Go is simple to read."

Yeah, it was Pike, and I have also seen it distilled (in bad faith) into "Go is a primitive language for inexperienced programmers, so it's beneath me to touch it". And yes, it is easier to write and read compared to other languages (old and new), but it does have some concepts that you should follow to write "idiomatic" Go code, e.g. don't throw panics as liberally as you would throw exceptions in other languages, use composition and interfaces where you would use inheritance in other languages etc. But I'm afraid people who have been indoctrinated with disregarding Go as "simple", but want to try it nevertheless (or are forced to use it), won't take the time to get into these details, and will see their preconceived opinions confirmed...

> I have seen that message distilled down into "Go is simple to read."

I think the two are related, directly. However in my experience i don't even agree with Pike. Go is not easy to read. Yes, a single small function in Go is much easier to read (perhaps) than X lang. However Go requires a huge (brain)memory table to remember everything, because it spreads logic out. So you have to remember X function, scroll up, look at Y function remembering how it interacts with X, etcetc.

> Whether or not it is successful in that is another topic for another day.

I guess i bikeshedded, sorry :s

> Do people say that? I've never heard anyone claim that Go is simple to write.

The article we are discussing now has a big subtitle "A simple language."

Reply on news.ycombinator.com