5 ms·

I wish Rust team invested more into tooling and maybe introduced officially supported IDE because at the end tooling is more important than the language itself.

I wish Rust team invested more into tooling and maybe introduced officially supported IDE because at the end tooling is more important than the language itself. Java is not the best language but it obvious choice for many people because of its IDE integration.

steveklabnik 11y ago
We have been working hard and investing a lot into tooling, it's just not done yet. https://www.rust-lang.org/ides.html https://www.rust-lang.org/ides.html is a rough outline of what's in the pipeline for IDEs specifically.
wyager 11y ago
>tooling is more important than the language itself What makes you say this? Many programmers don't use IDEs or anything.
- DasIch 11y ago
  You don't use any tools for package management, documentation, linting, testing and debugging?
  - untothebreach 11y ago
    I think the conflict here is that, for the "non-IDE" programmer, Rust's tooling is best-of-class (IMO). If your idea of an ideal programming environment is running vim/emacs/sublime/atom and maybe a terminal, Rust's tooling is great. However, some programmers like an IDE more. Which is fine, but for this type of programmer, Rust still has a long way to go. There are some immature plugins for existing IDEs, and even a couple "rust-specific" IDE projects, but nothing near what (say) Java or C# have.
    - tatterdemalion 11y ago
      As a vim user I can attest to this. Rust tooling is better for me than any other language I have ever used. Only thing I ever wish for is a REPL, which is a big ask for a language like Rust.
      - indiv0 11y ago
        While it's not official, rusti[1] by murarth is a functioning Rust REPL. IIRC, it's used to drive the Rust Playground[2] (don't quote me on that). [1]: https://github.com/murarth/rusti https://github.com/murarth/rusti [2]: https://play.rust-lang.org/ https://play.rust-lang.org/
        tatterdemalion 11y ago
        Rusti isn't 'there yet,' unfortunately. It is forced to recompile the entire project for every line entered. Aa far as I know I also can't do things like set 'breakpoints' that will pause execution and drop me into the REPL, like Ruby's binding.pry. This is a very hard feature for compiled languages, its just a con of this execution model (which is has a lot of pros).
        kibwen 11y ago
        I believe the playground is just a well-sandboxed Rust compiler. It doesn't have any of the fancy features of a REPL, such as allowing you to refer to the state of prior runs.
  - kibwen 11y ago
    Rust has tools for package management (Cargo), documentation (rustdoc), linting (clippy), testing (the built-in test runner), and debugging (gdb and lldb integration). It also has tools for code completion (Racer), build orchestration (Cargo again), benchmarking (the built-in benchmark runner), compiler version management (multirust), and automatic source code formatting (rustfmt, though this one's a WIP).
pcwalton 11y ago
We do invest a lot into tooling. There just hasn't been a huge amount of work put into IDE integration yet. There's lots of other types of tooling: Cargo, rustfmt, clippy, Racer, good error messages…
- yazaddaruvala 11y ago
  The only "critical" thing missing from this list would be a rustfix. Sadly, this is probably only worth it once the AST/compiler plugins are stabilized.
  - pcwalton 11y ago
    Well, rustfix is useful when we're breaking code, but we aren't doing that anymore, other than deep soundness fixes in the type system which would be very hard to automate a solution to.
scythe 11y ago
It took a long time for Java IDEs to not suck -- and complex GUI applications aren't exactly the open-source community's strong point. The way forward on that front would require, IMO, some external actor to smell profit in a Rust IDE. That has been sloooowly becoming more likely as the stdlib inches toward stability.
- SneakerXZ 11y ago
  There are new languages with quite nice IDE support e.g. Swift or Kotlin.
  - dikaiosune 11y ago
    Both of those examples are languages designed by IDE vendors, and their real IDE support comes from those vendors (Apple in the case of Swift, JetBrains in the case of Kotlin). It takes a bit longer when you can't just task an existing IDE development team to build your language support :). That said, I think that Rust has made fantastic progress towards IDE integrations so far.
kibwen 11y ago
As others have mentioned, we have lots of tooling that isn't specific to any IDE. For more information about IDE support in Rust, see this page: https://www.rust-lang.org/ides.html https://www.rust-lang.org/ides.html TL;DR: There exist Rust plugins for Eclipse, IntelliJ, Visual Studio, Atom, Emacs, Sublime Text, Vim, and VS Code. We're also working on ways to improve the compiler to better support the IDE use case: https://github.com/rust-lang/rfcs/pull/1317 https://github.com/rust-lang/rfcs/pull/1317
- SneakerXZ 11y ago
  I have followed https://areweideyet.com/ https://areweideyet.com/ and picked Atom and it is far from what I would like. I will try to give another chance to Rust in half year and see if it improved. But I would suggest to look at Swift SourceKit https://github.com/apple/swift/tree/master/tools/SourceKit https://github.com/apple/swift/tree/master/tools/SourceKit or OmniSharp http://www.omnisharp.net/ http://www.omnisharp.net/ SourceKit provides really nice Swift support in Xcode. If you can deliver same thing built on top of VSCode, Intellij IDEA with integrated debugger, I am sold.
  - jhasse 11y ago
    What was missing for you in Atom?
    - SneakerXZ 11y ago
      I would like to see: - Be able to see inferred type - Be able to see documentation for types and methods - Better auto completion was sometimes suggesting non senses and after selecting it placed a cursor on wrong place - Integrated debugger - Go to definition (including Rust std) - Syntax checking - Integrated formatter
      - jhasse 11y ago
        The last three points on your list work in Atom :) > - Be able to see inferred type https://github.com/phildawes/racer/issues/304 https://github.com/phildawes/racer/issues/304 > - Be able to see documentation for types and methods https://github.com/phildawes/racer/issues/415 https://github.com/phildawes/racer/issues/415 > - Better auto completion was sometimes suggesting non senses and after selecting it placed a cursor on wrong place Seems like a bug, never experienced this myself though. > - Integrated debugger I'm currently using nemiver and atom-gdb to set breakpoints from within Atom and launch nemiver. But you're right: A great integrated debugger would be awesome :) > - Go to definition (including Rust std) This works with atom-racer: Ctrl+Shift+P and type "racer find definition" > - Syntax checking https://atom.io/packages/linter-rust https://atom.io/packages/linter-rust > - Integrated formatter https://github.com/rust-lang-nursery/rustfmt/blob/master/atom.md https://github.com/rust-lang-nursery/rustfmt/blob/master/ato...
dragonwriter 11y ago
> I wish Rust team invested more into tooling Among similarly new language, I think the strength of the tooling is one of the notable positives of Rust. > and maybe introduced officially supported IDE While I get that some programmers prefer IDEs and that IDEs might actually be generally preferable for some Rust use cases, I think there is a lot more utility in the Rust team focusing on lower-level tooling (which IDE and enhanced-editor-plugin developers can leverage) rather than focusing on an officially supported IDE.
- alkonaut 11y ago
  > I think there is a lot more utility in the Rust team focusing on lower-level tooling Agreed, I hope that a good "Language service" API is on the horizon, so that tool authors don't need to reinvent the wheel in order to support parsing, error display, highlighting, completions and so on. A step in the right direction is the possibility of getting machine-readable (json) error messages from the compiler. Being able to just call the compiler as a library to produce AST's from source would be very handy, though it would probably complicate the compiler to be able to provide useful output from broken/incomplete source, which is critical for tool use.
  - GolDDranks 11y ago
    That'd be great to have and I think we'll see one in the future. No idea about the timeframe though.
    - alkonaut 11y ago
      It's being worked on, but it will be a bumpy road if the compiler simultaneously is going to be made more incremental. https://github.com/rust-lang/rfcs/pull/1317 https://github.com/rust-lang/rfcs/pull/1317 Nim does a good job with their IDE support http://nim-lang.org/docs/idetools.html http://nim-lang.org/docs/idetools.html
ufo 11y ago
I'm not sure Javas is a bood benchmark to compare a young language against when it comes to IDE support... That said, in my brief experience with rust I got the impression that their tooling is very high quality for something so new. Have you seen how pretty their compiler error messages are, for example?
agentgt 11y ago
Speaking from someone who uses Java everyday and has built a company that mainly uses Java I can tell you the Java tooling is fairly irritating (and I like Java). Java doesn't have really good canonical tools that ship with the JDK nor is there a necessarily an industry preferred choice (Javadoc is probably the only exception). This of course includes more than just build tools. The fragmentation is huge. For example Java doesn't have a defined format tool like gofmt or rustfmt nor does it have a preferred build/dep system like crate (there are several ... maven, gradle, ant). Even more annoying is that unlike code completion and refactoring tools (Rust racer) for Java are tightly coupled with the IDE and there are really only two choices: morbidly obese and broke: Eclipse or trust fund expensive but works: intellij. With Racer you can use whatever editor or IDE you like. I wish I had something like that for Java.
- snuxoll 11y ago
  > trust fund expensive but works: intellij. I think calling IntelliJ "trust fund" expensive is rather extreme. My company pays substantially more for my Visual Studio license than I do for my personal JetBrains All-Products subscription, $150/yr (which breaks down to $12.50/mo) saves me far more than 5 hours of time between all the work I do in IntelliJ, DataGrip, PyCharm, WebStorm and soon Rider (7 seconds to open a solution that takes Visual Studio 30 seconds to load and without the constant lockups - now I just need it to be able to run/debug ASP.net apps and run NUnit tests).
  - agentgt 11y ago
    Yes I was sort of exaggerating because it is the main complaint that people have of intellij. We too use intellij as well jrebel and these tools pay for themselves fairly quickly.
  - sitkack 11y ago
    IntelliJ is free as in beer and speech (Apache Licensed) for the Community Edition.
gnuvince 11y ago
> maybe introduced officially supported IDE I would much rather they don't do that and instead offer tools that can answer IDE-like queries (e.g. "Who calls this function?", "Where is this identifier defined?", etc.) and let people integrate that into Emacs, Vim, Atom, and other editors and IDEs. This brings all the communities together and doesn't dictate one particular tool over all others.
- 0xFFC 11y ago
  They have : https://www.rust-lang.org/ides.html https://www.rust-lang.org/ides.html >We propose a new tool, an 'oracle' which takes input from the compiler, maintains a project-wide view of the code and it's type information, and provides data about the project to IDEs and other tools. The oracle is a long-running daemon and presents an API via IPC. Which is great idea. But it is not implemented yet (AFAIK). personal opinion : Rust with this pace, will be absolutely one of the best language in term of usage/tools in next 5 year.
- airplane 11y ago
  Similar to that, I really like how in Intellij I can can use my Maven and Gradle build script as the IDE project's property file. I can now have my source checkout not include any helpful IDE specific files, but still have the project be instantly imported into an IDE.
cballard 11y ago
This is true. I tried to do something with Piston, but I couldn't figure out what the type of anything should be, because I could inspect functions to see what their parameter and return types were. I could follow examples, but they tended to use inline functions, which don't need to specify types. In Swift you can just Cmd+Click to do this (assuming SourceKit hasn't crashed) and it's very useful for that kind of exploration.

steveklabnik 11y ago

We have been working hard and investing a lot into tooling, it's just not done yet. https://www.rust-lang.org/ides.html https://www.rust-lang.org/ides.html is a rough outline of what's in the pipeline for IDEs specifically.

wyager 11y ago

>tooling is more important than the language itself What makes you say this? Many programmers don't use IDEs or anything.

DasIch 11y ago
You don't use any tools for package management, documentation, linting, testing and debugging?
- untothebreach 11y ago
  I think the conflict here is that, for the "non-IDE" programmer, Rust's tooling is best-of-class (IMO). If your idea of an ideal programming environment is running vim/emacs/sublime/atom and maybe a terminal, Rust's tooling is great. However, some programmers like an IDE more. Which is fine, but for this type of programmer, Rust still has a long way to go. There are some immature plugins for existing IDEs, and even a couple "rust-specific" IDE projects, but nothing near what (say) Java or C# have.
  - tatterdemalion 11y ago
    As a vim user I can attest to this. Rust tooling is better for me than any other language I have ever used. Only thing I ever wish for is a REPL, which is a big ask for a language like Rust.
    - indiv0 11y ago
      While it's not official, rusti[1] by murarth is a functioning Rust REPL. IIRC, it's used to drive the Rust Playground[2] (don't quote me on that). [1]: https://github.com/murarth/rusti https://github.com/murarth/rusti [2]: https://play.rust-lang.org/ https://play.rust-lang.org/
      - tatterdemalion 11y ago
        Rusti isn't 'there yet,' unfortunately. It is forced to recompile the entire project for every line entered. Aa far as I know I also can't do things like set 'breakpoints' that will pause execution and drop me into the REPL, like Ruby's binding.pry. This is a very hard feature for compiled languages, its just a con of this execution model (which is has a lot of pros).
      - kibwen 11y ago
        I believe the playground is just a well-sandboxed Rust compiler. It doesn't have any of the fancy features of a REPL, such as allowing you to refer to the state of prior runs.
- kibwen 11y ago
  Rust has tools for package management (Cargo), documentation (rustdoc), linting (clippy), testing (the built-in test runner), and debugging (gdb and lldb integration). It also has tools for code completion (Racer), build orchestration (Cargo again), benchmarking (the built-in benchmark runner), compiler version management (multirust), and automatic source code formatting (rustfmt, though this one's a WIP).

pcwalton 11y ago

We do invest a lot into tooling. There just hasn't been a huge amount of work put into IDE integration yet. There's lots of other types of tooling: Cargo, rustfmt, clippy, Racer, good error messages…

yazaddaruvala 11y ago
The only "critical" thing missing from this list would be a rustfix. Sadly, this is probably only worth it once the AST/compiler plugins are stabilized.
- pcwalton 11y ago
  Well, rustfix is useful when we're breaking code, but we aren't doing that anymore, other than deep soundness fixes in the type system which would be very hard to automate a solution to.

scythe 11y ago

It took a long time for Java IDEs to not suck -- and complex GUI applications aren't exactly the open-source community's strong point. The way forward on that front would require, IMO, some external actor to smell profit in a Rust IDE. That has been sloooowly becoming more likely as the stdlib inches toward stability.

SneakerXZ 11y ago
There are new languages with quite nice IDE support e.g. Swift or Kotlin.
- dikaiosune 11y ago
  Both of those examples are languages designed by IDE vendors, and their real IDE support comes from those vendors (Apple in the case of Swift, JetBrains in the case of Kotlin). It takes a bit longer when you can't just task an existing IDE development team to build your language support :). That said, I think that Rust has made fantastic progress towards IDE integrations so far.

kibwen 11y ago

As others have mentioned, we have lots of tooling that isn't specific to any IDE. For more information about IDE support in Rust, see this page: https://www.rust-lang.org/ides.html https://www.rust-lang.org/ides.html TL;DR: There exist Rust plugins for Eclipse, IntelliJ, Visual Studio, Atom, Emacs, Sublime Text, Vim, and VS Code. We're also working on ways to improve the compiler to better support the IDE use case: https://github.com/rust-lang/rfcs/pull/1317 https://github.com/rust-lang/rfcs/pull/1317

SneakerXZ 11y ago
I have followed https://areweideyet.com/ https://areweideyet.com/ and picked Atom and it is far from what I would like. I will try to give another chance to Rust in half year and see if it improved. But I would suggest to look at Swift SourceKit https://github.com/apple/swift/tree/master/tools/SourceKit https://github.com/apple/swift/tree/master/tools/SourceKit or OmniSharp http://www.omnisharp.net/ http://www.omnisharp.net/ SourceKit provides really nice Swift support in Xcode. If you can deliver same thing built on top of VSCode, Intellij IDEA with integrated debugger, I am sold.
- jhasse 11y ago
  What was missing for you in Atom?
  - SneakerXZ 11y ago
    I would like to see: - Be able to see inferred type - Be able to see documentation for types and methods - Better auto completion was sometimes suggesting non senses and after selecting it placed a cursor on wrong place - Integrated debugger - Go to definition (including Rust std) - Syntax checking - Integrated formatter
    - jhasse 11y ago
      The last three points on your list work in Atom :) > - Be able to see inferred type https://github.com/phildawes/racer/issues/304 https://github.com/phildawes/racer/issues/304 > - Be able to see documentation for types and methods https://github.com/phildawes/racer/issues/415 https://github.com/phildawes/racer/issues/415 > - Better auto completion was sometimes suggesting non senses and after selecting it placed a cursor on wrong place Seems like a bug, never experienced this myself though. > - Integrated debugger I'm currently using nemiver and atom-gdb to set breakpoints from within Atom and launch nemiver. But you're right: A great integrated debugger would be awesome :) > - Go to definition (including Rust std) This works with atom-racer: Ctrl+Shift+P and type "racer find definition" > - Syntax checking https://atom.io/packages/linter-rust https://atom.io/packages/linter-rust > - Integrated formatter https://github.com/rust-lang-nursery/rustfmt/blob/master/atom.md https://github.com/rust-lang-nursery/rustfmt/blob/master/ato...

dragonwriter 11y ago

> I wish Rust team invested more into tooling Among similarly new language, I think the strength of the tooling is one of the notable positives of Rust. > and maybe introduced officially supported IDE While I get that some programmers prefer IDEs and that IDEs might actually be generally preferable for some Rust use cases, I think there is a lot more utility in the Rust team focusing on lower-level tooling (which IDE and enhanced-editor-plugin developers can leverage) rather than focusing on an officially supported IDE.

alkonaut 11y ago
> I think there is a lot more utility in the Rust team focusing on lower-level tooling Agreed, I hope that a good "Language service" API is on the horizon, so that tool authors don't need to reinvent the wheel in order to support parsing, error display, highlighting, completions and so on. A step in the right direction is the possibility of getting machine-readable (json) error messages from the compiler. Being able to just call the compiler as a library to produce AST's from source would be very handy, though it would probably complicate the compiler to be able to provide useful output from broken/incomplete source, which is critical for tool use.
- GolDDranks 11y ago
  That'd be great to have and I think we'll see one in the future. No idea about the timeframe though.
  - alkonaut 11y ago
    It's being worked on, but it will be a bumpy road if the compiler simultaneously is going to be made more incremental. https://github.com/rust-lang/rfcs/pull/1317 https://github.com/rust-lang/rfcs/pull/1317 Nim does a good job with their IDE support http://nim-lang.org/docs/idetools.html http://nim-lang.org/docs/idetools.html

ufo 11y ago

I'm not sure Javas is a bood benchmark to compare a young language against when it comes to IDE support... That said, in my brief experience with rust I got the impression that their tooling is very high quality for something so new. Have you seen how pretty their compiler error messages are, for example?

agentgt 11y ago

Speaking from someone who uses Java everyday and has built a company that mainly uses Java I can tell you the Java tooling is fairly irritating (and I like Java). Java doesn't have really good canonical tools that ship with the JDK nor is there a necessarily an industry preferred choice (Javadoc is probably the only exception). This of course includes more than just build tools. The fragmentation is huge. For example Java doesn't have a defined format tool like gofmt or rustfmt nor does it have a preferred build/dep system like crate (there are several ... maven, gradle, ant). Even more annoying is that unlike code completion and refactoring tools (Rust racer) for Java are tightly coupled with the IDE and there are really only two choices: morbidly obese and broke: Eclipse or trust fund expensive but works: intellij. With Racer you can use whatever editor or IDE you like. I wish I had something like that for Java.

snuxoll 11y ago
> trust fund expensive but works: intellij. I think calling IntelliJ "trust fund" expensive is rather extreme. My company pays substantially more for my Visual Studio license than I do for my personal JetBrains All-Products subscription, $150/yr (which breaks down to $12.50/mo) saves me far more than 5 hours of time between all the work I do in IntelliJ, DataGrip, PyCharm, WebStorm and soon Rider (7 seconds to open a solution that takes Visual Studio 30 seconds to load and without the constant lockups - now I just need it to be able to run/debug ASP.net apps and run NUnit tests).
- agentgt 11y ago
  Yes I was sort of exaggerating because it is the main complaint that people have of intellij. We too use intellij as well jrebel and these tools pay for themselves fairly quickly.
- sitkack 11y ago
  IntelliJ is free as in beer and speech (Apache Licensed) for the Community Edition.

gnuvince 11y ago

> maybe introduced officially supported IDE I would much rather they don't do that and instead offer tools that can answer IDE-like queries (e.g. "Who calls this function?", "Where is this identifier defined?", etc.) and let people integrate that into Emacs, Vim, Atom, and other editors and IDEs. This brings all the communities together and doesn't dictate one particular tool over all others.

0xFFC 11y ago
They have : https://www.rust-lang.org/ides.html https://www.rust-lang.org/ides.html >We propose a new tool, an 'oracle' which takes input from the compiler, maintains a project-wide view of the code and it's type information, and provides data about the project to IDEs and other tools. The oracle is a long-running daemon and presents an API via IPC. Which is great idea. But it is not implemented yet (AFAIK). personal opinion : Rust with this pace, will be absolutely one of the best language in term of usage/tools in next 5 year.
airplane 11y ago
Similar to that, I really like how in Intellij I can can use my Maven and Gradle build script as the IDE project's property file. I can now have my source checkout not include any helpful IDE specific files, but still have the project be instantly imported into an IDE.

cballard 11y ago

This is true. I tried to do something with Piston, but I couldn't figure out what the type of anything should be, because I could inspect functions to see what their parameter and return types were. I could follow examples, but they tended to use inline functions, which don't need to specify types. In Swift you can just Cmd+Click to do this (assuming SourceKit hasn't crashed) and it's very useful for that kind of exploration.