Hacker News Reader

Comment by piazz | Hacker News Reader

I played around with Go a while ago, and while I appreciated the approach to concurrency, I was really put off by both the boilerplate + how primitive the type system felt. Not having map and filter due to lack of generics meant writing for loops all over the place just to filter and modify arrays. Appending elements to slices felt clumsy. The type system didn't feel expressive, and I often found myself having to resort to the empty interface escape hatch.

Compare this with Typescript (or Swift, or Rust), which have type systems capable of modeling nearly any problem domain. Go doesn't have algebraic data types (sum types) which are incredibly useful in my experience (Swift/Rust enums, Typescript discriminated unions). I'm honestly not sure why I would use Go over TS, unless performance was my primary consideration. It feels like Go was designing to be as inoffensive as possible to a legion of new-grad Google programmers, and you sacrifice most modern language niceties for it. Please convince me I'm wrong, because I really wanted to like Go.

View on HN

TS and Golang aren't comparable. I use both and I've never had a case where I needed to decide between the two. Golang is a high performance, modern language without the low-level or legacy headaches of comparably performant languages. Golang was written for an era where network communication and concurrency are commonly necessities and those use cases feel very natural. Typescript is JS (a conversation ending advantage in many cases) and so the concurrency model is amazing in some cases (e.g. when most of the work is async stuff like API calls) and pretty terrible in others (parallelizable computational work).

Golang was designed for getting shit done. If you are a big believer in OOP, then Golang feels underfeatured. But if you don't really care about OOP and you just want some of the advantages like basic inheritance, type safety, etc, Golang has everything you need to write performant, effective code quickly (there are use cases where that isn't true I'm sure, but, for me, Go's type system has been helpful and not a hinderance). There's nothing wrong with using the empty interface when you need to (any more than using any in TS, which you have to do in many applications).

I've found that Golang codebases are easy to pick up. I think everyone has some part of the Go style that they think is ugly (I 100% find append ugly), but for me this has mostly been inconsequential stuff - it has never gotten in the way of me solving business problems with high performance code. The tooling is the same (at least if you are using modules). It does its job well enough and then gets out of the way while you create business value.

I don't know your use case so this might not be relevant, but sometimes people will overuse for loops and slices when they might find it easier in Golang to pass around channels and use the pipeline pattern[1].

For me, Golang is like Python but with static typing and high performance. Fast to implement, easy to read, and focused on getting code out the door.

[1] https://blog.golang.org/pipelines

> Golang is like Python [...] Fast to implement, easy to read

I disagree. Python is often described as "executable pseudocode" - for example, to delete the `i`th element from a list `a` you use `del a[i]`.

In Go, it's much more convoluted: `a = append(a[:i], a[i+1:]...)`. Plus, without generics, you can't even easily hide that inside a function! There's a whole page of these "tricks" that are necessary to perform basic operations on slices: https://github.com/golang/go/wiki/SliceTricks

Interesting. I didn’t know you could do that in python with a list.

It would be trivial for Go to support the delete keyword on slices (mapping to the statement you noted), but I think it would be a bad idea. Sometimes you want an operation to be awkward intentionally because it’s fundamentally costly. Hiding that cost by making everything look the same doesn’t always help the programmer. Languages should be powerful, but there should be an intuitive relationship between the code the computational complexity (not exact, but intuitive).

I’m sure there are counter examples, but I think Go generally does a good job at this. Plain loops are standard, make, append, new, delete, etc. have obvious costs. Error handling is explicit.

> `a = append(a[:i], a[i+1:]...)`

Not only is this ugly and unintuitive (“what function do I call to delete an element?”; “append”), according to the linked page it can also cause a memory leak?!

On the other hand, it's very clear about what's actually happening when you delete an element of an array.

I'm not a C guy, but I figure doing this in C would involve several lines of mmemove, with loads of error checking[1]. So the Go version is about as ergonomic as you can get without obscuring what's going on.

[1] - I guess you'd do something like: memmove(a+i+1, a+i, sizeof(element) * (a->len - i)) with a whole load of checks to make sure everything's in order. I think C has the advantage of being utterly explicit about what is actually happening, but I think a higher level thing like append() is kind of nice when you don't want to think hard about, say, inserting an element in the middle of an array.

