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

81–90 of 110 posts

Re: Go Is a Shop-Built Jig

#81

Post by RHSeeger »

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

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.

Re: Go Is a Shop-Built Jig

#82

Post by bascule »

jhawk28 wrote: post #75
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

How does go not prevent data races? It has a race detector, channels, and atomics.

You can still send mutable state across channels, at which point it is shared and potentially racy. Race detectors only help you catch data races in the act (e.g. in production), they don't prevent them from happening in the first place.

Wikipedia has a nice description:

https://en.wikipedia.org/wiki/Go_(programming_language)#Race...

Re: Go Is a Shop-Built Jig

#83

Post by bascule »

zackbloom wrote: post #24
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.

I constantly see users of Go running into these problems. If you haven't, good for you I suppose.

Re: Go Is a Shop-Built Jig

#84

Post by mwcampbell »

pjmlp wrote: post #45
enneff wrote: post #39

Earlier quoted context omitted.

The rough shape the Go Java mapping has already been formed: https://godoc.org/code.google.com/p/go.mobile/cmd/gobind

Thanks for pointing this out. Even though I don't like some of Go's decisions, it would be nice to see it on Android. After all, I created the ticket request on Android Tools. But the feedback at Google IO from Android's team in this regard was disappointing.

Why do you want to see Go on Android? Yesterday, on the C++14 thread, you told me about why you gave up Turbo Pascal for C++ when you started programming for Windows 3.0 because you wanted to use a language officially supported by the OS vendor. If we apply that logic consistently, it seems to me that it would be best to just use Java on Android, unless you want to share code between platforms.

Re: Go Is a Shop-Built Jig

#85

Post by themartorana »

spion wrote: post #79
metafex wrote: post #70

Earlier quoted context omitted.

You get used to that pattern ;-) Also, the "I never need generics" made me smile. Sure, one can get by without them, but sometimes, as I said above, it would be really nice to have them.

Getting used to it is not the point. What I find cringe-worthy is that that's a bewildering amount of noise. It actually makes it harder to figure out what a specific piece of code does. Admittedly the error pattern is so common that I can imagine people getting very much used to it, but thats not the issue here. The problem is indicative of Go's lack of abstraction power, and its pervasive. There is no difference be…

Getting used to it is not the point. What I find cringe-worthy is that that's a bewildering amount of noise. It actually makes it harder to figure out what a specific piece of code does.

I find that so bizarre. That's on a personal level, I'm not throwing stones.

My two favorite languages before Go came along were Objective-C and Python. Different tools for different problem-sets of course, but Objective-C can quite easily be called insanely noisy.

Go is obtuse, but I find its readability on par with Python in that there's one way to do something, and that way is repeated over and over. I don't have to worry too much about stylistic preferences between programmers, people trying to get fancy while writing code (or trying to show off). Our server code serves thousands of requests per second - I need that code to be rock-solid, not fancy or overtly minimalistic.

You're right, people do get used to the error pattern. I can either handle it, ignore it, or toss it up the stack, and I get to make an explicit decision about that every time.

We've been rewriting critical systems code in Go (from mostly Python) and it's a joy. I am, of course, the (unintended) target audience for Go - a dynamic language dev looking for speed, concurrency, and compile-time safety, along with the simplistic beauty of gofmt, goimports, and so on. But I do find it beautifully simple, if not entirely "beautiful."

Edit: formatting.

Re: Go Is a Shop-Built Jig

#86

Post by chvid »

Am I the only one who is very confused by these examples?

A function named "frobulate" - what is frobulate? I dunno. The function calls: thingsToFrobulate, logit, cleanupOldest, processOld, doNewThing, cleanup and somehow FrobulatingMessage is set on the way.

Honestly; you can do the most clever functional programming in the world but if you naming is like this then your code is just going to be bananas.

And BTW: both Swift and Go are missing exceptions; I think those would be very helpful here.

Re: Go Is a Shop-Built Jig

#87

Post by polux »

mwcampbell wrote: post #78
spion wrote: post #63

Earlier quoted context omitted.

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.

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

Re: Go Is a Shop-Built Jig

#88

Post by pjmlp »

mwcampbell wrote: post #84
pjmlp wrote: post #45

Earlier quoted context omitted.

Thanks for pointing this out. Even though I don't like some of Go's decisions, it would be nice to see it on Android. After all, I created the ticket request on Android Tools. But the feedback at Google IO from Android's team in this regard was disappointing.

Why do you want to see Go on Android? Yesterday, on the C++14 thread, you told me about why you gave up Turbo Pascal for C++ when you started programming for Windows 3.0 because you wanted to use a language officially supported by the OS vendor. If we apply that logic consistently, it seems to me that it would be best to just use Java on Android, unless you want to share code between platforms.

I agree, but sharing code between platforms is what I do, as I want to target both Android and Windows Phone on my hobby coding. So the common language winner to both SDKs is C++.

The ticket was created back when I was still into Go and was wishing for first level support on Android.

Still I think it would be nice if it would be supported for those that like the language.

Re: Go Is a Shop-Built Jig

#89

Post by rsynnott »

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.

Well, you can if you MUST: https://bitbucket.org/minux/goios/wiki/Home

> Or your Swift to Linux.

I suspect that'll be a different story next year.

Re: Go Is a Shop-Built Jig

#90

Post by mwcampbell »

pjmlp wrote: post #88
mwcampbell wrote: post #84

Earlier quoted context omitted.

Why do you want to see Go on Android? Yesterday, on the C++14 thread, you told me about why you gave up Turbo Pascal for C++ when you started programming for Windows 3.0 because you wanted to use a language officially supported by the OS vendor. If we apply that logic consistently, it seems to me that it would be best to just use Java on Android, unless you want to share code between platforms.

I agree, but sharing code between platforms is what I do, as I want to target both Android and Windows Phone on my hobby coding. So the common language winner to both SDKs is C++. The ticket was created back when I was still into Go and was wishing for first level support on Android. Still I think it would be nice if it would be supported for those that like the language.

Have you looked at RemObjects Elements (http://www.remobjects.com/elements/)? With that (commercial) toolchain, you can write in either C# or Oxygene (an Object Pascal-derived language), and compile to .NET IL, JVM bytecode (and from there to Dex bytecode for Android), and even native code running atop the ObjC runtime for iOS and Mac.
Post reply on HN