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]

That depends on whether you think "fewer bugs" is part of a "better solution".

You can't deliver any features in Rust that you can't deliver in any other language, and because it's a young language with limited library support, you will usually have to write more of the code yourself. The compiled code will be fast, but that's true for most compiled languages. Things like polymorphic functions do make it easy to write generalized code, so one might expect good, reusable libraries in the future.

Rust's emphasis is on letting you write predictable programs in a fully compiled, nearly bare metal language, while avoiding common bugs, including concurrency-related bugs. It does that by having a relatively rich type system (with type inference so you don't always have to be explicitly babying the type system in your code), an object ownership system that will statically catch things like use-after-free bugs, by-default immutable values, and by-default memory safety. Things that would blow up a C program in hard to debug ways, or create security holes, or both, are compile time errors in Rust.

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

[mandolin]

Also, the paradigm might discourages people used to classes and such

I believe you're referring specifically to the (non-)support of class inheritance. Rust support for classes in general should be fine.

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

[Anonymous Coward]

Spoken like a true person who has no idea what they're talking about. Seriously, not every language is equal, and some really do try to push the state of the art. But I wouldn't expect Slashdot's peanut gallery to have a clue about any of this. They still seem to think that it's fine as long as their mainstray languages accumulates cruft, because all we need is to grow hypothetical ubermensch who will never shoot a footgun or accidentally abuse language cruft. Far better to keep our buffer overflows and other flaws then dare to investigate better languages that will help even the best programmer write better code. Apparently language design has been a solved problem for years now.

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

[mcolgin]

IMHO, it's more of a matter of MVP and first-to-market. There just hasn't been an emphasis on security, and that costs money and time. It's tough to get QA over releases. You're not wrong, there's certainly bad programmers and languages improvements help to protect buffer-overflows.

Re:Legit Question

[tgv]

Well, that's an eloquent argument. You don't care about memory management and data synchronization? Fine, go ahead, you can build your console based tic-tac-toe game app without it. No problem.

Re:Legit Question

[tgv]

Don't forget data races.

Re:Legit Question

[rodia]

Rust eliminates or mitigates two classes of common problems:

1. - data pointers gone crazy (null pointers, memory violations, "illegal" memory overwriting etc.)
2. - unwanted side effects because of uncontrolled data access from different scopes

It achieves that in a way that doesn't make your program slow or a memory hog, by using

1. - automatic memory management without a garbage collector
2. - data ownership/borrowing
3. - resolving abstractions early (at compile time)

In return, it demands a lot of programming discipline and openness to the new rules that data borrowing imposes on programmers. If you are ready to accept this because you really want correctness and security, then I guess that means that Rust offers you better solutions in a pretty unique way.

Re:Legit Question

[dremon]

Compile-time memory safety and thread safety, modern features (lambdas, closures, traits, generics, functional programming), online database of easy to install 3rd-party modules (crates.io), easy interoperability with C libraries, all this with predictable C-like performance AND without garbage collection. The learning curve is steep though due to ownership and borrowing concepts.

Re:Legit Question

[dremon]

Every piece of software ever written in C/C++ suffers from the same issues over and over again and the absolute majority of the security holes are due to these bugs. May be we NEED the better languages after all rather than keep complaining about better programmers?

Re:Legit Question

[ilsaloving]

This is utter nonsense. Either you can program or you can't.

Now THAT is utter nonsense.

What is your metric for determining whether someone can program or not? There are tons of people who are basically code monkeys. They can program, but the code they produce is absolute crap. They just vomit out code without having the slightest understanding as to what that code is doing underneath.

A great example is, once I saw code from a supposedly 'senior' developer that iterated through a hashmap to find the value he needed.

No language reduces code from, say, 40 lines to 4 lines, just like that. What it's actually doing is abstracting the hard work away from you in the form of a library or whatever. And that's well and good when you understand what is going on. But when a language has all this stuff build into the core of the language, it gives the impression that this knowledge is not important, so when all hell breaks loose, the inexperienced developer is stuck.

It all boils down to structural vs functional knowledge about what you're doing. Someone with functional knowledge could write a routine that writes data to disk, one byte at a time, and not understand why their code runs so slowly. They will likely complain that "the computer is too slow." Meanwhile, a programmer with structural knowledge of how a computer functions, will understand the limits of what an HDD can do, and cache up their writes so that they write an entire block at once.

Re:Legit Question

[K. S. Kyosuke]

No language reduces code from, say, 40 lines to 4 lines, just like that.

Not even APL? ;)

Re:Legit Question

[ilsaloving]

I had to look that one up. Sweet pickled monkey feet. I *suppose* APL counts, since it doesn't seem to have so much 'lines of code' as 'peterbations of the 4th dimension being exposed in 3 dimensional space' :P

Re:Legit Question

[angel'o'sphere]

They can program, but the code they produce is absolute crap.
Then they can't program. (*facepalm*)

Re:'blessed compilers'

[Thiez]

I could see the point of having a compiler in C/C++, but what would be the point of having a bootstrap compiler written in C/C++?

Yeah!

[ooloorie]

Rust is showing itself to be a high-quality, cross platform, high performance language, just like VisualBasic! And its integration via a barely used JSON protocol means that its integration into VisualStudio is not that much worse, really!

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.

Re: The I in IDE makes them all suck

[i.r.id10t]

So basically it is a network connection required version of what javadoc does in various editors...

So. What does a network based API do that a local copy doesn't do? Especially if that local copy can be updated and include the docs for your own stuff?

Of course, the fact that Microsoft and Redhat are working together on this is cool too....

There was a time,

[Anonymous Coward]

back in the day, when a story like this would come up, someone with actual knowledge would say something interesting about it. They would hypothetically have commented on the design of the Rust Language Service, or perhaps the Language Server Protocol. Will it save re-implmenting the wheel for IDEs? Will it help Rust's adoption?

Nope. "duh, c is betr than rusts! u dont need the ideez"

Where did the smart people with a passion for informative discussion of interesting topics go?

Re:'blessed compilers'

[K. S. Kyosuke]

It already is bootstrapped in C++, isn't it? At least the last time I looked, the existing implementation heavily relied on the LLVM framework to do most of the heavy lifting. Whether they'll move on to a Rust-based toolchain remains to be seen.

Re:Smalltalk

[K. S. Kyosuke]

No. Lisp already has those and the other languages can't support those at all.