5 ms·

Mostly because I can't stand Javascript. It makes me cringe just thinking about it. Go is much nicer to work with.

by treeder 14y ago

thibaut_barrere 14y ago
Although I personally like CoffeeScript, I must say that Go fills me with joy for some reason. It feels "fresh" and lightweight to the beginner, and reminds me of TurboPascal in some ways.
methehack 14y ago
Hey OP! I appreciate your sharing. Since you came from ruby and we're on the topic of the language itself, I'd appreciate your impression of how well Go supports collections. Is there or could one write something like http://underscorejs.org/ http://underscorejs.org/? Can you do this kind of thing? [1, 2, 3, 4, 5].reject {|i| i < 3}.map {|i| i + 9} I did the go tutorial the other day and I became a little worried that one would not be able to do this kind of thing without a bunch of unwieldy declarations. I think that would be a showstopper for me. Thanks for any insight you might have!
- jbooth 14y ago
  Go has first-class functions, so you could write a library do the same thing with, yes, a few more declarations around it. In your example, .map { |i| i + 9 } is .map( func(i int) int { return i + 9 }), or .map(myFuncDefinedElsewhere) in most real-world scenarios. As a commenter upthread pointed out, Go and serverside Javascript are aimed at very different use cases and audiences.
  - deleted 14y ago
    [deleted]
  - TresAmiga 14y ago
    Wrong and you know it. Go does not have generics so you have to use void* (interface{}) and casting. It ends up being about an order of magnitude uglier and more verbose. Which is why map, fold, etc don't exist in Go. You go fanatics are incorrigible.
    - drivebyacct2 14y ago
      Seriously? Is this just a coincidence that another throwaway named "TakeTwo" and then "TresAmiga" are both making throw aways and dismissing all Go users? Jesus. What he's describing is far more than possible using interfaces. I have plenty of code that does so. How is that "wrong and he knows it". Your worse than any Go fan here. Where the hell does someone get off being vitriolic about a language or someone's preference for that language. Pathetic, at least have the balls to post under your real account. That having been said, as an "incorrigible Go fan", I would love to see proper generics. It's something I'm enjoying in Rust. It's also something that everyone is open to adding in Go 2, so it doesn't necessarily have to be a permanent absence from Go.
      - jbooth 14y ago
        There's some idiots who troll the #golang-nuts freenode channel occasionally with a bunch of spam saying 'node is way better!'. I assume they're not gainfully employed, or else they would understand that the two languages/platforms have very different goals and principles.
        drivebyacct2 14y ago
        `chord`? Yeah, I was in there and was one of the people feeding him/her, I'm ashamed to say. I'd had a few beers and wasn't on my best behavior. Chord was on about "Rails" is better, couldn't fathom a web world without MVC and failed to understand that Rails was just a framework on Ruby and that one could write similar helpers in Go. It was the perfect example of Dunning-Kruger. Painful to witness.
        jlgreco 14y ago
        I think there is honestly something wrong with that guy in a mild "losethos" sort of way. He started spamming me trollish nonsense in PMs because I dared utter a single line while he was active. Something about golang just seems to attract a certain flavor of nutters.
  - paddyforan 14y ago
    I thought this would be a fun exercise, so I implemented the Go equivalent. Can anyone get it to fewer lines? It abandoned all pretenses of readability long ago. http://play.golang.org/p/M5VaeIgQ-q http://play.golang.org/p/M5VaeIgQ-q
    - paddyforan 14y ago
      Updated to generalise a bit more. If this ever came up in code review, I'd probably facepalm pretty hard. http://play.golang.org/p/YUQSZgFx_b http://play.golang.org/p/YUQSZgFx_b
      - jbooth 14y ago
        Ha. Yeah, the map() and reject() function defs are fine but the actual usage is a little eye-bleed inducing :)
        paddyforan 14y ago
        So now that we've established Ruby is better at being Ruby than Go is, I wonder if there's an actual use case for this kind of thing, so I can demonstrate the "Go way" of handling it...
- rcb 14y ago
  If you're looking for more elegant methods of expressing this in a higher performance runtime, here are two examples. Erlang: [I+9 || I <- lists:seq(1,5), I >= 3] Haskell: [i+9 | i <- [1..5], i >= 3] Like go, both Erlang and Haskell both have strong concurrency stories. For an I/O bound server in a production environment, Erlang is a very safe choice. Compared to these list comprehensions, that ruby example looks unwieldy.
  - jasongrout 14y ago
    Even python looks more readable to me: [i+9 for i in range(1,6) if i>=3]
