101–110 of 311 posts
Earlier quoted context omitted.
There's really nothing about a typical map operation that makes it any more parallelize-able than a for-loop, in the presence of closures.
The article is about Rust. In Rust, the type of the closure indicates whether it can mutate externally visible data (and therefore race on it).
Earlier quoted context omitted.
The plan is to release 1.0 around the end of the year. In that sense, Rust isn't done, but it is near done.
Unlike other languages that are "done" at 1.0, Rust will still be improving and iterating. 1.0 defines a backwards-compatible release that you can depend on but the language won't be "done". "It’s important to be clear about what we mean by stable. We don’t mean that Rust will stop evolving. We will release new versions of Rust on a regular, frequent basis, and we hope that people will upgrade just as regularly. But…
Earlier quoted context omitted.
I'm thinking of the crowd that insists "map" is never more useful or readable than s straight for-loop. So not only don't they want it in go (which could be understandable in some situations), they genuinely seem to think it has no place in an imperative language. That blows my mind.
I've written in both paradigms and I mostly agree with the Go team. That it blows your mind blows mine, and I suppose it's good that we have these choices so we don't have to agree. Could you show me a code snippet of maps and filters used that you believe is more readable than for loops? Maybe I'll get a laugh out of that. :)
def isAnagramOfPalindrome(s: String): Boolean =
s.groupBy { c => c }
.map { case(key, value) => value.size() }
.filter { n => n % 2 != 0 }
.size function isAnagramOfPalindrome(str) {
var chars = {};
for (var i = 0; i Having spent a little time with Go, I ended up feeling like it was both better and worse than Ruby. In many ways it's many of the things that I want from a language - static typing, fast complier, pretty sensible defaults and so on. A lot of things I wish Ruby did, Go does great. I think Go does really well in tooling, but it doesn't feel as great in syntax or language features that I would really like. The two big o…
the thing that has got me excited about learning go some day is that it's supposed to be really good at cross-compiling code into small, standalone binaries for the three major platforms (linux, windows, osx). haxe is another language on my radar for much the same write-once-deploy-all-over-the-place reason.
Earlier quoted context omitted.
There are a lot of comments in that thread, is there anything specific you think stands out? Some of Ian's initial comments were saying that they are being very very careful about what gets added to the language. Also, at this point the language syntax itself is basically locked. And from everything I've seen, they are focusing more on the runtime and tooling before they make any serious changes to the code language.
I think Ian (who works on Go) summed it up nicely. To paraphrase: yes map/reduce is useful but it's another built-in generic so it adds a lot of complexity and it's not worth the trade-off. This rounds back into Go's generics debate. If they give in with implementing map/reduce, they might as well start implementing some form on generics. I think Go is for people who are in-line with the golang crew's views on langua…
To a language user the benefits might be clear but the problems not.
To a language implementor the problems will be much clearer.
Earlier quoted context omitted.
Use unsigned integers for your index and values. That's what makes it hard to use a for loop. (Sure, you could cast a signed integer loop index to unsigned inside the loop to avoid the underflow problem in this specific case, but I'd argue that the functional style is so much clearer than code that has to work around unsigned underflow gotchas.)
All I did was take your for-loop code and translated into idiomatic Go code. My point is the for-loop in Go isn't as terrible as the loop example you wrote.
See why for loops are tricky? :)
Earlier quoted context omitted.
The article is about Rust. In Rust, the type of the closure indicates whether it can mutate externally visible data (and therefore race on it).
Gotcha! So will Rust then auto-parallelize these "pure" closures?
(Note that Servo has been using this type system feature for a while now to prevent data races in our massively parallel CSS layout code.)
Earlier quoted context omitted.
Let me save the reader of this comment a long and unproductive session of reading tea leaves out of mailing list posts: * Golang doesn't have generics. This comes up so often on the mailing list that it's in the FAQ: http://golang.org/doc/faq#generics * Golang has a similar attitude to idiomatic functional programming tools as Python; it doesn't have map() and it's not easy to write a general-purpose map. (I'll take…
Umm... Am I just interpreting you wrong? Python has map in the builtin namespace: >>> map(lambda x: x*5, range(5)) [0, 5, 10, 15, 20]
If you are considering Go, or just want a good laugh, just read discussions where higher order functions are discussed. Or for that matter, generics. Here is a gem: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC... There's a chance you'll laugh at the people dismissing higher order functions as nonsense, in which case Go might not be for you. This is a good test of whether you want to try it out or not.
I liked Rob Pike's driveby comment - programmers these days...