Hacker News Reader

Hacker News

Comment by lukasm | Hacker News Reader

Full thread

lukasm

I would switch from python to Go but

- Type system needs to be improved e.g. generic code

- Verbosity, duplication of code are painful

- Lack of functional features

- Tooling

- Maturity

View on HN

I've spent a solid amount of time with both Python and Go, and I encourage you to make the jump. Services I write in Go are just much simpler and easier to maintain than in Python (or Javascript).

I haven't had an issue with code duplication at all. If you do, you might just not have gotten deep enough into how interfaces work yet.

When you use the standard library it's clear it was designed by people who have been programming computers since the Plan 9 days, I consider it much more mature than Python's equivalents.

In terms of tooling, having go fmt run on every save is wonderful, your code is always and instantly formatted perfectly. Beyond that, I haven't needed much.

Tooling? I am not sure about that one. Go tooling is pretty nice. The one area lacking a bit is, for want of a better word, "package management". However, I have been using gpm with success, and others are happy with godep.

For me, the biggest pain point is, to be honest, dealing with json. json in Go is not as fast as you would expect, due to the overhead of runtime reflection. Parsing "loose/dirty" json is also painful. If you cant be sure ahead of time if a value is `"1"` or `1` (int or string of int), and have to support both, you are going to have a bad time.

    > If you cant be sure ahead of time if a value is `"1"` or 
    > `1` (int or string of int)

...then your data provider is _broken_ and you need to take it up with them :)

Well, these are B2B customers, who are huge companies. We have actually had customers say they can't even find which servers are running the code, so could we "pretty please with money on top" just make it work anyway....

Sometimes you actually have to deal with what you get, and can't just "fix the other end".

To be fair, a favorite tagline of the Go community is "it solves real problems". Dirty JSON (with no simple way to fix it) is a real problem.

It might be a bit more painful, but it is totally doable. You could parse that field into a generic interface, and check the type in your code, or you could create an interface which requires an `AsInt` method, and implement it for both options.

I personally struggled with the json parsing issue a fair bit, but persevering resulted in me having a mostly static typed setup which has ended up being much better than when I've used JS or Python.

Yeah. It is indeed possible, just painful. I am thinking of wrapping json or even go-simplejson to add support for attempting to coerce strings to ints, where the target is an int and you happen to get a string(int) via json. Haven't gotten around to it yet though.

Hang on - you are coming from Python and complaining about the lack of generics?

Why? Go types (without generics) are much stronger than in Python aren't they?

No, they make the language weaker. For example, its impossible to write the `map` function in Go because of type restrictions.

In python, every function is as generic as it can be.

You can write map but it's a lot of boilerplate and you loose types

Map func(interface{}, func(interface{}) interface{}) []interface{}

You also loose the ability to pass existing functions with your implementation of Map

  Map([]string{"a", "b", "c", "d"}, ToUpper)

That isn't the case at all. The problem is that the types restrict your functions, so you either have to write a Mao function for every type you want to support, or drop the types altogether.

The situation where you drop the types is the equivalent to Python isn't it?

Its not because in Go you cannot reuse existing functions that you've written if you drop the types. In python, you can.

So, you don't write the map function in Go; you use a plain for loop. Again, Go only focuses on solving real problems, and does so in a mostly imperative style.

Map is solving the real problem of code duplication for the scenario "create a new list whose elements are the elements of the original list to which f was applied". Not only does it reduce boilerplate but when you read map(f, list) you know that the result is gonna be a new list of the same size, that if f = id you're gonna get the same list, etc. In other words, map has invariants. It captures a tiny subset of all the for loops you can write.

Saying "we don't need map, we have for", is akin to saying "we don't need toUpper, we have for loops" or "we don't need functions, we have goto".

- Designers of the language forced their where-braces-go religion on everyone by building it into the language.

For me, that means every time I attempt to write code in Go my nose is rubbed in the "this language was built by assholes who have no respect for you".

Oh really? I can see that I suppose, but I always found it kind of nice that they enforce a very specific style. It makes it so that all Go code I see is consistent and clear. Same with the way they do documentation.

I guess it does take some of the aesthetic or artistic quality out of it, but in practice it's never bothered me. On the contrary, not having the option removes quite a bit of mental overhead on what (to me) comes down to a fairly religious but ultimately inconsequential viewpoint.

Are you being ironic? I guess it wouldn't overly bother the OP, considering he's switching from python, where "the designers of the language forced their mind-your-indentation religion on everyone blah blah blah".

The indent-backwards programmers must have felt very offended by that. :)

Reply on news.ycombinator.com