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

← Back to Stories (view on slashdot.org)

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

Posted by EditorDavid on Saturday October 22, 2016 @04:34AM from the Mozilla-meets-Microsoft dept.

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.

49 comments

Min score:

Reason:

Sort:

servER by Anonymous Coward · 2016-10-22 04:42 · Score: 0

s/service/server/g
Seriously, could you not be bothered to even finish reading the _title_ of the submitted article before posting about it?
Crap implementation by Anonymous Coward · 2016-10-22 05:07 · Score: 0

The idea is sound, but microsofts implementation and reliance on JSON and the client/server paradigm is just stupid.
Legit Question by PmanAce · 2016-10-22 05:10 · Score: 2

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

--
Tired of my customary (Score:1)
1. Re:Legit Question by Anonymous Coward · 2016-10-22 05:17 · Score: 0
  
  Really really good performance. Also, it takes a lot of concepts from functional programming, that's a good thing against side effects. But, like any language, it has its problems... not enough libraries to compete with... Python, for example. Also, the paradigm might discourages people used to classes and such (I don't consider that a problem, but it's a matter of opinion).
2. Re:Legit Question by Anonymous Coward · 2016-10-22 06:36 · Score: 3, Interesting
  
  Nothing. It's yet another programming language in an already crowded field.
3. Re:Legit Question by Anonymous Coward · 2016-10-22 06:40 · Score: 0, Troll
  
  Spoken like a true cynic who has no idea what they're talking about.
4. Re:Legit Question by Anonymous Coward · 2016-10-22 07:08 · Score: 1
  
  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.
5. Re:Legit Question by Anonymous Coward · 2016-10-22 07:22 · Score: 5, Informative
  
  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.
6. Re:Legit Question by mandolin · 2016-10-22 08:28 · Score: 1
  
  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.
7. Re:Legit Question by Anonymous Coward · 2016-10-22 08:33 · Score: 0
  
  Spoken like at ITT graduate.
8. Re:Legit Question by cavreader · 2016-10-22 08:45 · Score: 4, Insightful
  
  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.
9. Re: Legit Question by Anonymous Coward · 2016-10-22 09:16 · Score: 0
  
  We also need better source code analyzers that can catch these problems. Then even the bad programmers have a chance of releasing safe programs.
10. Re:Legit Question by Anonymous Coward · 2016-10-22 09:31 · Score: 0
  
  For me, it's a C/C++ replacement that is designed specifically to prevent a whole raft of issues: everything from undefined variables and buffer overruns, to race conditions and accidental mutability. Ownership and lifespans aren't something I've really seen in other languages, but they make a huge difference to writing solid, working code - issues that would normally be a run-time problem, become a compile-time error. The compiler itself gives meaningful, helpful error messages by default with the option for even more detail if necessary.
  The syntax is nice too: the power of a "mid-level" systems programming language, but with high-level concepts drawn from functional languages like OCaml. You can be incredibly expressive, dare I say it declarative, without having to make a trade-off for performance. It's proving very popular among dynamic language developers, as well as the original target of C/C++ developers.
  I'm not sure there's one specific killer feature, more a bundle of many different killer features in one collection.
11. Re:Legit Question by Anonymous Coward · 2016-10-22 10:29 · Score: 1
  
  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.
12. Re:Legit Question by angel'o'sphere · 2016-10-22 13:38 · Score: 2
  
  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.
  
  --
  Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
13. Re:Legit Question by mcolgin · 2016-10-22 14:24 · Score: 1
  
  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.
  
  --
  I made this: http://www.bpftpserver.com
14. Re:Legit Question by Anonymous Coward · 2016-10-22 15:59 · Score: 0
  
  Write Rust programs?
15. Re:Legit Question by tgv · 2016-10-22 18:55 · Score: 1
  
  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.
16. Re:Legit Question by tgv · 2016-10-22 18:58 · Score: 2
  
  Don't forget data races.
17. Re:Legit Question by rodia · 2016-10-22 19:52 · Score: 1
  Rust eliminates or mitigates two classes of common problems:
  
  - data pointers gone crazy (null pointers, memory violations, "illegal" memory overwriting etc.)
  
  - 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
  
  - automatic memory management without a garbage collector
  
  - data ownership/borrowing
  
  - 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.
18. Re:Legit Question by Anonymous Coward · 2016-10-22 20:28 · Score: 0
  
  Bad programming is more to blame for both security and performance problems and not the languages themselves.
  I used to think that too, until I had to support a legacy backend written in PHP.
  It's true that bad programming makes it worse, but I wouldn't want to vouch for the security or correctness of even my cleanest PHP code.
  Sure, with some effort I can make it work 99% of the time, but that 1% breaks in unforeseen and unexpected ways (as in: difficult to unit test, for example IO errors).
  Which is usually caused by the core language implementation and its standard libs (as in: undocumented, undefined, platform-dependent behavior).
  Languages like Java are far from perfect, but their inherent strictness and compilation make it much easier to write secure and working code.
  Or as the saying goes: use the right tool for the job...