Yeah, Python is much much more readable than Go. I feel like performance focused languages are always less readable because the language needs to give you more control and I think Golang lets you work at a pretty high level of abstraction while still having plenty of control on performance. Once you know Go, it's pretty easy to read someone else's code, which I think is really nice. But "easy to read" might have been a little bit of a stretch.

IMO Go's biggest issue is its lack of the functional features which have trickled into most languages (although arguably without generics, this is impossible to implement).

I dont particularly want Haskell with semi colons and braces, but a functional style definitely has its place.

Just like Go has a subset of the traditional object oriented style, i think there is a place for a subset of functional.

What do you miss? All I've ever really needed is the ability to pass around functions as first class primitives which Golang has.

I always cringe when people proclaim that they need to "get shit done". It often pays to be mindful of what is getting done as a result.

I think some people feel productive when they write out a big loop, but to me it’s wasted effort. I want to write

  col.filter(_.isReady).map(convertToX).any(_.color == BLUE)

and generate whatever fused loops make that work. I don’t want to write and review loop boilerplate by hand for the same reason that I don’t want to customize the stack frame layout when I call a function.

I've never found it much more painful to write:

  for i, c in range col {
    if c.isReady && convertToX(c).color == "BLUE":
      return True
  }

(which is not to say I don't miss the map/filter syntax - although I don't miss the bugs related to lazy execution in stuff like LINQ or Spark)

That’s actually pretty good. Most people would use three more lines to create a temporary and break after setting it, and three to nine more depending on how many steps require idiomatic Go error handling.

Would most people actually do that? That example seems like pretty idiomatic Go. I imagine junior developers would write that.

I would typically expect

  anyBlue := false
  for _, c in range col {
          ready, err := c.IsReady()
          if err != nil {
                  return nil, fmt.Errorf("isReady failed: %v", err)
          }
          if !ready {
                  continue
          }
          x, err := ConvertToX(c)
          if err != nil {
                  return nil, fmt.Errorf("convertToX failed: %v", err)
          }
          color, err := x.GetColor()
          if err != nil {
                  return nil, fmt.Errorf("getColor failed: %v", err)
          }
          if color == BLUE {
                  anyBlue = true
                  break
          }
  }

which badly obscures what’s going on but demands no cleverness at all (except that some might forget the “break” and still get the right answer).

If IsReady, ConvertToX, and GetColor can return errors then this isn't that far off. But then you're not making an apples to apples comparison. You would have to extend your functional example so that it also handles errors. Unless it already does, and I am missing something.

What I wrote should be pretty close to valid Scala, which handles exceptions. I can imagine wanting to skip an isReady failure, which looks like

  col.filter(c => Try(c.isReady).getOrElse(false))
  .map(convertToX).any(_.color == BLUE)

I see. Then in part the comparison is showing off exception handling, not FP.

Rust is a good example of functional lang without exceptions (panics aside).

In Rust there are many cases where I could use FP but opt not to because it can make error handling more awkward. For example to collect the result of a map operation to a vector, and if there is an error along the way you want to abort the entire operation. In functional this means collecting to a Result<Vec<T>>. Not sure if I'm just tired today but I can think of how to do it in 5 seconds with a loop. I suspect functional solution would be uglier.

Rust’s collect will do this for you. It’s even an example in the documentation.

Thanks! I learned something new.:)

https://doc.rust-lang.org/stable/rust-by-example/error/iter_...

This is easy to miss if you are mainly reading reference docs. I probably read the getting started guide at a time before there was a section on it.

My other comment in this thread comes to mind https://news.ycombinator.com/item?id=24300057

I was thinking of the final example in https://doc.rust-lang.org/stable/std/iter/trait.Iterator.htm... , glad we have it in both places!

I don’t personally really agree with what you’ve said, but that’s fine. Different people perceive things differently.

No problems. There are enough dimensions involved in what makes a language good that Im pretty sure I could rationalize why any language is better than another, measured along only one of them.

Robustness. Speed. Simplicity. Easiness. Conciseness. Writability. Readability.

