61–70 of 311 posts
tl;dr: Guy who knows Rust better than Go prefers Rust over Go.
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.
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.
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 language design. For the rest, use any other strongly typed language that has sort form of type-abstraction/generics (which pretty much they all do).
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 think to properly write a language comparison, you need to have extensively used both languages and with multiple use cases. For example: I've recently attempted writing a small service in Go and it only took a few hours for me to figure out how weak a language could be without some sort of type-abstraction or generics: I had to implement a FindValueInArray() twice for two different types. This should be a big issu…
True, but you can assess how approachable a language is by simply approaching it. This is useful information. You could even argue that experience would disqualify you from reviewing using that angle!
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. :)
golang goroutine let me built a standalone binary with embedded https server and websocket support. Would Rust be able to do that even at 1.0 release without relying on low-level C library wrappers ?
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.
What an infuriating thread. I guess I'm not the kind of person Go is made for, but the fact that everyone in the thread was so close-minded about what might be helpful about map, filter, and reduce was frankly absurd. I especially enjoyed the demonstration of map would look in Go code, complete with a useless anonymous function: > bar = map(foo, func(e T) { return f(e) }) And this guy who doesn't seem to understand t…
Not a bad write-up. The Rust code snippets can be slimmed down very slightly though. Here's main(): fn main() { let args = os::args(); let washed_args = args.iter().map(|arg| arg.as_slice()).collect:: >(); match washed_args.as_slice() { [_, "review", opts..] => review(opts), _ => usage() } } although I might actually suggest the alternative approach: fn main() { let mut args = os::args().into_iter(); args.next(); //…
I'm surprised at the paragraph about rust having erlang style actor based parallellism... From what i've read, parallel programming was still heavily a work in design in Rust ( had a very recent discussion on using rust for http server side coding on HN whith people confirming this to me). golang goroutine let me built a standalone binary with embedded https server and websocket support. Would Rust be able to do that…
That said, Rust does encourage message passing by default, but also gives you the ability to safely do shared-memory concurrency if you need.