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

101–110 of 110 posts

Re: Go Is a Shop-Built Jig

#101

Post by georgemcbay »

dkarapetyan wrote: post #54
georgemcbay wrote: post #46

Earlier quoted context omitted.

"I know personally I'm good enough to do magical, wizardly stuff" In my experience really good developers don't see it like that, they see it more like the Brian Kernighan quote: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" It isn't that they are worried that "lesser" programmers will make…

I agree but you can do that in any language. That's more a reflection of the programmer than the language.

True, but what makes Go different than a lot of languages is that it basically guides you into doing things in the most straightforward way possible by making it a PITA not to do so (see: the unsafe package).

If you have an infallible sense of discipline then you don't need this sort of guidance, but given unlimited flexibility a lot of developers can easily lapse into fat-kid-in-a-candy-store mode regardless of their knowledge and skill level.

Re: Go Is a Shop-Built Jig

#102

Post by smegel »

sat wrote: post #98
smegel wrote: post #31

Earlier quoted context omitted.

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

> Lets crank out a simple ToDo CRUD application. Any bet who will finish faster?

Well I haven't done much web programming in Go, so I would not be very fast. I have done a lot in Python, and I usually finish prototype apps within days while the Java teams are still stuck in meetings with the Oracle DBAs trying to work out why Hibernate is generating shitty SQL again. And I believe Go is comparable to Python as far as productivity is concerned, but with type-safety and speed.

I think there is a lot to commend of Java, well at least the JVM, and the tooling and libraries are great, as is the performance. But I rarely hear anyone argue it is a fast, agile language to develop in.

Re: Go Is a Shop-Built Jig

#103

Post by fineline »

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…

> Sigh... this "where's my feature!" argument almost always comes up.

