It's too early and too immature a language for all the fawning it gets on HN.
I think if the developers do it right they can snag enough mindshare among new developers that Rust will be a serious competitor to C and C++ in 10 years or so. Which is great, because I think it's a better language. But it isn't there yet.
It takes a while.
(I lost interest in Python in early 2000s, and then it got popular. So if I lose interest in Rust it's bound to get popular.)
I'm definitely keeping an eye on it though, because if it keeps going at the same rate it has the potential to be great in 10 years.
But at the same time, flurries of activity aren't universally positive: it becomes harder to filter out the low-quality contributions that introduce subtle bugs, and smaller/more strict teams have an easier time maintaining stringent quality controls.
PHP and JavaScript very rarely segfault either. Sure, they use virtual machines (PHP's is non-JITed too!); and yes, their CPU and memory usage are comparatively astronomical. But I can only hope that Rust's memory-safety doesn't wind up attracting the same kind of unskilled language architecture "contributions" that PHP has, or wind up with an ecosystem as fragmented as Node's.
I agree that it's hard to find people who do systems programming, but those I know have mostly heard of Rust.
There isn't much else of anything happening in that space aside from C++ iterations.
Rust still needs to improve its compile times and IDE related tooling, to make it appelative to the enterprise coder used to the comfort of Java / .NET tooling + C++ for lower level stuff.
As a long time Emacs user, the only way I'd even consider switching off of GNU Emacs would be if there was a port written in Common Lisp that replaced ELisp with Common Lisp. Even then, I'd only switch if it had replacements for the ELisp modules I use (ERC, Slime, C++-mode, etc.).
As an end user, I don't see any advantages in switching to yet another Emacs rewrite in yet another low level language.
Using Common Lisp instead of ELisp would be useful enough that I might switch.
fn Fnumberp(object: LispObject) -> LispObject { if lisp::SYMBOLP(object) { unsafe { Qt } } else { Qnil } }
It uses SYMBOLP instead of NUMBERP. Highlighting the risk of introducing new bugs.
Which leads to the question, why Remacs can't just auto-wrap the lisp::* functions, which I assume are the Rust versions of the C Macros. If you look at Emacs' C code there are a lot of functions and macros that implement Elisp primitives in a C way. E.g., NUMBERP(x) will return 1 if x is a number or else 0. So you can use this function to deal with lisp objects in C code. The function that exports this primitive to elisp is Fnumberp. Rust has a better type system than C and supports meta-programming. So why not have a simple wrapper that can take a (LispObject) -> bool and turn it into a (LispObject) -> LispObject. Similar for other Elisp<->Rust types.
However unless GNU Emacs is willing to accept the Rust replacement code I don't think this will succeed. It is a lot of work and it takes quite some time until it actually pays off. It seems simpler to do what GCC and GDB have done and switch from C to (a strict subset of) C++ to simplify at least some of the more painful C hackeries.
And the reasoning given in the announcement are rather weak:
* "We can leverage the rapidly-growing crate ecosystem." Emacs recently added module support allowing leveraging all kinds of ecosystems
* "We can drop support legacy compilers and platforms (looking at you, MS-DOS)." how is that an opportunity when it effectively removes support for platforms.
Interesting! Where can I read more about this? Is it true that gcc compiles using g++? That's rather amusing. :)
> "We can drop support legacy compilers and platforms (looking at you, MS-DOS)."
> how is that an opportunity when it effectively removes support for platforms.
Supporting MS-DOS is something of a challenge now. I've not done any research but I have vague notions that GCC ports aren't really being maintained anymore. Besides that, many platforms (for example BeOS) are stuck on GCC 2.95.3, a rather famous last version using a particular ABI. A lot of stuff is stuck on that GCC version. (I don't know many details, although I'm very interested to learn more if anyone else has any insight.)
With the above said, I do disagree with wholesale willingness to summarily sweep legacy platforms off the table. Rust has saved itself some maintenance nightmares because it doesn't support DOS, but it means quite a large number of people are still stuck on C for industrial control system tooling. (Granted, I can't deny that I'm talking about a really tiny niche here...)
You can find everything related to GCC's C++ transition here:
https://gcc.gnu.org/wiki/gcc-in-cxx
On Windows even the C runtime, MSVCRT.dll got re-written in C++ and the C functions are actually extern "C" ones.
https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great...
So a kind of small victory for us on the C++ side of the fence on the endless C vs C++ discussions.
Now the joke "my compiler compiles yours" has been reversed.
There are many kinds of success. :-)
Why port Emacs to Rust ?, it adds no value to users. Why not develop a modern GUI like Intellij IDEA with a Common Lisp implementation underneath like SBCL ?
Any person who write their own license to specify in fine details how the work may be used and distributed is going to have a very strong (and likely legal) issue with people who try to circumvent that license. Even a clean room implementation would need source material as instructions, and writing such specification without any copyrighted elements of the source would be quite a challenge when dealing with a very large program that has compatibility to a large ecosystem as its primary feature.
Apple chose FreeBSD as base for it OS, Google chose Linux. Look at sad state of FreeBSD now.
Otherwise, not that I’m aware of. Everyone knows that Elisp is horribly crufty, but getting everyone to shift to a new language requires carrying all the extensions over which is a huge task.
[1]: http://www.wilfred.me.uk/blog/2016/07/30/example-driven-deve...
Practical, however, I have no idea whatsoever about.
I know Rust fans are passionate, but we don't really need "X, but in Rust" for every value of X.