- paddyforan 14y ago
  Go does not have the fascination with one-liners that Ruby has. Which is why I like Go. In my experience, people who write in Go value code clarity over terseness.
- gnuvince 14y ago
  Go's lack of type parametrisation makes many higher order functions really awkward. I'm no expert on Go, but below is my attempt at writing a generic Map function. As you can see, the code of the Map function itself isn't so bad (though there's a lot of noise in the declaration). Using that function however is really annoying, as you need to convert from the slice you have ([]string, []int, etc.) to an empty interface slice, and in the function you give to Map, you need to dispatch on the element's dynamic type. I think this is why Go people prefer to just use for loops and not do the whole higher-order combinators stuff. package main import ( "fmt" ) func Map(fn func(interface{}) interface{}, xs []interface{}) []interface{} { res := make([]interface{}, len(xs)) for i, x := range(xs) { res[i] = fn(x) } return res } func main() { words := []string{"foo", "bar", "baz"}; // First we need to create a version of words that has the []interface{} type. interface_words := make([]interface{}, len(words)) for i, w := range(words) { interface_words[i] = interface{}(w) } fmt.Printf("%v\n", Map( func(x interface{}) interface{} { switch s := x.(type) { case string: return s + "!!" } return interface{}(0) // Need to please the compiler. }, interface_words)) }
  - methehack 14y ago
    Thank you for your answer. If you're right and this is the Go way to do it (and I have no reason to doubt you), it's exactly what I was afraid of. I can see why for loops would just read better. Feels like a step in the wrong direction though -- at least for me.
    - gnuvince 14y ago
      Go's lack of parametric polymorphism is an abundant source of Internet debate; proponents of Go say that it keeps the language simpler and find that they don't miss it in practice. I won't get into that debate (it's too late anyway), but I'll say that if you are writing an application, that kind of polymorphism might not be as useful since you can know all the types of your application. Why bother making a generic function if you know you are only ever going to use it with strings? When you are writing libraries however, you don't have this sort of freedom.
- deleted 14y ago
  [deleted]

Mostly because I can't stand Javascript. It makes me cringe just thinking about it. Go is much nicer to work with.

by treeder 14y ago

Mostly because I can't stand Javascript. It makes me cringe just thinking about it. Go is much nicer to work with.

Although I personally like CoffeeScript, I must say that Go fills me with joy for some reason. It feels "fresh" and lightweight to the beginner, and reminds me of TurboPascal in some ways.

methehack 14y ago

Hey OP! I appreciate your sharing. Since you came from ruby and we're on the topic of the language itself, I'd appreciate your impression of how well Go supports collections. Is there or could one write something like http://underscorejs.org/ http://underscorejs.org/? Can you do this kind of thing? [1, 2, 3, 4, 5].reject {|i| i < 3}.map {|i| i + 9} I did the go tutorial the other day and I became a little worried that one would not be able to do this kind of thing without a bunch of unwieldy declarations. I think that would be a showstopper for me. Thanks for any insight you might have!

jbooth 14y ago
Go has first-class functions, so you could write a library do the same thing with, yes, a few more declarations around it. In your example, .map { |i| i + 9 } is .map( func(i int) int { return i + 9 }), or .map(myFuncDefinedElsewhere) in most real-world scenarios. As a commenter upthread pointed out, Go and serverside Javascript are aimed at very different use cases and audiences.
- deleted 14y ago
  [deleted]
