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

Leaving Go

jozefg.bitbucket.org

Post reply on HN
Print view View original

51–60 of 220 posts

Re: Leaving Go

#51

Post by slantedview »

chimeracoder wrote: post #5

As someone who writes both Lisp and Go (and enjoys both), I find it odd that this article uses Lisp and Haskell as points of comparison. > programming in Go isn’t “fun” in the same way that Python, Haskell, or Lisp is. Yes, writing Lisp is much more "fun" than writing Go for me. But writing Go is much more productive and maintainable (both for solo projects and for larger groups). In fact, this is almost an intention…

Yes, Go is boring, but it's interesting that the people who hate on Go for being boring are not the same people who hate on Java for being boring (though Java 8 is much improved).

Re: Leaving Go

#52

Post by m0th87 »

tptacek wrote: post #24

If you're looking for a language that will enable "bottom-up development", where you gradually define, in Paul Graham On Lisp style, a language optimized for your problem domain, Golang is not the language for you. Similarly, if you're looking for a language that will read and write like a specification for your problem domain, so that writing your program has the side effect of doing half the work of proving your pr…

You're right, Golang is all about pragmatism, and a very pragmatic thing for language designers to do is to listen to the marketplace on how the language should evolve. Lack of polymorphism must be the most common critique of Golang. It seems pretty practical to add it, as it would greatly reduce the amount of boilerplate. And it's not as if polymorphism is stuck in the ivory tower - languages used in industry have had them for decades.

Re: Leaving Go

#53

Post by dragonwriter »

DAddYE wrote: post #3

> I’ve been using Go since November and I’ve decided that it’s time to give it up for my hobby projects. I’d still be happy to use it professionally, but I find that programming in Go isn’t “fun” in the same way that Python, Haskell, or Lisp is. I can't leave go, but indeed I think absolutely the same. The thing is that GO was designed to replace c++ thing that absolutely failed. So we have a python/ruby replacement…

> The thing is that GO was designed to replace c++ thing that absolutely failed.

I don't think Go was designed as a general replacement for C++, I think it was designed as a replacement for C++ for the things that Python was almost better than C++ for, but not quite.

EDIT: Though, OTOH, I do get the feeling that the people who designed Go largely are the type of people who feel that just-plain-C is a superior choice to C++ for most of the rest of the domain where C++ might be used, so they might view Go as a general replacement for C++, because they start with a smaller view of C++'s useful role than the market at large has.

Re: Leaving Go

#54

Post by StefanKarpinski »

coherentpony wrote: post #11
DAddYE wrote: post #3

> I’ve been using Go since November and I’ve decided that it’s time to give it up for my hobby projects. I’d still be happy to use it professionally, but I find that programming in Go isn’t “fun” in the same way that Python, Haskell, or Lisp is. I can't leave go, but indeed I think absolutely the same. The thing is that GO was designed to replace c++ thing that absolutely failed. So we have a python/ruby replacement…

>The thing is that GO was designed to replace c++ thing that absolutely failed. I was so excited for GO to become a nice replacement to C++. GO has awesome build times. C++ has awful build times. This is partly due to all the extra work the C preprocessor has to do make sure all the headers are present. The big lose for me is the fact that GO has absolutely no operator overloading. This is one of the biggest wins in…

I wrote this analysis [1] in the context of Julia vs. C++ about why I think that Go has not been successful as a C++ replacement. The primary issues are performance (the ability to trade off abstraction for performance, really), generics, and operator overloading. We did not intend for Julia to be a C++ replacement, but it turns out that it's quite a good one and a lot of adopters have come from C++ – I think that these features are why.

[1] https://groups.google.com/forum/#!msg/julia-users/-SGWPUBJKq...

Re: Leaving Go

#55

Post by ChuckMcM »

This is a great rant. Having recently done the 'golang' tutorial on the site a lot of it resonated with me. I have a slight advantage in that I worked at Google when Go came into existence and followed some of the debates about what problem it was trying to solve. The place it plugged in nicely was between the folks who wrote mostly python but wanted to go faster, and the folks who wrote C++. It was a niche that Java could not fill given its structure.

In a weird way, it reminds me of BLISS[1]. BLISS had this relationship to assembler that "made it manageable" while keeping things fast. BLISS was replaced by C pretty much everywhere that C took hold (one theory is that BLISS is the 'B' programming language, Algol is the 'A' language, personally I think BCPL is a better owner the the 'B' moniker). The things that C has issues with, memory management, networking, and multi-threading, Go takes on front and center. It keeps around some of the expressiveness and type checking that makes compiling it half the battle toward correctness.

Now that was kind of what the Java team was shooting for as well but with limited success. I feel like between Go and Java we've got some ideas of what the eventual successor language will look like. For me at least that is a step in the right direction.

[1] http://en.wikipedia.org/wiki/BLISS

Re: Leaving Go

#56

Post by bunkat »

Donch wrote: post #31

The example could have been simplified: func abs(x Top) Top { switch v := x.(type) { case int32: if v

This code doesn't actually compile. You can't assign v to x.(type) like that.

Re: Leaving Go

#57

Post by Jabbles »

As much as I want to emphasize that this is not the right way to think about programming in Go, I do want to point out that the example has a lot of extra code that isn't needed. Indeed, it's not really possible to have a bug of the kind the author wrote if written properly:

http://play.golang.org/p/puZBEmOVaI

Re: Leaving Go

#59

Post by protomyth »

tptacek wrote: post #24

If you're looking for a language that will enable "bottom-up development", where you gradually define, in Paul Graham On Lisp style, a language optimized for your problem domain, Golang is not the language for you. Similarly, if you're looking for a language that will read and write like a specification for your problem domain, so that writing your program has the side effect of doing half the work of proving your pr…

"If you're looking for a language that will enable "bottom-up development", where you gradually define, in Paul Graham On Lisp style, a language optimized for your problem domain, Golang is not the language for you."

Sounds like he is looking for Forth or one of its decedents (e.g. Factor). That is pretty much the definition of how you do Forth development.

Re: Leaving Go

#60

Post by personZ »

These sorts of posts are profoundly boring. I know people will up arrow it -- some sort of spiteful "Down with Go!" contrarian thing, when they aren't talking up rust -- but it isn't because the content is interesting or illuminating, but rather as some sort of activist thing.

This particular piece (by a high school student, as an aside) starts off trying to create a surrogate for generics in Go.

Don't.

Here's the thing -- most of these posts are not about people making real code, but people making -toy- code. Where every function is all things to all people.

The number of times I've needed a generic abs in my life -- zero.

The number of times I've needed a double floating point abs in my life -- every single time.

That's the thing about generics and real, actual world code: Your types are generally much less amorphous than you think. They really are. This illusion that everything needs to be everything just does not hold in the real world.

But it is always the tiring example used against Go. Boring.

Post reply on HN