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

91–100 of 110 posts

Re: Go Is a Shop-Built Jig

#91

Post by yohanatan »

themartorana wrote: post #85
spion wrote: post #79

Earlier quoted context omitted.

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…

The difference though is that Python is powerful enough to avoid the repetitive noise even if use of that power isn't the 'Python way'.

Re: Go Is a Shop-Built Jig

#92

Post by pjmlp »

mwcampbell wrote: post #90
pjmlp wrote: post #88

Earlier quoted context omitted.

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.

I know then from the time they used to collaborate with Embarcadero. Although I left Turbo Pascal/Delphi when Windows 3.x was still actual, I kept on following Borland.

What I am doing are very basic hobby projects, when private life allows for, which is seldom the case nowadays. You can check some of them with my nick at GitHub.

If I would be doing a commercial app, I would be buying either Qt or Xamarin, mainly because they are better known and using Pascal like languages (except maybe Ada) is no longer relevant on my CV.

Re: Go Is a Shop-Built Jig

#93

Post by bascule »

enneff wrote: post #38
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

Generics are not a problem to be solved, they're a tool to solve problems.

The lack of generics is definitely a problem. You can't write generic code, and end up having to write your own thunks for each type you want to use. The standard library can't expose generic facilities that work on any type.

This should be evidenced by the fact that Go is the only mainstream statically typed language without parametric polymorphism. Worse, trying to bolt it on after the fact has generally lead to ugly solutions, like C++ templates or Java's generics.

I expect Go will eventually follow Java's lead and bolt on generics awkwardly.

Re: Go Is a Shop-Built Jig

#94

Post by stock_toaster »

zackbloom wrote: post #25
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…

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

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.

Re: Go Is a Shop-Built Jig

#95

Post by sat »

campoy wrote: post #4
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…

"What we really want is a flattened struct" That's what we call struct embedding. Check this http://talks.golang.org/2014/go4java.slide#33 for more details.

Embedding won't give you a flattened structure with transparency you expect. In other words struct B embedded in struct A will only create a syntactic sugar so that you can access properties of B through A. It won't work in other cases .Check this out - http://stackoverflow.com/questions/24333494/golang-reflectio...

This is not to say inheritance is better. I am just illustrating how reuse is harder with go because it expects a lot more code to do a simple thing.

Re: Go Is a Shop-Built Jig

#96

Post by sat »

kasey_junk wrote: post #8
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…

That's funny, because I'm also a Go skeptic but your 2 points are literally exactly the opposite of mine. On the top 2 of the things I like about Go they are tooling and removed inheritance. Being able to fire up a fully formed, non-handicapped environment consisting of only vim and some command line tools is great. I've tried repeatedly on the JVM to accomplish this and always end up back with bloated IntelliJ and t…

>> bloated IntelliJ and the vim plugin as my only option

Bloated it may be but helps me get the job done faster...much faster than I can do it in vim. I work on a mac with 16 GB RAM and thats sufficient for lots of processes. Every bit of the way, I have documentation I can lookup right within as I type, I have autocomplete that always works, I have debugger support to catch little things I missed, tons of libraries and plugins that have stabilized over the years...whats not to like? The downsides (and the reason I looked at go) are both Java and .Net are memory hogs. I needed something more lighter that would offer the same level of productivity during development.

Re: Go Is a Shop-Built Jig

#97

Post by sat »

polux wrote: post #76
tagrun wrote: post #9

Earlier quoted context omitted.

As you have discovered the hard way, trying to write Java in Go is not productive.

IDE support is not a prerogative of Java.

I attempted not to. What pulls me back is the fact that I am trying to force go to help me reuse data structures I already have (without turning to reflection everytime or manually typecasting).

Re: Go Is a Shop-Built Jig

#98

Post by sat »

smegel wrote: post #31
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…

> a small shop that runs on scanty resources and needs to build robust and reliable applications, a heavy weight like Java or .Net is still ruling the roost. That seems to be the opposite usual scenario for "heavyweight" enterprise frameworks. I actually think Go hits the sweetspot - faster to develop in than Java/.NET, but much more robust, reliable and faster than the scripting languages.

Here is a competition. I'd write in Java and you can write in go. Lets crank out a simple ToDo CRUD application. Any bet who will finish faster?

This is not to say go is bad at all. Its been designed by people 1000x smarter than me. But it isn't helping small shops go any faster or be more productive than they are with current setup. Talk about progress of the 21st century programming language...can't find much.

Re: Go Is a Shop-Built Jig

#99

Post by sat »

mentat wrote: post #28
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

Struct embedding is just syntactic sugar. Have you tried using reflection to look at the fields of the struct? You don't have a chance of looking that the embedded field properties as if they were truly embedded (flattened out as in inheritance) using reflection. Now put that opposite inheritance. No matter what you do (reflection, direct access what not), you still can get to those properties. See why I am saying go is making it harder? Its those cranny little details that you experience that drop your productivity.

Re: Go Is a Shop-Built Jig

#100

Post by enneff »

bascule wrote: post #93
enneff wrote: post #38

Earlier quoted context omitted.

Generics are not a problem to be solved, they're a tool to solve problems.

The lack of generics is definitely a problem. You can't write generic code, and end up having to write your own thunks for each type you want to use. The standard library can't expose generic facilities that work on any type. This should be evidenced by the fact that Go is the only mainstream statically typed language without parametric polymorphism. Worse, trying to bolt it on after the fact has generally lead to ug…

> The lack of generics is definitely a problem.

Not to me. Not to the author of this article.

> I expect Go will eventually follow Java's lead and bolt on generics awkwardly.

Nope. They'll either be done right or not at all. We're not ignoring Java's mistakes.

Post reply on HN