Rust Implements An IDE Protocol From Red Hat's Collaboration With Microsoft and Codenvy (infoworld.com)

An anonymous reader quotes InfoWorld: Developers of Mozilla's Rust language, devised for fast and safe system-level programming, have unveiled the first release of the Rust Language Service, a project that provides IDEs and editors with live, contextual information about Rust code. RLS is one of the first implementations of the Language Server Protocol, co-developed by Microsoft, Codenvy, and Red Hat to standardize communications between IDEs and language runtimes.

It's another sign of Rust's effort to be an A-list language across the board -- not only by providing better solutions to common programming problems, but also cultivating first-class, cutting-edge tooling support from beyond its ecosystem...
The Rust Language Service is "pre-alpha", and the whole Language Service Protocol is only currently supported by two IDEs -- Eclipse and Microsoft's Visual Studio Code. Earlier InfoWorld described it as "a JSON-based data exchange protocol for providing language services consistently across different code editors and IDEs," and one of the Rust developers has already developed a sample RLS client for Visual Studio Code.

Comments

Legit Question

[PmanAce]

What can you do in Rust better (providing better solutions to common programming problems) than any other language out there?

Re:Legit Question

[Anonymous Coward]

Nothing. It's yet another programming language in an already crowded field.

Re:Legit Question

[Anonymous Coward]

What can you do in Rust better (providing better solutions to common programming problems) than any other language out there?

I believe the only thing that is truly novel about Rust is the facility to compile code with "C-like" performance that cannot have memory violations, and I'm not allowing for research languages that have also achieved this. By "C-like" I mean Rust delivers very fast, compact and memory thrifty programs that start instantly, having no run-time beyond the compiled object and the system itself. By memory violations I mean no use after frees, buffer overflows, double frees, smashed stacks, uninitialized data, data races, etc.; these are all compile time errors in Rust. This is achieved through "ownership," a concept that has previously appeared in research languages, but not in languages with mainstream pretensions.

Beyond that one could argue that Rust pulls a lot of high level abstractions into systems programming; optional types, traits, hygienic macros, well designed iterators, pattern matching, closures, lambda expressions, derivation and more. There is a lot of this in Rust and so programming in Rust does not feel like using a "portable assembler," which is how C/C++ is sometimes characterized. But none of these abstractions are truly novel in an of themselves, they just haven't appeared together as native features of a systems language.

More generally and less tangibly, Rust is the first language with perhaps enough "mind share" to succeed and displace some traditional C-ish systems programming activity. Time will tell, and a lot of time at that. The language is appearing in the real world; Mozilla, Dropbox, Facebook, and others have delivered real work in Rust or will soon. Should this continue and grow Rust will become important, and that would make it the first new "important" systems programming language since the early 70's that isn't some derivative of C.

Re:Legit Question

[cavreader]

It's a pretty accurate statement. We don't need more languages we need better programmers. Bad programming is more to blame for both security and performance problems and not the languages themselves. And some of the bad programming practices we see today is the result of developers jumping from one trendy language to the next while never taking the time to become proficient in any of them.

Re:Legit Question

[angel'o'sphere]

And some of the bad programming practices we see today is the result of developers jumping from one trendy language to the next while never taking the time to become proficient in any of them.
This is utter nonsense. Either you can program or you can't.
And jumping form language to language usually makes you a better programmer as you tend to learn to look at problems from different points of views.

We don't need more languages Of course we do. I rather write 4 lines of code in a new language than 40 line sin C or 400 in assembler.
we need better programmers. No we don't. Most programmers are good enough. We only need _more_ of the good ones. Not better ones.

Re:Legit Question

[tgv]

Don't forget data races.

Re: The I in IDE makes them all suck

[SavedLinuXgeeK]

This is inherently the opposite of what you are saying. The goal of the language services is to provide the same functionality to all ides vs every ide implementing their own solution per language. This also allows for the language owner to be in charge of the quality of the services in the ide.

IDE protocol?

[Yvan256]

And here I thought even SATA was on its way out.