4 ms·

> The second one is actually less true in Rust than it is in Kotlin or C#! In those languages, each file starts with a package declaration, which immediately mo

by brabel 3y ago

> The second one is actually less true in Rust than it is in Kotlin or C#! In those languages, each file starts with a package declaration, which immediately mounts the file at the appropriate place in the semantic model. That's the difference between languages designed to be IDE-friendly and languages designed to have flexible semantics without much concern for making analysis easy. Languages like C++, D, Lisp, Rust are terribly difficult to analyse compared to Java, Kotlin and Dart... and that's no accident. Rust only has good support (not great but ok) in IDEs because it managed to get enough people to muster the huge effort that requires. I've been trying the Kate editor (from the KDE project), for example, and it does a pretty good job of helping with Rust thanks to the Rust Analyzer LSP... all Kate had to do was provide a LSP client for that to work. The situation for D, for example, which has not had the same amount of effort (and due to the difficult to analyze nature of the language) is much worse, unfortunately... that's a big reason for me to prefer Rust over D (others being more libraries and much fewer compiler bugs), despite finding D more fun to write.

globular-toast 3y ago
Interesting that you put Lisp in difficult category despite the IDE experience being in another league compared to any other language I've tried.
- brabel 3y ago
  The IDE experience with Lisp is great because of the interactivity, not because its great analysis. You do get good analysis from the language introspection capabilities itself, but you need to "manually" use that... It's just different. I know SLIME and love it, but the analysis it's capable of doing is not near the level you get with IntelliJ and Java or Kotlin. For starter, Common Lisp (and most other Lisps) don't even have static types (I know you can declare types, but most libs don't do it and SLIME doesn't use that for any IDE feature as far as I know, other than perhaps warn when you use an obviously wrong argument type), making features like advanced refactoring very difficult. Macros make it very hard to even know whether the syntax is right (try writing a LOOP in Common Lisp - SLIME won't help you).
  - trealira 3y ago
    I'm not a Common Lisp expert, but so far, I dislike the LOOP macro specifically because of its complex syntax compared to other Lisp macros and constructs. The DO macro is complex, but I'm pretty sure Emacs will write something like this at the bottom of your screen if you have ElDoc enabled. (I'm not at my computer right now, so this is just me writing from memory). (do ((var init step)...) (condition value) &body) You're right that this isn't as good as actual autocomplete like in IDEs, though.
matklad 3y ago
>because it managed to get enough people to muster the huge effort that requires. Not really true on both counts: - you don't need _that_ many people, if you know what you are doing. For both rust-analyzer and IntelliJ Rust, the headcount was around one-and-a-half people between the first line written and the point where the thing basically works - the "mustering" only came together after the tools have proven themselves to be successful. _Today_ both rust-analyzer and Rust Rover have dedicated teams working on them, but it is a _consequences_ of the fact that these IDEs work great, not a cause. It was a shoestring budget at the beginning! Rust is not the easiest language to build an IDE for, but you really don't need a Google-level of effort for that either. What you do absolutely need though, is an _understanding_ of how to build an IDE, and that's very niche knowledge!
- brabel 3y ago
  A short history of the rust-analyzer can be found here[1]. > The rust-analyzer project was started at the very end of 2017 (first commit). At that time, the existing LSP implementation, RLS, had been providing IDE support for Rust for several years. By 2017, Rust had just basic IDE support with RLS and it was already quite popular. I completely reject your theory that the success of rust-analyzer is due to "the fact these IDEs worked great". It was Rust's success, even while having quite poor tooling, that brought people in to work on improving the tooling (to a point most other languages never reach). > it took surprisingly little effort to get to a prototype which was already useful as an IDE, which happened in Autumn 2018 So, yeah it takes little effort to get a basic IDE... that's where most languages (e.g. D, Nim) stop... the hard part is to get something that's really good. > At that critical point, the company Ferrous Systems (which was newborn itself) stepped in to fund further development of the prototype. So, rust-analyzer was not just a hobby project since at least 2018, when it got sponsored by a business. > By 2020, we realized that what we had built was no longer a prototype, but an already tremendously useful tool for day-to-day Rust programming. It took 2 years of work while sponsored by a real business to get to the point where rust-analyzer was considered "tremendously useful". That's a "huge effort" on my book, not Google-level (and I never said that), but huge nevertheless. And to get to the same level as you get with Java in IntelliJ, for example, you can be sure it'll take about as much effort as was already put into it, maybe more. [1] https://blog.rust-lang.org/2022/02/21/rust-analyzer-joins-rust-org.html https://blog.rust-lang.org/2022/02/21/rust-analyzer-joins-ru...

by brabel 3y ago

globular-toast 3y ago

Interesting that you put Lisp in difficult category despite the IDE experience being in another league compared to any other language I've tried.

brabel 3y ago
The IDE experience with Lisp is great because of the interactivity, not because its great analysis. You do get good analysis from the language introspection capabilities itself, but you need to "manually" use that... It's just different. I know SLIME and love it, but the analysis it's capable of doing is not near the level you get with IntelliJ and Java or Kotlin. For starter, Common Lisp (and most other Lisps) don't even have static types (I know you can declare types, but most libs don't do it and SLIME doesn't use that for any IDE feature as far as I know, other than perhaps warn when you use an obviously wrong argument type), making features like advanced refactoring very difficult. Macros make it very hard to even know whether the syntax is right (try writing a LOOP in Common Lisp - SLIME won't help you).
- trealira 3y ago
  I'm not a Common Lisp expert, but so far, I dislike the LOOP macro specifically because of its complex syntax compared to other Lisp macros and constructs. The DO macro is complex, but I'm pretty sure Emacs will write something like this at the bottom of your screen if you have ElDoc enabled. (I'm not at my computer right now, so this is just me writing from memory). (do ((var init step)...) (condition value) &body) You're right that this isn't as good as actual autocomplete like in IDEs, though.

matklad 3y ago

>because it managed to get enough people to muster the huge effort that requires. Not really true on both counts: - you don't need _that_ many people, if you know what you are doing. For both rust-analyzer and IntelliJ Rust, the headcount was around one-and-a-half people between the first line written and the point where the thing basically works - the "mustering" only came together after the tools have proven themselves to be successful. _Today_ both rust-analyzer and Rust Rover have dedicated teams working on them, but it is a _consequences_ of the fact that these IDEs work great, not a cause. It was a shoestring budget at the beginning! Rust is not the easiest language to build an IDE for, but you really don't need a Google-level of effort for that either. What you do absolutely need though, is an _understanding_ of how to build an IDE, and that's very niche knowledge!

brabel 3y ago
A short history of the rust-analyzer can be found here[1]. > The rust-analyzer project was started at the very end of 2017 (first commit). At that time, the existing LSP implementation, RLS, had been providing IDE support for Rust for several years. By 2017, Rust had just basic IDE support with RLS and it was already quite popular. I completely reject your theory that the success of rust-analyzer is due to "the fact these IDEs worked great". It was Rust's success, even while having quite poor tooling, that brought people in to work on improving the tooling (to a point most other languages never reach). > it took surprisingly little effort to get to a prototype which was already useful as an IDE, which happened in Autumn 2018 So, yeah it takes little effort to get a basic IDE... that's where most languages (e.g. D, Nim) stop... the hard part is to get something that's really good. > At that critical point, the company Ferrous Systems (which was newborn itself) stepped in to fund further development of the prototype. So, rust-analyzer was not just a hobby project since at least 2018, when it got sponsored by a business. > By 2020, we realized that what we had built was no longer a prototype, but an already tremendously useful tool for day-to-day Rust programming. It took 2 years of work while sponsored by a real business to get to the point where rust-analyzer was considered "tremendously useful". That's a "huge effort" on my book, not Google-level (and I never said that), but huge nevertheless. And to get to the same level as you get with Java in IntelliJ, for example, you can be sure it'll take about as much effort as was already put into it, maybe more. [1] https://blog.rust-lang.org/2022/02/21/rust-analyzer-joins-rust-org.html https://blog.rust-lang.org/2022/02/21/rust-analyzer-joins-ru...