Live data from Hacker News

Go Is a Shop-Built Jig

robnapier.net

31–40 of 110 posts

Re: Go Is a Shop-Built Jig

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

Re: Go Is a Shop-Built Jig

#32

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

Define what you mean by hard and then I can say whether you're correct or not. Otherwise you're putting words in my mouth. I didn't say I want programming to be "hard" but I did say I'd rather work with smarter people. That doesn't mean smarter programmers exclusively program in Haskell, Erlang, Clojure, Scheme, Racket, SmallTalk, etc. I find programming overall to be quite easy in any language once you're used to thinking with the abstractions the language offers. The hard part is communicating with other people.

Also, your "less anecdotally" is by definition pretty anecdotal.

Re: Go Is a Shop-Built Jig

#34
post #16

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…

> OS and Android supports are on their way in case you're not following recent developments.

Yes, but it remains to be seen how Go's view on data structures map Objective-C and Java APIs.

As for Android support, the Android team doesn't seem to care any little bit about it, given their statements on Google IO.

So you have developers of a Google language trying to target a Google platform, where the platform owners just want to support Java (NDK is a kind of stepchild).

Re: Go Is a Shop-Built Jig

#35
post #17

Earlier quoted context omitted.

From the article: "Go feels under-engineered because it only solves real problems" "and so you build real solutions rather than finding excuses to use your beautiful tools" The implication from reading the article is that those of us that rely on those so called exotic features aren't doing so for serious business and technical reasons. And it seems to be a common thread amongst many Go users. And generics allow you…

> The implication from reading the article is that [...] The implication you inferred from reading the article is that... I think there reason is that there a misunderstanding here caused by a cultural gap. The Practice of Programming is a very good read which I feel like recommending to every programmer. > And generics allow you to reuse existing components much cleaner and exceptions allow you to handle errors in a…

> You don't build error handling classes in Go.

That much is true, you compare strings!

Re: Go Is a Shop-Built Jig

#36

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.

They probably mean that you are solving problems, real world and other, but you don't really need features like generics to do the "real world" part. Their proof is in things they have done, projects they have completed. If more projects and developers tried to use Go they might also find that a lot of projects can work with Go. Regarding the 20+ developers I am pretty shure Google has Go projects with many developers. I also think they were clearly targeting enterprise projects. Google is a huge enterprise with huge programming projects.

Re: Go Is a Shop-Built Jig

#37

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…

I don't think it's necessarily about mistrust of other programmers. It's more that we all have tendencies to over-engineer the small stuff, so with Go giving you fewer ways to do things you spend more time thinking about the job you're getting paid to solve.

Re: Go Is a Shop-Built Jig

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

Re: Go Is a Shop-Built Jig

#39
post #34
post #16

Earlier quoted context omitted.

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

> OS and Android supports are on their way in case you're not following recent developments. Yes, but it remains to be seen how Go's view on data structures map Objective-C and Java APIs. As for Android support, the Android team doesn't seem to care any little bit about it, given their statements on Google IO. So you have developers of a Google language trying to target a Google platform, where the platform owners ju…

The rough shape the GoJava mapping has already been formed:

https://godoc.org/code.google.com/p/go.mobile/cmd/gobind

Re: Go Is a Shop-Built Jig

#40
post #35
post #17

Earlier quoted context omitted.

> The implication from reading the article is that [...] The implication you inferred from reading the article is that... I think there reason is that there a misunderstanding here caused by a cultural gap. The Practice of Programming is a very good read which I feel like recommending to every programmer. > And generics allow you to reuse existing components much cleaner and exceptions allow you to handle errors in a…

> You don't build error handling classes in Go. That much is true, you compare strings!

Or do type assertions.
Post reply on HN