Hacker News Reader

Comment by praptak | Hacker News Reader

The selling point of Go is readability, feature minimalism and code that might be boring to write but gets you readability in return. Putting a Lisp on top of that throws these away.

I'm not saying there's nothing left - channels, maybe the standard library. But putting a Lisp on top of Go feels like going strongly against the grain.

View on HN

But Go is not that readable. In fact across all languages I know I would factor go towards the bottom end of readability. Mostly because of it's insane error handling overhead. A lot of function bodies are like reading a book where every sentence is followed with 3 that have no meaning.

That's subjective. Readability is one of Go's goals. Whether they achieved it depends on your preference.

The fact that goland automatically collapses error handling blocks is solid evidence that enough developers find go's error handling blocks to be invasive.

I agree. My point is that you can't objectively define readibility, so it will always be a matter of preference. I've met my share of Go developers that think it is very readable. I personally can't stand it.

You don't understand 'readability' the same as the language creators. More text to read doesn't necessarily make a file or function less readable. Quite the opposite usually.

IntelliJ collapses the repeatedly occurring err != nil blocks with expandable placeholders in grey color to aid readability. Not the ultimate evidence but says something when a commercial product spends effort behind such features.

Not necessarily no. It's a balance. And Go skews so far that it's no longer reasonable. It's so bad that the most popular Go IDE by default removes the error handling code from view.

I don’t know, I understand most assembly line I see in isolation, yet often have no idea what the whole does. Sometimes too primitive primitives actually hinder readability/understanding.

I know many don’t feel that way, but functional stream manipulation is a very good example for that — I much rather deal with filter.map.reduce whatever, than 3 nested for loops with random breaks inside, even though the latter may be easier to reason about line-by-line

That’s a myth. Go read some random Go. Trivial functions often do nothing but call a couple of other functions, check errors and return. But non-trivial functions use relatively less lines for error handling.

> The selling point of Go is readability, feature minimalism and code that might be boring to write but gets you readability in return.

That is one selling point. Another is that it's a GC'd language that compiles to native on all major platforms, and is more popular than the alternatives, like OCaml, Haskell, D, Common Lisp. Just like Java was used as a platform on which to build languages, like Groovy, Scala, Clojure and Kotlin t otake only the most popular.

Besides the (subjective) advantages that you've mentioned, the selling points of Go include standalone binaries, fast compilation, a good standard library, and crucially, strong corporate support. A transpiled language could benefit from those.

Transpiling Python to Go would be neat and it turns out at least one project does just that (at least to prove the concept):

https://github.com/google/grumpy

I've been dinking around with generating Go from Lisp macros. For me the motivation is that infra teams in my company have been supporting Go but dropping the ball on Java/Scala, so I want to generate review-ready code for them while letting my experienced team work in some more complete language (maybe Java though that seems like a lot of work for a prototype).

Ecosystem, you forgot ecosystem. Go has lot of mature libraries. So new language will not have to create yet another library for HTTP server, JSON parsing, SSH connection, key-value DB, SQLite connection etc..

And network applications can be written without relying on async.

We have a litany of much bigger ecosystems than Go’s, that are much more friendly to guest languages, what advantage would targeting Go bring?

List a few, let's see:

JVM: 'bloated' or at least the perception of it. Now improving quite fast but also Oracle.

Dot net: still Microsoft.

C/C++: Not similarly high level languages

Scripting languages: lol slow.

Turns out Go ecosystem isn't that tiny at all. Yeah java is larger but also comes with a bad perception among other programming language users. So after Java, if you're targetting a general purpose audience, it's Go I think.

Never really understood this company-problem - if we squint hard enough, then perhaps .NET is really too Microsoft-centred (though improving rapidly in recent years), but Java has multiple, fully independent implementations and a specification. It is much much more open than Go in this regard, though again, I think it is often overblown of a problem.

Reply on news.ycombinator.com