Hard to tell which are independent vs correlated, let alone how they factor into productivity. And productivity is also a function of the kind of problem you work on.

It really doesn't matter day to day once you're in the loop (cough). I agree, it's an ugly language on the face of it, but you get over that quickly. You come to appreciate the language as a whole.

A bigger concern when I started out with Go was the imports/lack of versioning, and at the time the lack of official package manager.

This style makes developer forget the underlying costs though. It feels productive but it is harder to understand what work computer will do. Go is designed to be imperative, so is a complementary language.

That's true and we should embrace it. Higher-level languages should empower us. We should use profilers to measure actual bottlenecks when necessary, not make every potential bottleneck more painful to write and read forever.

You can get a ton done in Typescript or Python or Ruby. And in addition to type systems being developed to assure type safety in the most dynamic of languages, you also can write tests and draw on the community knowledge of countless programmers who know your language. Obviously if performance & certain performance first libraries are first priority for you, choose a very computationally efficient lang. But it’s a toothless argument in 2020 to say when following best practices you are inevitably going to write flawed, incorrect code because you’re starting in a dynamic language.

I'm also majorly turned off by this attitude. We're knowledge workers - ostensibly paid nice salaries to think deeply and find reasonable solutions to hard problems, not just to turn a crank and shit out code as fast as possible. Sure, this is not your job 24/7, and there will always be boring code to write, but still, have some pride in your craft, you know?

The point of code is readability and runtime, not ego-stroking. Fast compile times are a bonus!

Are you suggesting that Golang leads to to poor quality software? That hasn't been my experience.

No, I specifically quote words from the comment to which I'm replying.

The problem is language-independent, but is more pronounced among adepts of "practical" languages and tools.

Maybe you are not really taking full advantage of the powerful type system in typescript if you don’t see any lacks in go type system and if you think that using ‘any’ or the empty interface is perfectly normal?

>Golang was designed for getting shit done

That's indeed a good way to explain the utility driven nature of Go. I've been predominantly using OOP languages before and Go's deliberate lack of OOP features was although uncomfortable at first, the advantages of getting things done fast far outweighed it later when I released production applications with it.

>For me, Golang is like Python but with static typing and high performance. Fast to implement, easy to read, and focused on getting code out the door.

I was tired of adding disclaimer when teaching Python, that when you want to extract performance out of it you should also learn 'C/C++'. Go serves as a perfect replacement to Python where performance is a necessity, I don't see where that would be false in a production environment where 'code performance == capital efficiency'.

I share much of the sentiment. I like the simplicity of Go, but I think they took it too far an ended up with something too dumbed down and lacking in abstractions and expressive power. It feels like a step backwards coming from other contemporary and popular languages like JS/TS, Python, Kotlin, C#.

I agree with this, but I suspect I disagree on the extent to which this is a problem. These things are minor annoyances in my opinion compared to concerns that are largely apart from the actual language itself, such as performance, ecosystem, tooling, deployment story, learning curve, etc.

With respect to Python and JS, you can always drop down to `interface{}` for similar expressive power and type safety, but generally people don't do this for the sake of simple for-loop boilerplate.

