It feels "fresh" and lightweight to the beginner, and reminds me of TurboPascal in some ways.
[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!
As a commenter upthread pointed out, Go and serverside Javascript are aimed at very different use cases and audiences.
You go fanatics are incorrigible.
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.
I assume they're not gainfully employed, or else they would understand that the two languages/platforms have very different goals and principles.
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.
Something about golang just seems to attract a certain flavor of nutters.
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.
In my experience, people who write in Go value code clarity over terseness.
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))
}http://play.golang.org/p/oH850AdLuQ
what you don't realize (apart from the fact that go doesn't terminate lines with semicolons since 2009) is that you don't need to create a copy that's typed []interface{} because []X already satisfies interface{} and you can use reflection to handle it. if a seasoned Go programmer wanted to write a somewhat generic map function they'd do something similar to this:
http://play.golang.org/p/qM8sBNcdwY
It doesn't look pretty and you're right, most go programmers don't have to write code like this. It is much more common to define a common interface for something that's map-able and expect callers to implement that. examples in sort.Interface.
Also, what about semi-colons?
nevermind the semicolons, 'twas a joke :)