I'll make it simple. Nimrod has one feature - only ONE - which differentiates it from Go. It's not generics, it's not inheritance, it's not proper error handling (cos they're all just fancy features which nobody really needs, right?), it's not even optional garbage collection (although that's a part of it, Go is not suitable for constrained real time applications because of its opinionated lack of optionality in this space).

It's REACH.

You know, the thing that has made JavaScript the most widely used language on the planet - and nobody's claiming THAT's got the greatest feature set.

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

Yes I am, and the closest I came up with was this:

https://bitbucket.org/minux/goios/wiki/Home

Seriously? I mean, have you tried this? Have you even tried to make sense of the build instructions?

If you have the inside line on some secret Google plans for Go then good on you. But if you're going to make public claims like this - in a forum where people might be interested to hear about tools that help them DO cross-platform development rather than just dream about doing it one day - you should be prepared to back them up.

Challenge: you implement a cross platform library in Go, I'll do one in Nimrod, we'll upload working XCode and Android projects that use our shared library and that compile to App Store / Play Store eligible apps to Github. I'm up for it - are you?

Re: Go Is a Shop-Built Jig

#104

Post by bascule »

enneff wrote: post #100
bascule wrote: post #93

Earlier quoted context omitted.

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.

I guess you're a fan of rewriting type thunks over and over and over again, and don't care about the standard library implementing functionality or reusably. Whatever floats your boat, but in both C++ and Java people got tired of writing type-thunking boilerplate over and over again and eventually got features added to the language to fix the problem.

At this point I'm not sure how Go can do generics well, so if "right or not at all" is really the bar, then Go will probably never get them.

Re: Go Is a Shop-Built Jig

#105

Post by sj4nz »

chvid wrote: post #86

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

frob is a https://en.wikipedia.org/wiki/Metasyntactic_variable , but not a "common one" which may have led to your confusion.

Re: Go Is a Shop-Built Jig

#106

Post by chvid »

sj4nz wrote: post #105
chvid wrote: post #86

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

frob is a https://en.wikipedia.org/wiki/Metasyntactic_variable , but not a "common one" which may have led to your confusion.

Ok. Maybe I am not getting the joke then. So thingsToFrobulate, logit, cleanupOldest, processOld, doNewThing, cleanup and FrobulatingMessage are "metasyntactic variables" too?

Re: Go Is a Shop-Built Jig

#107

Post by sat »

smegel wrote: post #102
sat wrote: post #98

Earlier quoted context omitted.

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.

> Lets crank out a simple ToDo CRUD application. Any bet who will finish faster? Well I haven't done much web programming in Go, so I would not be very fast. I have done a lot in Python, and I usually finish prototype apps within days while the Java teams are still stuck in meetings with the Oracle DBAs trying to work out why Hibernate is generating shitty SQL again. And I believe Go is comparable to Python as far as…

Well, I was just comparing Java - a complied, strictly typed languages to another in the same domain - Go. Scripting and interpreted languages like python, ruby are a different thing altogether. I agree with you that ruby/rails or python/django get it done a lot faster. On the JVM, we get close but not quite - with Grails and Play. Spring Boot seems to be getting up there as well in terms of productivity. They still have some way to go.

Re: Go Is a Shop-Built Jig

#108

Post by sj4nz »

chvid wrote: post #106
sj4nz wrote: post #105

Earlier quoted context omitted.

frob is a https://en.wikipedia.org/wiki/Metasyntactic_variable , but not a "common one" which may have led to your confusion.

Ok. Maybe I am not getting the joke then. So thingsToFrobulate, logit, cleanupOldest, processOld, doNewThing, cleanup and FrobulatingMessage are "metasyntactic variables" too?

It just comes down to a habit of giving a name to something as an example of something that isn't meant to map to any problem domain. E.g. when a manufacturer is in the business of making "widgets," we know they're not actually making products that are widgets (whatever those are.)

Once you know that the names being used are not considered to be "important", the other names aren't as important as well, only the syntax. These metasyntactic variables are useful for avoiding situations like "Who's on First?" (e.g. https://www.youtube.com/watch?v=kTcRRaXV-fg ) which is humorous to native-English speakers, but probably incoherent to non-native English speakers.

Re: Go Is a Shop-Built Jig

#109

Post by vorg »

sat wrote: post #107
smegel wrote: post #102

Earlier quoted context omitted.

> Lets crank out a simple ToDo CRUD application. Any bet who will finish faster? Well I haven't done much web programming in Go, so I would not be very fast. I have done a lot in Python, and I usually finish prototype apps within days while the Java teams are still stuck in meetings with the Oracle DBAs trying to work out why Hibernate is generating shitty SQL again. And I believe Go is comparable to Python as far as…

Well, I was just comparing Java - a complied, strictly typed languages to another in the same domain - Go. Scripting and interpreted languages like python, ruby are a different thing altogether. I agree with you that ruby/rails or python/django get it done a lot faster. On the JVM, we get close but not quite - with Grails and Play. Spring Boot seems to be getting up there as well in terms of productivity. They still…

> Scripting and interpreted languages like python, ruby are a different thing altogether. I agree with you that ruby/rails or python/django get it done a lot faster. On the JVM, we get close but not quite - with Grails and Play

Play doesn't use a scripting/interpreted language, it uses Scala, a statically-typed one, but with type inference which you may have confused with dynamicity. As for Groovy/Grails, they seem to be dying off lately.

Re: Go Is a Shop-Built Jig

#110

Post by kasey_junk »

sat wrote: post #96
kasey_junk wrote: post #8

Earlier quoted context omitted.

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…

But that's the beauty of the go tool chain. I have a source browser (godef), a documentation browser (godoc), a code style formatter (go fmt), code vetting (vet), unit testing (go test), a linter (golint) etc. and they are all fast command line programs. This means that it is trivial to setup a vim/command line environment the way I like.

In my vim setup with simple key strokes, I can go to the source of, see the type definition of, see the documentation for the call under the cursor. I have formatting, vetting, and if you want compiling on save of the file (and it's super fast). I have autocomplete that behaves exactly as I want it to.

I wish there was better ctags support for go, and the go oracle tool is more prototype than production software, but on the whole I am much happier with my development chain in go than I've ever been on the JVM or .NET.

Post reply on HN