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

Go is boring

aeronotix.pl

Post reply on HN
Print view View original

111–120 of 138 posts

Re: Go is boring

#111

Post by StavrosK »

slurgfest wrote: post #109
StavrosK wrote: post #97

As a long-time Python programmer, I tried Go recently for something that needed large amounts of concurrency (a hosted version of hubot: http://instabot.stochastictechnologies.com ), and I have to say, I am very pleasantly surprised. The type system was a bit cumbersome, after coming from Python, especially having to wrangle with pointers after not using them ever, but it's nothing you don't get used to. I'm still no…

I think what you gain from static typing is pretty much that you can compile your programs and run without a fat interpreter. Note - I am not saying that is the only possible benefit of static typing anywhere, e.g. in Haskell - this is more in line with C, you are doing type declarations to cue the compiler rather than to realize some utopian test-free development methodology.

Oh, definitely, I'm just not sure it gains that much speed compared to Python. I'd expect Go's speed to be on par with C, but, from what I understand, it's more like PyPy.

Of course, this is just from what I hear, I haven't run any benchmarks. Does anyone have more details about this?

Re: Go is boring

#112

Post by icebraining »

hythloday wrote: post #107
icebraining wrote: post #93

Earlier quoted context omitted.

no real first class functions - you barely use map/reduce/fold/etc. in python Can you expand on this?

I'll expand a little, because I've been feeling the same thing recently. Python has syntactic support for list[0] comprehensions, which can be used a little like maps: def addOne(n): return n+1 l = [1, 2, 3] [ addOne(n) for n in l ] # [2, 3, 4] a little like filters: def isOdd(n): return n % 2 == 1 l = [1, 2, 3] [ n for n in l if isOdd(n) ] # [1, 3] and a little like folds/reductions: def accum(s): acc = s def a(n):…

But Python has map(), filter() and reduce(). Why wouldn't you write your example as

    from operator import add
    reduce(add, filter(isOdd, map(addOne, l)))
I mean, I use list comprehensions when it makes sense, but I won't torture myself with them ;)

Re: Go is boring

#113

Post by papsosouid »

thebigshane wrote: post #31
ozataman wrote: post #29

I've tried giving Go a try a bunch of times now. My primary choice of language is Haskell and I just can't seem to get excited about Go.

Would you say your interest in programming languages is largely academic in nature? I get the impression that Haskell mostly (for now at least) fits best with academia, Java/C# for enterprise, python/ruby for smallish web apps, Go/C/C++/Java for industrial applications (like servers, etc). There is a very real possibility that Go is just not the right fit for you with your current requirements. No language is the rig…

I'm in the same boat as ozataman, go feels like a huge step backwards to me because I use haskell. My interest in programming languages is roughly 0% academic in nature. I use haskell primarily for web development (also random stuff like parsing log files, automating deployments, etc). I use it for these things because the practical benefits of such a high level language are so good, using anything else is painful.

Re: Go is boring

#114

Post by hythloday »

icebraining wrote: post #112
hythloday wrote: post #107

Earlier quoted context omitted.

I'll expand a little, because I've been feeling the same thing recently. Python has syntactic support for list[0] comprehensions, which can be used a little like maps: def addOne(n): return n+1 l = [1, 2, 3] [ addOne(n) for n in l ] # [2, 3, 4] a little like filters: def isOdd(n): return n % 2 == 1 l = [1, 2, 3] [ n for n in l if isOdd(n) ] # [1, 3] and a little like folds/reductions: def accum(s): acc = s def a(n):…

But Python has map(), filter() and reduce(). Why wouldn't you write your example as from operator import add reduce(add, filter(isOdd, map(addOne, l))) I mean, I use list comprehensions when it makes sense, but I won't torture myself with them ;)

