4 ms·

10 years and still an okish IDE experience… This is going to stay with Rust. The problem is not the tooling, but the language.

selfmodruntime 4y ago
I am unsure what you mean. Care to elaborate?
- conaclos 4y ago
  See my other answer [1] to get more context :) [1] https://news.ycombinator.com/item?id=33729406 https://news.ycombinator.com/item?id=33729406
- TheCycoONE 4y ago
  I think I followed. One aspect of a programming language is how easy it is to build a useful IDE for with code prediction, navigation, refactoring, etc. Java is relatively easy, Lua is very hard. Rust is somewhere in the middle, with macros being a complicating factor. https://rust-analyzer.github.io/blog/2021/11/21/ides-and-macros.html https://rust-analyzer.github.io/blog/2021/11/21/ides-and-mac... discusses the problems specific to rust much better than I could.
  - bitexploder 4y ago
    Go has one of the best compiled language IDE experiences out there. GoLand makes it feel easier than Python code :)
    - zaphirplane 4y ago
      Can it find all Implementations of an interface or what interfaces this implements ?
      - bitexploder 4y ago
        Yes to both. It is great :)
- mvhvv 4y ago
  I'm unsure exactly what the above poster is trying to say, I generally find Rust development very pleasant with nothing but vscode and Rust-analyzer. But... I'll admit there is one major stumbling block so far. Debugging iterator chains can be cumbersome because of the disconnect between the language and the compiled code. I've found myself stepping in and out of assembly more than I'd like. I assume this is the kind of problem that can be overcome with a nicer debugger though.
  - still_grokking 4y ago
    > I assume this is the kind of problem that can be overcome with a nicer debugger though. I think this would be something that modern debuggers need to solve somehow in general. There are more and more languages with high amount of syntax sugar, where the output to be debugged doesn't have much in common anymore with the code written. Debuggers need to be aware of desugarings somehow. But it makes no sense to implement this on a case by case basis for every language. We need next generation debuggers! (But I have no clue how "a sugar aware debugger" could be implemented; something in the direction of "source maps" maybe?)
still_grokking 4y ago
I don't get what you mean. There are languages out there with much more advanced features than Rust, like e.g. Scala. But the IDE experience in Scala is not worse than with Java. There is no fundamental problem with IDE support. It just takes some work with an advanced language. (The only issue are languages which you need to write "backwards", like Haskell. But that's another story.)
- conaclos 4y ago
  I am talking about compilation speed. I recently started working with Rust for contributing to projects like Rome/tools [1] and deno_lint [2]. My first impression with Rust is a bit frustrating: compilation takes tens of seconds or minutes. I am waiting in front of my IDE to get type hints / go-to def (often to fall-back to a text search). When I am launching unit tests, I am waiting that rust-analyzer terminates its indexing, and then I am waiting again that the tests compile… The tools are now mature, and a lot of engineering work is done on both rust compiler and rust-analyzer. I am afraid that the slow compilation of Rust is rooted to its inherent complexity. [1] https://github.com/rome/tools https://github.com/rome/tools [2] https://github.com/denoland/deno_lint https://github.com/denoland/deno_lint
  - still_grokking 4y ago
    > I am afraid that the slow compilation of Rust is rooted to its inherent complexity. AFAIK that's not the case. The problem here is that Rust has "issues" with separate compilation due to some language design decisions (which affect incremental compilation than obviously). It's not built for that and it is, and continuously will be, quite difficult to make this work somehow. But that's less a problem with the complexity of the language as such. My Scala example stands: Scala is also quite complex and not the fastest to compile. But after the build system and the compiler crunched the sources once (which may take many minutes on a larger code base) the IDE is very responsive. Things like type hints or go-to def are more or less instant. Code completion is fast enough to be used fluently. Edit-compile-test cycles are fast thanks to the fact that separate compilation considerations were part of the language design decisions. (That's for example why Scala has orphan type-class instances; which are a feature and a wart at the same time). As I understand Rust's "compilation units" are actually crates. This is not very fine granular and I guess the source of the issues. I would guess splitting code into a few (more) crates (which than need to depend on each other) may improve the incremental build times. Also things like not building optimized code during development of course apply, but I think cargo does this automatically anyway. But I'm not an expert on this. Would need to look things up myself. Maybe someone else has some proven tricks to share? … OK, a quick search yielded some useful results, so I share: https://www.pingcap.com/blog/rust-huge-compilation-units/ https://www.pingcap.com/blog/rust-huge-compilation-units/ https://fasterthanli.me/articles/why-is-my-rust-build-so-slow https://fasterthanli.me/articles/why-is-my-rust-build-so-slo... https://news.ycombinator.com/item?id=29742694 https://news.ycombinator.com/item?id=29742694

