Slashdot Mirror
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.
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.
"Let's build a better text editor!"
"Yes, I bet we can do one that's better than everything else!"
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.