Here are some serious pitfalls with Python (it's the language I know best) that dwarf concerns about language features. JS, Kotlin, and C# share some of these problems. Go doesn't really share any of these problems; it competes well with JVM and .Net with respect to performance, and its tooling story is simply top-notch on the whole (of course, there are individual tool categories where other languages have better offerings).

* Python is a super slow language and the proverbial advice "just rewrite the hotpath [with multiprocessing / with C / with Pandas / etc]" falls over for any bottleneck that involves processing a large object graph. In these cases, you can't use multiprocessing because the de/serialization and IPC costs will typically exceed any parallelism gains. You can't use Pandas because the data set isn't matrix-shaped, and even if you can shoehorn it into a dataframe, you'll end up calling back and forth between Python and Pandas/C so much that you'll lose anything you gain from Pandas (and have much harder to maintain code). Similarly with "rewrite it in C/Rust/etc", you'll have to basically rewrite the whole object graph (including all of the inherent classes and methods) into C/Rust/etc and you probably don't want to keep those in sync with the original Python classes, so congratulations, a huge amount of your code is now in C/Rust/etc and you're no longer enjoying any of the benefits you would enjoy with Python (probably iteration velocity). Sadly, performance isn't likely to get better in Python because the community is so heavily invested in C-extensions (because Python is so slow) and the C-extension interface is basically the whole CPython interpreter, such that anything that wants to play in the ecosystem has to be very CPython shaped including many mechanisms that are prohibitively difficult to optimize around. Pypy is making a lot of interesting progress, but compatibility is still a blocker for lots of applications (e.g., anything that wants to talk to a Postgres database--unsupported packages notwithstanding). Python is fine if all you're doing is shelling out to a database or a C library, but anything more becomes expensive quickly ("well how come $BIGCOMPANY is so successful despite using Python?!": probably deep pockets).

* When you want to distribute a Python program (e.g,. an internal tool), your options are pretty limited--the executable zip file formats (e.g., PEX files) are pretty nice, but inevitably something depends on an .so file (because Python utterly depends on C for just about everything) that doesn't get included in the zip file. Even in the happy path, you have to have the right version of a Python interpreter installed on the target system.

* Correctness is the least of problems with untyped Python or JS, rather the biggest problem is the lack of quality documentation (critical information is typically either missing or outdated). The second biggest problem is that there aren't rails to guide mediocre developers toward sane code--developers tend to not know how to "think in types" and the code is typically far more complex than equivalent typed languages as a consequence.

* Python nominally has a static type checker, but it's still very immature (still can't model JSON or even callbacks with keyword arguments). Further, getting it to find the type stubs for a given package is an exercise in frustration and terrible error messages. The only hope is that the Python community seems to be leaning into type annotations, so that should drive improvements in tooling in time (how long? is a different question)

* Tests are super slow, largely because Python is super slow. CI bills can get to be really expensive. Not a big deal for well-endowed companies, but this is really hard for companies with meager budgets (this is ultimately true for Python generally IMO, not just WRT CI bills).

* Documentation generation is brutal. Developers have to document types and keep them up to date. Consequently documented types are never up to date and many libraries--even the most popular--just punt on documenting types altogether. Then you have to write and maintain your own CI jobs for building and publishing documentation packages. And the documentation is still really reader-hostile on account of the everything-on-one-page, nested-with-no-context structure (e.g., SQLAlchemy has lots of methods and even classes with the same names but minor variances in module path and the only way to tell what you're looking at is to gradually scroll up to the previous `class Foo:` block and then back down to the thing you're looking at. Good luck ctrl+f-ing around). The latter problem would be easily remedied within Sphinx. The typing problem will get better as the typing story improves, but it's improving at only a snail's pace (mypy is still prohibitively difficult and restrictive for many projects). Further, if someone wanted to build a godoc.org clone for Python that automatically discovered, built, and published Python packages, I don't know if it would be possible because Python doesn't have a standard repository structure.

* Then there's a long tail of paper cuts. Black (Python formatter) is a welcome relief but it's also really slow. No decent editor plugins (dynamic typing) and PyCharm is relatively expensive and there's still constant friction between it and your preferred editor even after you've learned it. Python has no dead-code elimination so artifacts are frequently enormous--like "too big to fit into a lambda, better use an ECS task and good luck with those startup times" big. Etc etc.

> its tooling story is simply top-notch on the whole (of course, there are individual tool categories where other languages have better offerings).

Personally feel like rust is better overall, but I don't know if you've tried it

I have, and I generally agree. Rust’s tooling is fantastic. Compiler needs a speed up, but impressive work all around. Would like to be able to use it more often.

Python also actively hates functional programming and certain other language features that it "has", plus its standard library is extensive but also all over the place.

I still find the Typescript compilation time to be annoying. I rediscovered using Typescript for backend development on NodeJs and was very unpleasantly surprised by the compilation time (my only complaint).

For a project with 20-30 files and around 8 dependencies, it took 10-20 seconds to compile and 4Gb of RAM (yes I checked with tsc --listFiles that no other files were parsed).

The same in Go to compile to native would probably take <5s in my experience!

