71–80 of 311 posts
I wonder what actor library the author is using with Rust. Given the status of github issues like https://github.com/rust-lang/rust/issues/3573 I thought there weren't any real options.
That said, Rust does encourage message passing by default, but also gives you the ability to safely do shared-memory concurrency if you need.
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'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…
In any case, Rust 1.0 is not aiming to be feature complete in language or library, it is just the point of guaranteed backwards compatibility and additions and improvements will continue. See:
- http://blog.rust-lang.org/2014/09/15/Rust-1.0.html
- http://blog.rust-lang.org/2014/10/30/Stability.html
The Rust standard library is not aiming to have async IO at 1.0, but external libraries have exactly the same low-level power as the standard library, so this functionality can be written externally, e.g. mio[0], and the Cargo package manager makes it super-easy to use them in your own applications (with reproducible builds, so no risk of upstream changes accidentally breaking the build).
Lastly, are you saying "(low-level C library) wrappers" or "low-level (C library wrappers)". The former is exactly what Rust will have, it has highly efficient FFI (a Rust -> C function call is the same as C -> C function call) and so can bind to the high-performance libraries other have written without any overhead. However, there's no reason that people can't build a nice and high-level API above the direct bindings though (this is exactly what happens, e.g. the game-development community has quite a few nice-to-use libraries[1] that are thin layers above the low-level C functionality).
[0]: https://github.com/carllerche/mio
[1]: https://github.com/rust-lang/rust/wiki/Computer-Graphics-and...
Earlier quoted context omitted.
Like you†, I've had the pleasure of working with some fairly large concurrent codebases and the character-building experience of tracking down deadlocks, random memory corruption bugs that turn out to be race conditions, and (my most favorite of all) unexpected serializations that randomly bring programs to a halt. Most of that experience has been in C++, with a little C and a little Java mixed in there. Over & over…
> why don't all those libraries and programs randomly deadlock and corrupt themselves all the time? The simplest answer would be "they do." In aphyr's recent presentation on Jepsen, where he tested etcd (a Go database implemented on top of Raft), he noted that when he started using it he encountered a ton of easily reproducible races and deadlocks (which he sarcastically noted was surprising because he thought gorout…
Earlier quoted context omitted.
> why don't all those libraries and programs randomly deadlock and corrupt themselves all the time? The simplest answer would be "they do." In aphyr's recent presentation on Jepsen, where he tested etcd (a Go database implemented on top of Raft), he noted that when he started using it he encountered a ton of easily reproducible races and deadlocks (which he sarcastically noted was surprising because he thought gorout…
Were there any code examples provided that show how to easily trigger races & deadlocks? I mean, the Go team needs to be aware of these problems and provide a fix or something.
My point wasn't that Go is _worse_ than contemporary languages like C++ and Java when it comes to data races, only that it doesn't eliminate them. Which, again, it doesn't claim to. Rust does, and it is an important difference between the two languages. Because data race freedom with cheap mutable state requires a garbage-collection free subset of your language [1], I think it's unlikely that Go will ever guarantee this.
[1] as noted by Niko Matsakis at http://smallcultfollowing.com/babysteps/blog/2013/06/11/on-t...
Earlier quoted context omitted.
Like you†, I've had the pleasure of working with some fairly large concurrent codebases and the character-building experience of tracking down deadlocks, random memory corruption bugs that turn out to be race conditions, and (my most favorite of all) unexpected serializations that randomly bring programs to a halt. Most of that experience has been in C++, with a little C and a little Java mixed in there. Over & over…
> why don't all those libraries and programs randomly deadlock and corrupt themselves all the time? The simplest answer would be "they do." In aphyr's recent presentation on Jepsen, where he tested etcd (a Go database implemented on top of Raft), he noted that when he started using it he encountered a ton of easily reproducible races and deadlocks (which he sarcastically noted was surprising because he thought gorout…
Maybe I'm wrong and etcd was riddled with concurrency problems between the goroutines of a single etcd process?
In any case: as anyone who has worked on a large-scale threaded C++ codebase can tell you: Golang programs simply do not exhibit the concurrency failures that conventional threaded programming environments do. It would be one thing if Golang code only used concurrency for, say, network calls. But goroutine calls are littered throughout the standard library, and throughout everyone's library code.
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…
Yeah, "Erlang style-actor" isn't exactly accurate anymore. A while ago, this was true, but it's not exactly true today. That said, Rust does encourage message passing by default, but also gives you the ability to safely do shared-memory concurrency if you need.
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(); //…
Your expect version changes behaviour: it does the allocation and string formatting unconditionally even if `have_dot_git(&cwd)` is `Some`. It is probably not a problem for this since the other operations are significantly more expensive, but it can be a gotcha if used inside a loop.
let dot_git_dir = have_dot_git(&cwd).unwrap_or_else(|| panic!("{} does not appear to have a controlling .git directory; you are not in a git repository!", cwd.display()));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.
* 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 Golang's lack of generics and map over Python's busted closures, and so call it a draw).
If you want to write programs in functional style, you don't want to use Golang. Pretty simple.
It's not clear how much experience the author really acquired with each language, and whether that experience was sufficient experience to justify his statement: Go felt that way to me — it was good at everything, but nothing grabbed me and made me feel excited in a way I wasn’t already about something else in my ecosystem. He's apparently using each language to write relatively small command-line utilities. If Go is…
who is still using C/C++ in 2014, and why? Systems programmers. Embedded programmers. Kernel developers. Compiler developers. Language runtime developers. Safety critical software developers. I guess you can group them under "performance benefits" but it's as much about the ability to drop down, write arbitrary bits to arbitrary addresses, and (re)implement low-level constructs as it is about performance. The most ob…
elliptic.nim: https://github.com/def-/bigints/blob/master/examples/ellipti...
elliptic.py: https://github.com/wobine/blackboard101/blob/master/Elliptic...
Others have reported success converting Python codebases directly to Nim. To put it in perspective [1]:
> The problem asked students to do a hundred runs and to try sample sizes of 10 and 100. For kicks, I did 1000 runs with a sample size of 1000. This took nearly 4 minutes in Python (macbook pro retina with i7 or i5? I forget...) and under 5 secs in Nim.
[1]: http://forum.nimrod-lang.org/t/589
Rust and Go vs Nim: http://goran.krampe.se/2014/10/20/i-missed-nim/