I've been tempted to try getting rust going on some of the small arm micros I've got lying around. The memory safety would be tremendous boon for a lot of development there, same with the ownership/lifetime management. I think I'd probably have to strike most of the standard library but it'd still be really useful.
For me I keep seeing buffer overflows in router management stacks. It seems like rust would help protect routers from attack, while allowing low footprints.
Yea that's a common one I've done in a bunch of microcontroller things I've done. And there it's even more dangerous because you'll overflow the buffer, and change something and never have ANY idea you've done it until the consequences have happened. I ran into quite of few of those while setting up an allocator to get Lua running in <30k of ram without any floating point math.
Rust is likely to be popular for embedded work, where debugging is hard and crashing is often not tolerated.
Go is primarily for server-side web applications. That's Google's main business area, that's what they built it for, and that's where all the libraries are well-debugged.
I saw them talking about that, but it's completely obvious.
Nobody today is running C/C++ unless they need either A) complete speed or B) bare metal. Go can't do either, so there was going to be very little transfer from C/C++ to Go.
C++ is still mostly what I use, but I need neither speed nor bare metal. Maybe add C) people doing UI and applications?
There aren't many other good options:
Java: UI looks terrible; it's annoying living in Noun-land when CPUs are, if anything, more about verbs than nouns; and running properly on Windows is not trivial.
C#: Up until recently, not cross-platform unless you're ok with Mono. (But, might be worth looking in to now)
Python: great for scripts and experiments. The lack of static typing is a real problem when working with code other people wrote. Also, UI is not a strong point.
Go: what UI libraries? (I'm sure they exist)
Objective-C: even on iOS/Mac-only projects, I still prefer C++, because it's so much easier to use STL objects than NS data structures.
C++: you can pretty much get it done, and often you can use Qt to get it done quickly and cross-platformy.
Most GUI toolkits for Rust are in their infancy, but I hear that Gnome will be working on integrating Rust with GObject this year, which should allow Rust to leverage Gtk:
> I hear that Gnome will be working on integrating Rust with GObject this year, which should allow Rust to leverage Gtk:
This disappoints me greatly.
The idea of an object hierarchical GUI is not a guaranteed given. It causes things like "primary UI thread" which doesn't need to exist anymore. It is a reflection of a time when memory and CPU was more scarce.
In the face of massively parallel CPU's and huge memory, a tile-based, constraint GUI with publish-subscribe is probably a much better choice. This is especially true with a language that promotes concurrent programming.
I suspect, sadly, that we're simply going to continue down the same broken, single-threaded UI path because of the installed codebases.
I am a Qt/C++ programmer by day and i have been looking at rust and there some bindings to GTK and such, but to me, nothing really comes close to the cross platform-ness of Qt. There seem to be simple QML bindings for Rust too, but thats not really the same.
Lack of a runtime exception model would be one huge thing. So you basically have to check for errors after every operation, and whatever errors you don't check for just... get lost.