> or a project with 20-30 files and around 8 dependencies, it took 10-20 seconds to compile

Something is very wrong here. If you use `tsc -w`, you should get incremental compilation. Small changes should compile almost instantly.

For me, even without using `-w` on pretty large projects, my compile time is never more than 5s.

I have to wonder if you have bottlenecks elsewhere.

Regardless, TypeScript's type system is much, much more expressive than Go's, so compile time will theoretically be slower. For me, it's worth it because compile time is an inexpensive way to save lots of maintenance time in the future.

(Note that I would never use TypeScript and Go for the same type of project, but that's my mindset in theory.)

That's a fair complaint, but I find that during development, I use `tsc --watch`, which makes incremental compilation very fast.

Of course, that doesn't affect the slow production build time, but I care a lot less about that (since it usually happens off in CI land somewhere and I'm not sitting waiting for it to happen.

So ultimately, this is a non-issue for me.

Super agree. Speedy compilation time of Go was my favorite feature. TS compilation is frustratingly heavy.

TypeScript has way more advanced type system so there is a price you pay for that.

IIUC, this is specifically a problem with the TS build system/runtime, not because it’s typed. Deno is attempting to solve that.

the key is simplicity, you're complaining about language features that allow you to write "fun" code, but remember that we spend around 80% of the time reading or debugging code, the main focus of Go is about writing code that's easy to read which will allow you to scale a project or source code with more people, also remember that easy doesn't mean simple, I think these 2 talks will make you understand my idea a little bit better:

https://www.youtube.com/watch?v=rFejpH_tAHM

https://www.youtube.com/watch?v=2y0pmRJNkLA

map/filter and sum types are not about "fun", they're about correctness and expressiveness.

map/filter and their equivalent loops are both perfectly readable, but the latter involves more boilerplate.

And I'd disagree. Numerous engineers of differing skill levels (what I deal with day to day), struggle significantly when map/filter are added into the mix. And we may say "get better engineers", but we don't have that ability. We have to write code that is maintainable for the engineers we have and can get (and the ones coming in the future).

Come on, map and filter difficult? That's hyperbole of the highest order.

Not really. They require a basic understanding of higher order functions and often heavily use closures. Those moderately advanced concepts. It’s also sometimes harder to write efficiently to avoid multiple iterations over the same collection. I think many many people are way more comfortable with loops than people are with map/filter.

I'd settle for comprehensions. It already has generic for/range so why not. That would cover a lot of boilerplate annoyances.

Correctness isn't about fun, although fun is definitely a side effect. I agree Go is easier to read if you're primarily familiar with C style imperative programming, but once you've strayed from that a bit, a PR in Typescript is no more difficult to review than one in Go. The big benefit of languages with more expressive type systems is the confidence you get that your code will work as expected if it compiles - I felt this in Swift more than in TS, and very little in Go.

I love go but the OP is completely right. Lack of basic collection functions is incredibly aggravating and slows down productivity substantially. At least it's not as bad as Java.

I'm not sure how you can have that opinion of Java when Go is basically Java pre-generics. Especially in the context of collection functions. Java's stream API is simply amazing.

Yeah sorry, the Java collections API is pretty great. I meant in terms of raw boilerplate the language requires you to type to get anything done. This is definitely improving, and you can use things like Project Lombok to generate a lot of it.

Java's photocopy of .NET's Linq in the form of "Streams" is usable.

> the key is simplicity

Simplicity (in language features) can lead to complexity (in code) that is hard to maintain.

I share a lot of these opinions. The language and especially its type system feel like toys when comparing it to TS. I still really enjoy working with it for the right projects, which tend to be very straightforward little servers that need to do one or a couple things very well.

For me, when the task is right, “limiting” becomes “straightforward and uncomplicated” and the things it does well really shine. The language and its type system encourage a simplicity of thought that I find refreshing when compared to the power and complexity of modern languages. I also can’t say enough for the joy of deploying Go binaries over TypeScript projects.

Even so, I’m waiting for generics before I use it for anything really significant. As is right now, I could see myself becoming frustrated with the Zen of Go if I had to use it every day. Just give me map, damn it!

I would be embarrassed to admit the amount of times I have discovered this in my Python code

  for foo in ...
    if i in foo:

creating something of quadratic complexity!

Yes, I would rather take the explicitly verbose Go code

To be clear: If foo is a dict, we have one loop. If foo is a list, we have two loops. If accidentally happens to be a string, even then it is nested loops

This seems like a misunderstanding of quadratic complexity. If every i in every foo is checked/operated upon once, that's still linear, no matter if the nesting structure requires nesting flow control.

Isn't this just an issue of having types, versus not?

Although I do remember trying racket, where they solved the same problem by naming functions dict-remove set-remove hash-remove vector-drop etc, which does the job but never have I been more offended thinking I was going in for its abstraction capabilities

Complicated languages come with an explosion in number of ways to do things.

Rust is great but I waste a lot of cycles thinking about how to structure the code instead of the actual problem. What is cleaner here using a loop or a higher order function? Should I use if let to make the code a little shorter? Should I use that question mark trick to propagate the error? Do I use the expression or statement form of ifs?

Do all of the features in your language really make you more productive, or are the gains offset by the cognitive burden of dealing with them? And what is the cost of having many ways to do things in the context of a code review? What about when reading other people's code? What about when writing automatic tooling?

I get the feeling that Go programmers came from some other imperative language and got burned by some OO features. I feel kind of bad for them. I hope they never discover modern functional features or they will realize how much of their life was wasted writing pointless boilerplate.

And I feel bad for those who pontificate over the lack of features for a language that’s easy to use, has a simple build system and allows for solving many classes of problems very easily.

Golang is popular for a reason. It is popular even among programmers that enjoy using other languages. No need to feel bad for programmers who are happily building things.

What you feel about what you don't understand, isn't really important to anyone else though.

Go provides less is more as a feature, but would be invisible unless the dev cared about seeking simplicity and performance.

Go is not simple (conceptually) by any strecth of imagination. Golang has pointers bolted on as if they are a real thing. Like, what's the point of exposing pointers without the pointer arithmetic when modern languages have come up with simpler ways to think about accessing memory? So, as a Go developer are you supposed to understand pointers or not? Similarly with Go routines, people boast about them as if they are a silver bullet for concurrent programming. But then, you also have and need to use sync primitives like mutexes sometimes. So, you still need to understand accessing shared mutable state and it's challenges well to use Go which is the actually complex part of concurrent programming. So, I don't know what people mean when they say Golang is simpler. I find it an ugly, weird and a hyped up language. The languages I consider simple are C and Python. C is simple because it's a small language and Python because it truly abstracts away the low level details. Golang is an opinionated (an quite an unimpressive) language with pros and cons like any other language. Currently, with more cons than pros, IMHO.

Go spec is quite short and understandable. The implementation handle quite alot for you, which is not simple, but makes many applications easy to write. Code is fast to write and easy to read. Golang really has 2 types of references, not pointers. I find C and Python slow and tedious to use, and would rather not share memory if I can avoid it, including using pointers (use map instead). It depends what one wants from a language, where golang fills a nice untraditional niche where experience and newcomers can meet. I find Go optimizes more concerns than any other language, which in turn makes it an opinionated balance of several dimensions.

The time spent writing boilerplate is completely negligible to the amount of time spent finding the "perfect" combination of language features to express your problem. I write production ready code in Go way faster than in any other language I've used.

You'll be happy with the latest developments: https://blog.golang.org/generics-next-step

No need to convince. If you've got something working nicely why would e.g. I spend my energy to convince you otherwise.

Go is designed to be performant by default, so expensive operations will stick out in code. It is high level, but also like a "better C".

a quick grep on my project and I'm counting 779 functions. the empty interface appears in 12 of the 779 function signatures. If you find yourself constantly using the empty interface it's because you don't know the language, not because it's necessary.

This sort of comment is not really relevant to the article that was posted, which is not about Go's type system, or convincing TypeScript users to switch to Go. I'm sorry that you don't like Go's types, but I'm going to guess it's not really targeted at your needs if you are a TS user.

It's okay not to use Go for your projects. But there's no need to drop your personal opinion of a language into a post about specific case studies of how that language is used inside a company.