- TresAmiga 14y ago
  Wrong and you know it. Go does not have generics so you have to use void* (interface{}) and casting. It ends up being about an order of magnitude uglier and more verbose. Which is why map, fold, etc don't exist in Go. You go fanatics are incorrigible.
  - drivebyacct2 14y ago
    Seriously? Is this just a coincidence that another throwaway named "TakeTwo" and then "TresAmiga" are both making throw aways and dismissing all Go users? Jesus. What he's describing is far more than possible using interfaces. I have plenty of code that does so. How is that "wrong and he knows it". Your worse than any Go fan here. Where the hell does someone get off being vitriolic about a language or someone's preference for that language. Pathetic, at least have the balls to post under your real account. That having been said, as an "incorrigible Go fan", I would love to see proper generics. It's something I'm enjoying in Rust. It's also something that everyone is open to adding in Go 2, so it doesn't necessarily have to be a permanent absence from Go.
    - jbooth 14y ago
      There's some idiots who troll the #golang-nuts freenode channel occasionally with a bunch of spam saying 'node is way better!'. I assume they're not gainfully employed, or else they would understand that the two languages/platforms have very different goals and principles.
      - drivebyacct2 14y ago
        `chord`? Yeah, I was in there and was one of the people feeding him/her, I'm ashamed to say. I'd had a few beers and wasn't on my best behavior. Chord was on about "Rails" is better, couldn't fathom a web world without MVC and failed to understand that Rails was just a framework on Ruby and that one could write similar helpers in Go. It was the perfect example of Dunning-Kruger. Painful to witness.
        jlgreco 14y ago
        I think there is honestly something wrong with that guy in a mild "losethos" sort of way. He started spamming me trollish nonsense in PMs because I dared utter a single line while he was active. Something about golang just seems to attract a certain flavor of nutters.
- paddyforan 14y ago
  I thought this would be a fun exercise, so I implemented the Go equivalent. Can anyone get it to fewer lines? It abandoned all pretenses of readability long ago. http://play.golang.org/p/M5VaeIgQ-q http://play.golang.org/p/M5VaeIgQ-q
  - paddyforan 14y ago
    Updated to generalise a bit more. If this ever came up in code review, I'd probably facepalm pretty hard. http://play.golang.org/p/YUQSZgFx_b http://play.golang.org/p/YUQSZgFx_b
    - jbooth 14y ago
      Ha. Yeah, the map() and reject() function defs are fine but the actual usage is a little eye-bleed inducing :)
      - paddyforan 14y ago
        So now that we've established Ruby is better at being Ruby than Go is, I wonder if there's an actual use case for this kind of thing, so I can demonstrate the "Go way" of handling it...
rcb 14y ago
If you're looking for more elegant methods of expressing this in a higher performance runtime, here are two examples. Erlang: [I+9 || I <- lists:seq(1,5), I >= 3] Haskell: [i+9 | i <- [1..5], i >= 3] Like go, both Erlang and Haskell both have strong concurrency stories. For an I/O bound server in a production environment, Erlang is a very safe choice. Compared to these list comprehensions, that ruby example looks unwieldy.
- jasongrout 14y ago
  Even python looks more readable to me: [i+9 for i in range(1,6) if i>=3]
paddyforan 14y ago
Go does not have the fascination with one-liners that Ruby has. Which is why I like Go. In my experience, people who write in Go value code clarity over terseness.
gnuvince 14y ago
Go's lack of type parametrisation makes many higher order functions really awkward. I'm no expert on Go, but below is my attempt at writing a generic Map function. As you can see, the code of the Map function itself isn't so bad (though there's a lot of noise in the declaration). Using that function however is really annoying, as you need to convert from the slice you have ([]string, []int, etc.) to an empty interface slice, and in the function you give to Map, you need to dispatch on the element's dynamic type. I think this is why Go people prefer to just use for loops and not do the whole higher-order combinators stuff. package main import ( "fmt" ) func Map(fn func(interface{}) interface{}, xs []interface{}) []interface{} { res := make([]interface{}, len(xs)) for i, x := range(xs) { res[i] = fn(x) } return res } func main() { words := []string{"foo", "bar", "baz"}; // First we need to create a version of words that has the []interface{} type. interface_words := make([]interface{}, len(words)) for i, w := range(words) { interface_words[i] = interface{}(w) } fmt.Printf("%v\n", Map( func(x interface{}) interface{} { switch s := x.(type) { case string: return s + "!!" } return interface{}(0) // Need to please the compiler. }, interface_words)) }
- methehack 14y ago
  Thank you for your answer. If you're right and this is the Go way to do it (and I have no reason to doubt you), it's exactly what I was afraid of. I can see why for loops would just read better. Feels like a step in the wrong direction though -- at least for me.
  - gnuvince 14y ago
    Go's lack of parametric polymorphism is an abundant source of Internet debate; proponents of Go say that it keeps the language simpler and find that they don't miss it in practice. I won't get into that debate (it's too late anyway), but I'll say that if you are writing an application, that kind of polymorphism might not be as useful since you can know all the types of your application. Why bother making a generic function if you know you are only ever going to use it with strings? When you are writing libraries however, you don't have this sort of freedom.
deleted 14y ago
[deleted]