19. Re:Legit Question by dremon · 2016-10-22 22:18 · Score: 1
  
  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.
20. Re:Legit Question by dremon · 2016-10-22 22:24 · Score: 1
  
  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?
21. Re:Legit Question by Anonymous Coward · 2016-10-24 02:02 · Score: 0
  
  You really don't understand the difference between bad programming and bad programming languages did you .Of course work should continue on improving the languages used to build applications but any extensible and powerful language, no matter how well designed, can not stop programmers from building poor performing and insecure implementations.
22. Re:Legit Question by ilsaloving · 2016-10-24 03:40 · Score: 1
  
  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.
23. Re:Legit Question by K.+S.+Kyosuke · 2016-10-26 13:31 · Score: 1
  
  No language reduces code from, say, 40 lines to 4 lines, just like that.
  Not even APL? ;)
  
  --
  Ezekiel 23:20
24. Re:Legit Question by ilsaloving · 2016-10-27 02:22 · Score: 1
  
  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
25. Re:Legit Question by angel'o'sphere · 2016-11-04 05:48 · Score: 1
  
  They can program, but the code they produce is absolute crap.
  Then they can't program. (*facepalm*)
  
  --
  Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Smalltalk by Anonymous Coward · 2016-10-22 05:22 · Score: 0

Does this mean that other languages will get Smalltalk-style development environments eventually?
1. Re:Smalltalk by K.+S.+Kyosuke · 2016-10-26 13:32 · Score: 1
  
  No. Lisp already has those and the other languages can't support those at all.
  
  --
  Ezekiel 23:20
'blessed compilers' by Anonymous Coward · 2016-10-22 05:31 · Score: 0

For both the software authenticity and IP/DRM crowd.
Unfortunately it is single sourced, self-compiled, and the last alternative language implementation of it was from the early alpha days (0.1x) written in OCAML and incapable of compiling the latest sources (which have gone through at least two major API/ABI changes.)
That said, it does look like a compelling programming language, if at least a bootstrap compiler was written in C/C++, and at least one other language to provide verification, and then enough CPU arches were supported to provide platform independence.
1. Re:'blessed compilers' by Thiez · 2016-10-22 06:07 · Score: 1
  
  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++?
2. Re:'blessed compilers' by K.+S.+Kyosuke · 2016-10-26 13:29 · Score: 1
  
  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.
  
  --
  Ezekiel 23:20
The I in IDE makes them all suck by Anonymous Coward · 2016-10-22 06:00 · Score: 0, Insightful

"Let's build a better text editor!"
"Yes, I bet we can do one that's better than everything else!"
1. Re: The I in IDE makes them all suck by SavedLinuXgeeK · 2016-10-22 07:36 · Score: 2
  
  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.
  
  --
  je suis parce que j'aime
2. Re: The I in IDE makes them all suck by i.r.id10t · 2016-10-22 11:24 · Score: 1
  
  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....
  
  --
  Don't blame me, I voted for Kodos
3. Re: The I in IDE makes them all suck by Anonymous Coward · 2016-10-22 23:17 · Score: 0
  
  So basically it is a network connection required version of what javadoc does in various editors...
  No. It's more like what IntelliSense/Code Completion does. It exposes information that is normally only known by the compiler to the IDE, in a platform independent way. Needed for things like auto completion, finding all implementations of an interface, finding declarations of variables, how to rename a certain variable/class in all files (refactoring), syntax highlighting, etc.
  You can use it locally, if you want, but it has networking capabilities to support online IDEs.
Yeah! by ooloorie · 2016-10-22 06:15 · Score: 1

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!
"IDE Protocol" by Anonymous Coward · 2016-10-22 06:25 · Score: 0

I can only assume this is something like making a GUI in Visual Basic to track an IP address
headline buzzword overload explosion by Anonymous Coward · 2016-10-22 07:36 · Score: 0

so many buzzwords in the headline that my brain couldn't parse it all
IDE protocol? by Yvan256 · 2016-10-22 09:37 · Score: 2

And here I thought even SATA was on its way out.
Just stop by Anonymous Coward · 2016-10-22 10:04 · Score: 0, Funny

Seriously... Stop. Rust is a social justice agenda traipsing about disguised in the dead flesh of a programming language.
It's what all the fat white women with gluten sensitivity on my Facebook feed think software development should be.
So how soon should we expect by Anonymous Coward · 2016-10-22 10:31 · Score: 0

microlinkdredzilla
When.. by Anonymous Coward · 2016-10-22 15:33 · Score: 0

..will they implement the "Rusty Trombone"?
There was a time, by Anonymous Coward · 2016-10-22 18:06 · Score: 1

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?
1. Re:There was a time, by Anonymous Coward · 2016-10-22 20:08 · Score: 0
  
  Where did the smart people with a passion for informative discussion of interesting topics go?
  Maybe Hacker News.
I guess Neil Young was right by Anonymous Coward · 2016-10-22 21:37 · Score: 0

Rust never sleeps.