Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Is a Shop-Built Jig

robnapier.net

Post reply on HN
Print view View original

21–30 of 110 posts

Re: Go Is a Shop-Built Jig

#21

Post by stock_toaster »

lukasm wrote: post #14

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

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.

Re: Go Is a Shop-Built Jig

#22

Post by sagichmal »

stock_toaster wrote: post #21
lukasm wrote: post #14

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

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 pai…

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

Re: Go Is a Shop-Built Jig

#23

Post by stock_toaster »

sagichmal wrote: post #22
stock_toaster wrote: post #21

Earlier quoted context omitted.

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 pai…

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

Re: Go Is a Shop-Built Jig

#24

Post by zackbloom »

bascule wrote: post #20

"Go feels under-engineered because it only solves real problems" This belies a multitude of real problems Go doesn't solve, like generics or preventing data races

As he said in the article, neither seem to be problems which come up in practice. I maintain about twelve Go services running in production, and neither failure has cost me any significant amount of time.

Re: Go Is a Shop-Built Jig

#25

Post by zackbloom »

stock_toaster wrote: post #21
lukasm wrote: post #14

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

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 pai…

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.

Re: Go Is a Shop-Built Jig

#26

Post by zackbloom »

lukasm wrote: post #14

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

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.

Re: Go Is a Shop-Built Jig

#27

Post by zackbloom »

dkarapetyan wrote: post #19

Notice the author would still rather use Swift when he's doing fun stuff. I get this sentiment and more than once I've wished there were more constraints in the language to mitigate the damage some kid with a chip on their shoulder could do but it says something about the psychology of programmers, "I know personally I'm good enough to do magical, wizardly stuff with all the cool stuff that Swift gives me but you, we…

So you're saying you want programming to be hard because that means you get to work with smarter people? I think what Go is striving for is simplicity, not elegance. And that change makes the code easier to write and maintain for everybody involved. At 10AM I might feel like writing Swift, but at 3AM I'm sure as hell glad I used Go.

Or, less anecdotally, I maintain about twelve services in Go, including web services, proxies, and an analytics engine, and I have never been woken up in the middle of the night with a failure. That was certainly not true when I was writing Python or Javascript. Erlang or Swift might offer comparable reliability, but it comes at the cost of a lot of complexity.

Re: Go Is a Shop-Built Jig

#28

Post by mentat »

sat wrote: post #2

Seriously, in good faith, I attempted to learn and write a simple web application in go. I found it hard coming from a world where IDE support was available in other languages that do autocompletion and things like that and development just moves faster. In go, there is some level of support in sublime text, go for vim etc, but it is not nearly as full featured as say, IntelliJ. Want to learn about the javadoc - Comm…

Have you looked at this? http://howistart.org/posts/go/1

Re: Go Is a Shop-Built Jig

#29

Post by zackbloom »

threeseed wrote: post #5

What is with Go supporters ? I don't understand why if I don't use Go then I am not solving real world problems and instead building over engineered monstrosities. Working in the enterprise features like exceptions and generics makes it easier to ensure consistency across the platform and our 20+ developers.

I can give you insight into my perspective. Go has made programming better. It is genuinely easier to build reliable things in Go than in Java or C or Python (from my experience). I didn't know that, until I invested a good amount of time building things with it, souly because everyone seemed so enthusiastic.

It's fine to say for economic or organizational reasons you're not moving to Go, but don't say it's because you need exceptions or generics unless you've spent a serious amount of time trying it the other way.

Re: Go Is a Shop-Built Jig

#30

Post by wutbrodo »

tagrun wrote: post #16
fineline wrote: post #12

But you can't deploy your Go to iOS. Or your Swift to Linux. I'm getting interested in Nimrod (or Nim as I think it's planning to become). Compiles to native binaries via C, C++ or ObjectiveC. Even compiles to JavaScript. So it will run on all consumer and server platforms, on microcontrollers and in browser. And it has generics, exceptions, macros, inheritance, and (optional, time-boxed) garbage-collection. It's a t…

> But you can't deploy your Go to iOS. And? iOS and Android supports are on their way in case you're not following recent developments. In case you're interested in writing programs for mobile devices, there's already a supporting go.mobile repository with (mainly targeting Android at the moment). > And it has generics, exceptions, macros, inheritance, and (optional, time-boxed) garbage-collection. Sigh... this "wher…

>> It's a tiny community

> in total contrast with... Nimrod community?

He _was_ referring to the Nimrod community here.

Post reply on HN