Now that Mozilla has two great projects as Rust language and Photon Desing System, I think it would be interesting if Mozilla creates a new Rust IDE written in Rust (like Eclipse is written in Java and is used to program in Java) and using Photon UI design.
That would be good both for Rust (specially for its adoption, but also would make its specification to grow) and Photon and Mozilla would have total control over it.
3 Likes
Beat me to it!
@Aliuken SolidOak is the only "Rust" IDE. (even if it actually uses NeoVim under the hood, which is a C editor)
Buildin an IDE is a really diffucult task, there are no needs for a new IDE written in Rust yet.
And I find Rust to be growing fast knowing it is only (publicly) 5 years old!
The IntelliJ Rust looks promising. It's built on a stable base (I never had an IntelliJ product crash on me for no reason), updated regularly, but a little slow at times (this comes with features). And you have Vim/NeoVim and Emacs behind for the shear speed too (and it's already stable too).
I am insisting on stable because it is the only that I could see Rust doing for IDEs. But right now, there are no needs for this.
2 Likes
Many people could say that "there are no needs for a new web browser or a new programming language", but that's the way software improves, by creating new software.
ÂżVim/NeoVim and Emacs? I suppose you are joking. That's not comparable to an IDE.
1 Like
New software yes. Re doing what has already been done in 10 different languages, I don't know. Anyway, nothing stops anyone to do another IDE in Rust.
No, I'm not joking. We're talking about Rust here. IDEs don't have a lot more going for them right now.
I still use IntelliJ products whenever I need/want to. They are amazing IDEs and I really like the fact that once you learnd how one works, you can use them all without having to re learn everything.
1 Like
I can see why you would think this, but personally I'd rather have the (limited amount of) Mozilla engineers work on the compiler, crates.io, non-lexical lifetimes, language ergonomics, etc..
(And making the web safer+faster with Servo and Firefox quantum)
There's already a very vibrant Rust IDE ecosystem, with plugins for practically every popular editor, and even some unpopular ones.
Don't get me wrong, I wouldn't mind yet-another-IDE, but I think Mozilla's unique position as Rust's pioneer and sponsor means that there are other things that they can do better than anyone else; things more important than a RIIR-IDE.
6 Likes
I have to make a joke that JetBrains (IDE vendor) are inventing a new programming language though 
8 Likes
Good point!
Of course, this can only mean that JetBrains must now start on a browser! 
I'd joke back that inventing a new language is easy! They even make first year students do it for compiler courses 
Just look at things like whitespace, brainfuck or malbolge, or any other esoteric language
Joking aside, I'd draw the parallel that both companies were so unhappy with the language in which they were writing their primary product, that they had to invent a new language to solve the shortcomings!
I wrote java for a living, and it is so. ver.bose.!
Kotlin++? 
As someone who is effectively developing an Emacs-based IDE for a set of meta languages, please allow me to weigh in.
Emacs is quite a capable piece of software, and I'd go so far as to say that regarding IDE-building fundamentals, almost all of it is there, including being able to syntax highlight whatever you want, based on positions in the code (a seemingly unremarkable feature that can be the difference between having proper syntax highlighting and a hacky version that is based on regexes and thus will never properly work for any recursively nested structure e.g. nested functions in languages that allow that).
There is even a surprisingly mature ELisp debugger (the language Emacs is mostly written in).
The only thing I haven't really found in Emacs so far is infrastructure to support refactoring.
1 Like
Architecturally the biggest problem with Emacs, as I see it, is that it's not really async, and being async is pretty important for IDEs. Even if you parse code incrementally, there will be weird edge cases like an uncolsed quote which require O(size of buffer) processing, and you don't want this stuff to block basic typing.
(a seemingly unremarkable feature that can be the difference between having proper syntax highlighting and a hacky version that is based on regexes and thus will never properly work for any recursively nested structure e.g. nested functions in languages that allow that).
Fun fact: code editors (except IntelliJ based ones, and Emacs for LISPs) just don't parse code, and use regex-based approximations for everything. I don't really understand why
Edit:
except IntelliJ based ones, and Emacs for LISPs
I might be exaggerating here actually. I think QtCreator parses C++ and Eclipse parses Java, but those are language-specific features.
1 Like
Architecturally the biggest problem with Emacs, as I see it, is that it’s not really async, and being async is pretty important for IDEs.
I ran into this issue actually. My thesis solves this issue as a sub-problem, by creating some infrastructure that allows sending messages efficiently into and out of emacs. This infrastructure is based on ZeroMQ, Rust, and multiple threads, and is called Amplify.
I don’t really understand why
I'm thinking that the historical reasons for regex-based syntax highlighting are:
- Doing syntax coloring "correctly" (in the structural sense) requires explicit support from (aside from the editor/IDE) at least the parser (for relatively simple but already powerful syntactic highlighting), and ideally the analysis framework for the language as well i.e. the code that deals in ASTs, e.g. doing control flow analysis, dead code elimination etc. The latter allows for semantic highlighting, which can be much more powerful than syntactic highlighting. So getting this to work in most editors requires either that the editor authors understand some parser theory so they could do that themselves, or they would have to work together with the maintainers of the language they want to support. So historically, for most editors/IDEs, this is/was not really a viable option in practice. In that regard things definitely are better now
- regexes are cheap to use when they're short and simple, e.g.
[A-Za-z_][A-Za-z0-9_]*for identifiers or(-|\+)?[0-9]+for signed integers. They're also straightforward to use, and when you're not doing anything/much with recursively nested structures (I'm looking at 80s tech e.g. C, awk, sed, etc) you might be able to get away with using them. - Because of 1. and 2. the structured approach very likely takes more computational power than the 80/20 approximation that is the regex-based approach. In an era of multicore CPUs and editors that consume gigabytes of memory at a time without even blinking, this principled approach is much more viable than in an era where green on black-ish was an acceptable default theme for a terminal screen.
3 Likes
Where is the Photon UI? Is it on a separate code base or apart of the whole firefox codebase.
It's part of Firefox theoretically, but it has its own github project.
https://github.com/FirefoxUX/photon
1 Like
I would love to do this, as a part of my personal project in process of learning rust!
I may have misunderstood you, but if you mean writing a Rust IDE, then I guarantee you that by the time it is usable by the general public, you won't be a beginner anymore
2 Likes
I was thinking about trying out Emacs but didn't know that.
I began writting Rust code with Vim 7 and syntastic (which is not async) and each time I saved it locked Vim to check for errors. Not a pleasant experience. But I then discovered Vim 8 and Neovim. I now use both for different reasons. With the Ale plugin, it works like a charm with something like the RLS checking for errors behind.
1 Like
It's a bit more than a personal project at this point, but it's also not anything like Google's official editor. I do like the idea of building an IDE well suited for Rust using it. From a brief skim, I'm not convinced that Photon is an ideal UI toolkit for building an editor (or IDE), but I might be persuaded.
6 Likes