Of course you can. But the poor support for lambdas and higher-order-functions makes comprehensions a worse-is-better solution, because you can e.g. pickle comprehension expressions (which you can't do for lambdas), and you don't need to import a module for reduce (in 3.x). I gave up on using them when I realized they were just too frictive (or that they were "un-Pythonic", if you prefer).

Re: Go is boring

#115

Post by jlouis »

onan_barbarian wrote: post #30

I reached the same conclusion ("Go is boring") myself, but with a different flavor. After having spent a great deal of time in recent years doing things like GPGPU and a _whole_ lot of SIMD programming (not to mention a lot of use of the STL, BGL, etc), I have to say I'm less impressed by the boringness (aka taking good, solid choices from existing languages) of Go. I understand that not everyone is excited about SIM…

You picked Go for the wrong reason then. Go is not about parallel programming, which SIMD and GPGPU programming is. Go is about concurrency and that is a completely different beast.

What Go is good for is a different thing. It is good for writing a webserver, which you won't really like to do in SIMD or on a GPGPU. The reason is that a webserver requires you to handle independent activity where things are inherently uncoordinated: while one client is connecting, the other is being sent data.

Vice versa, where Go is bad, is when you want to handle massive parallel computation where each computation is the same and you have to wait until all computation is done before you can continue. This means that you have a sequential program, you have to wait, but not a serial one, since all the computations could be executed on SIMD or a GPGPU in parallel.

Re: Go is boring

#116

Post by api »

C is boring too, in all the right ways. I think Go could be what we've been waiting for: C 2.0.

Re: Go is boring

#117

Post by [deleted] »

rblackwater wrote: post #82
jroesch wrote: post #61

Earlier quoted context omitted.

It only "sucks"(causes problems rarely, and can be quite useful regardless) in dynamic languages. Languages like Go, Rust, and Haskell provide the same flexibility with static guarantees. All you must do is define type specific implementations to satisfy the interface(or typeclass). For example in Haskell, I can so something like: class Stream s where read :: s -> (a, s) write :: a -> s -> s and extend it to any type…

I really wish more languages had the option of using a Haskell style type system.

[deleted]

Re: Go is boring

#118

Post by eru »

rblackwater wrote: post #82
jroesch wrote: post #61

Earlier quoted context omitted.

It only "sucks"(causes problems rarely, and can be quite useful regardless) in dynamic languages. Languages like Go, Rust, and Haskell provide the same flexibility with static guarantees. All you must do is define type specific implementations to satisfy the interface(or typeclass). For example in Haskell, I can so something like: class Stream s where read :: s -> (a, s) write :: a -> s -> s and extend it to any type…

I really wish more languages had the option of using a Haskell style type system.

Or even just plain Hindley-Milner.

Re: Go is boring

#119

Post by eru »

obtu wrote: post #86
eru wrote: post #11

Earlier quoted context omitted.

Alas, nobody has written a really good IDE for Haskell, yet. So we still have to run the show for that statically typed language manually.

What do you think of leksah?

I know of it, but haven't used it, yet. That's why my comment was a bit more guarded than it would have otherwise been. (Though re-reading that line, it doesn't come across as such to me now.)

Re: Go is boring

#120

Post by icebraining »

hythloday wrote: post #114
icebraining wrote: post #112

Earlier quoted context omitted.

But Python has map(), filter() and reduce(). Why wouldn't you write your example as from operator import add reduce(add, filter(isOdd, map(addOne, l))) I mean, I use list comprehensions when it makes sense, but I won't torture myself with them ;)

Of course you can . But the poor support for lambdas and higher-order-functions makes comprehensions a worse-is-better solution, because you can e.g. pickle comprehension expressions (which you can't do for lambdas), and you don't need to import a module for reduce (in 3.x). I gave up on using them when I realized they were just too frictive (or that they were "un-Pythonic", if you prefer).

I'm sorry, but can you clarify what you mean by poor support for higher-order-functions? And how can one pickle comprehension expressions?

I'm not trying to be argumentative, I just don't have much experience with that. I write functions that return functions/closures regularly, but they're always simple cases.

Post reply on HN