3 ms·

I've been following Rust for a bit, though not for anything serious as it seems very nichey. I do hope it picks up some momentum, though. I have to say, I've t

I've been following Rust for a bit, though not for anything serious as it seems very nichey. I do hope it picks up some momentum, though. I have to say, I've tried several times to move to Go and I've never fully embraced Go's syntax. For some reason I'm able to wrap my head around Rust much easier. I don't know the reason, but I can. I wonder what the future holds for Rust. In a world with Go, C, C++11, Scala and Obj C (among others), there is no shortage of languages it seems to directly compete with and b/c of that, you have to wonder where it will be in a year or 18 months.

pselbert 14y ago
I've had the same experience in trying to pick up go. The lack of some FP paradigms that I enjoy (iterators, namely) combined with most of the naming conventions just puts me off. I realize the goal is to be very paired down and easy to pick up, but it goes to far in limiting language constructs IMO. Rust has several features that I find compelling: optional memory management or GC, first class functions that maintain memory separation, and shared nothing concurrency. All with performance that is increasingly comparable to straight C. Truthfully I am mostly excited about the work Mozilla is doing lately and want to support their efforts where I can.
coolsunglasses 14y ago
Golang and Rust aren't made to solve the same problems. Go competes with Java and Python, Rust with C++. (Not with C, not really.) I don't really know why people keep comparing the two. Go - networked services, cmd-line utilities (writing unixy tools in Go is a joy), scalable scripts. Rust - fast (bleeding edge) client software, anything that needs stricter control of memory allocation semantics than most GC'd languages without going whole-hog. I'd be curious to see a write-up on what making a game engine in Rust would be like. Another key aspect of Go that Rust wasn't made for, is that Go is MUCH more focused on "developer experience" and project scalability. Everything is standardized, compiles damn near instantly, etc. Go solves Google problems (maintaining and developing on slow-compiling C++/Java projects just to make a network service when Python is insufficient) Rust solves Mozilla problems (complexity/performance/concurrency ramp up in large C++ projects, usually client software that has to be maximally performant)

pselbert 14y ago

I've had the same experience in trying to pick up go. The lack of some FP paradigms that I enjoy (iterators, namely) combined with most of the naming conventions just puts me off. I realize the goal is to be very paired down and easy to pick up, but it goes to far in limiting language constructs IMO. Rust has several features that I find compelling: optional memory management or GC, first class functions that maintain memory separation, and shared nothing concurrency. All with performance that is increasingly comparable to straight C. Truthfully I am mostly excited about the work Mozilla is doing lately and want to support their efforts where I can.

coolsunglasses 14y ago

Golang and Rust aren't made to solve the same problems. Go competes with Java and Python, Rust with C++. (Not with C, not really.) I don't really know why people keep comparing the two. Go - networked services, cmd-line utilities (writing unixy tools in Go is a joy), scalable scripts. Rust - fast (bleeding edge) client software, anything that needs stricter control of memory allocation semantics than most GC'd languages without going whole-hog. I'd be curious to see a write-up on what making a game engine in Rust would be like. Another key aspect of Go that Rust wasn't made for, is that Go is MUCH more focused on "developer experience" and project scalability. Everything is standardized, compiles damn near instantly, etc. Go solves Google problems (maintaining and developing on slow-compiling C++/Java projects just to make a network service when Python is insufficient) Rust solves Mozilla problems (complexity/performance/concurrency ramp up in large C++ projects, usually client software that has to be maximally performant)