Hacker News Reader

Comment by egeozcan | Hacker News Reader

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.

View on HN

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).

> 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.

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.

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.

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’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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com