selfmodruntime 4y ago

I am unsure what you mean. Care to elaborate?

conaclos 4y ago
See my other answer [1] to get more context :) [1] https://news.ycombinator.com/item?id=33729406 https://news.ycombinator.com/item?id=33729406
TheCycoONE 4y ago
I think I followed. One aspect of a programming language is how easy it is to build a useful IDE for with code prediction, navigation, refactoring, etc. Java is relatively easy, Lua is very hard. Rust is somewhere in the middle, with macros being a complicating factor. https://rust-analyzer.github.io/blog/2021/11/21/ides-and-macros.html https://rust-analyzer.github.io/blog/2021/11/21/ides-and-mac... discusses the problems specific to rust much better than I could.
- bitexploder 4y ago
  Go has one of the best compiled language IDE experiences out there. GoLand makes it feel easier than Python code :)
  - zaphirplane 4y ago
    Can it find all Implementations of an interface or what interfaces this implements ?
    - bitexploder 4y ago
      Yes to both. It is great :)
mvhvv 4y ago
I'm unsure exactly what the above poster is trying to say, I generally find Rust development very pleasant with nothing but vscode and Rust-analyzer. But... I'll admit there is one major stumbling block so far. Debugging iterator chains can be cumbersome because of the disconnect between the language and the compiled code. I've found myself stepping in and out of assembly more than I'd like. I assume this is the kind of problem that can be overcome with a nicer debugger though.
- still_grokking 4y ago
  > I assume this is the kind of problem that can be overcome with a nicer debugger though. I think this would be something that modern debuggers need to solve somehow in general. There are more and more languages with high amount of syntax sugar, where the output to be debugged doesn't have much in common anymore with the code written. Debuggers need to be aware of desugarings somehow. But it makes no sense to implement this on a case by case basis for every language. We need next generation debuggers! (But I have no clue how "a sugar aware debugger" could be implemented; something in the direction of "source maps" maybe?)

still_grokking 4y ago

I don't get what you mean. There are languages out there with much more advanced features than Rust, like e.g. Scala. But the IDE experience in Scala is not worse than with Java. There is no fundamental problem with IDE support. It just takes some work with an advanced language. (The only issue are languages which you need to write "backwards", like Haskell. But that's another story.)

conaclos 4y ago
I am talking about compilation speed. I recently started working with Rust for contributing to projects like Rome/tools [1] and deno_lint [2]. My first impression with Rust is a bit frustrating: compilation takes tens of seconds or minutes. I am waiting in front of my IDE to get type hints / go-to def (often to fall-back to a text search). When I am launching unit tests, I am waiting that rust-analyzer terminates its indexing, and then I am waiting again that the tests compile… The tools are now mature, and a lot of engineering work is done on both rust compiler and rust-analyzer. I am afraid that the slow compilation of Rust is rooted to its inherent complexity. [1] https://github.com/rome/tools https://github.com/rome/tools [2] https://github.com/denoland/deno_lint https://github.com/denoland/deno_lint
- still_grokking 4y ago
  > I am afraid that the slow compilation of Rust is rooted to its inherent complexity. AFAIK that's not the case. The problem here is that Rust has "issues" with separate compilation due to some language design decisions (which affect incremental compilation than obviously). It's not built for that and it is, and continuously will be, quite difficult to make this work somehow. But that's less a problem with the complexity of the language as such. My Scala example stands: Scala is also quite complex and not the fastest to compile. But after the build system and the compiler crunched the sources once (which may take many minutes on a larger code base) the IDE is very responsive. Things like type hints or go-to def are more or less instant. Code completion is fast enough to be used fluently. Edit-compile-test cycles are fast thanks to the fact that separate compilation considerations were part of the language design decisions. (That's for example why Scala has orphan type-class instances; which are a feature and a wart at the same time). As I understand Rust's "compilation units" are actually crates. This is not very fine granular and I guess the source of the issues. I would guess splitting code into a few (more) crates (which than need to depend on each other) may improve the incremental build times. Also things like not building optimized code during development of course apply, but I think cargo does this automatically anyway. But I'm not an expert on this. Would need to look things up myself. Maybe someone else has some proven tricks to share? … OK, a quick search yielded some useful results, so I share: https://www.pingcap.com/blog/rust-huge-compilation-units/ https://www.pingcap.com/blog/rust-huge-compilation-units/ https://fasterthanli.me/articles/why-is-my-rust-build-so-slow https://fasterthanli.me/articles/why-is-my-rust-build-so-slo... https://news.ycombinator.com/item?id=29742694 https://news.ycombinator.com/item?id=29742694