Hacker News Reader

Comment by eapressoandcats | Hacker News Reader

I think that points 3 and 4 of that article are somewhat refuted by the popularity of Go.

You could argue that Go ultimately does give you a much control as possible but it certainly doesn’t do it like Lisp in the way that Paul Graham admires, and Go definitely doesn’t focus on brevity, beyond avoiding Java style magic incantations and boilerplate.

Interestingly Go is designed for “yourself and your friends” and they ended up in a very different place from the hackers that Paul Graham admires. It’s a language spawned from the pain points of large corporate software projects that wins a lot of sympathy from smart engineers that are working on large corporate software projects. The fact that it translates well to small projects as well is definitely an engineering feat.

View on HN

The single biggest factor in Go's popularity is that google is pushing it.

Then I'd say concurrency, native compilation, static linking...

The simplicity of its language constructs is IMHO one reason why Go is not more popular. The point seems moot anyway. Go is mostly used by experienced programmers, usually havong experience in other, richer languages.

Go is a language made for people doing systems programming who like static typing. Compared to popular alternatives like C# and Java, Go is a breath of fresh air.

Go was intended for systems programming, but is rarely used for that.

(Java and C# don't compete in that area at all)

Go is marketed as being designed for system programming. But all of its features seem to be designed for web services.

Go has a stupid definition of “system programming”. It uses it to mean “low-level network stuff”, and absolutely not as something where low-level languages would fit.

Don't bundle C# with Java in this area. It is way more low-level. Give it a try and it will surprise you :)

In what way is an objectively more verbose language than C# and Java a “breath of fresh air”? Especially one so badly designed with gotchas everywhere (defer being function scoped, they even got loop captures bad at first, when that was a well known problem 50(!) years ago, etc)

What exactly is "systems programming"? I thought that had to do with manipulating hardware? Usually Java and C# are more associated with application programming...

Not sure of any official definition, but it usually means that you're creating a system that applications made by other people will be built on top of. For example, writing Postgres or NodeJS is doing systems programming, writing a web backend atop those two isn't.

I was thinking of Go when I re-read that article. Unlike many here on HN, I am not a fan of Go because I find it far too opinionated and untrusting of its users. While technically it might have been written for Pike's and Thompson's friends, it does feel to me like a language designed to prevent poor programmers from making mistakes.

> it does feel to me like a language designed to prevent poor programmers from making mistakes.

That's Rust. I would not call _any_ language containing some kind of nil pointers to be " designed to prevent poor programmers from making mistakes". Go is mainly designed to be "easy to read" (and excels at that if you are used to C-style syntax).

Easy to read? That would be Python. I would say Go is designed to be fast to learn for experienced programmers.

Null pointers are a free runtime check for invalid assumptions. I don't understand the fuzz about them being bad at all.

I find python quite hard to read, honestly. The lack of typing in most python means that it isn’t immediately clear what a given piece of code does without diving into its implementation. You have to rely on docstrings (good luck) or descriptive naming.

The issue with null pointers is that they are, as you said, a stand-in for an invalid state. However, most null pointers don’t prevent you from trying to use the underlying data, which can, among other things, cause crashes (think not checking the return value of malloc). Additionally, it doesn’t make formal the litany of possible forms that a value can take — if you codify possible states, then you don’t always need to check everything. I’m currently working to port security firmware from C to Rust, and I’ve found I make fewer state checks, because the data I’m working with has bounded state — the data given cannot be in an invalid state.

Types really only help when they're primitives. You're going to have a million random classes that are only used in a few places. Seeing `ConfigManagerFactory config_manager_factory` doesn't help. What helps is avoiding excessive oop and making sure objects are printable for debug, imo something Javascript does a lot better.

Re null pointers, in Java or Python they raise an exception. Isn't that ok? It doesn't end up doing something invalid like in C.

Agreed. However, IMO Go's designers have good taste. That's hard to quantify but you know it when you see it and I see it in Go. Not so much in most other languages. Again, IMO.

Arguably, Go is the only language I couldn’t even infer the syntax for before learning it.

I can quite easily follow any ML, or C-like language, even if this is the first time I see it, and then go just writes some bullshit list of tokens, where you can’t even decipher which is a type or an identifier name. And then does some receiver syntax in function definitions that is absolutely unhinged.

I really dislike Golang, everything about it, even the name, and this is one reason. C C++ Rust can do systems stuff, Java JS Python and even C# can do applications. All with pretty intuitive syntax except for Rust kinda, but Rust has good reasons for that.

I don't get why Golang, ObjC, or Swift exist other than some company pushing them, and their guiding design principles are "be different to be different."

Go is popular, but so are Javascript and C++. I don't really know that you can draw any sort of conclusion from one language being popular.

> Go definitely doesn’t focus on brevity

It does, arguably to a fault.

* Single-letter variables

* Capitalization instead of private/public

Requiring explicit error handling instead of exceptions makes it not brief. Lots of things will fail, and every single time:

  f, err := Sqrt(-1)
  if err != nil {
      // handle error
  }

Probably async/await would make things briefer too, idk, haven't used Golang enough to tell.

Reply on news.ycombinator.com