this post was submitted on 03 Oct 2023
26 points (86.1% liked)

Programming

17460 readers
132 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 1 year ago
MODERATORS
snowe
Ategon
[email protected]
26
Best free (preferably FOSS) Rust IDE for MacOS (lemmy.world)
submitted 1 year ago by [email protected] to c/programming
34 comments fedilink hide all child comments
 

I think I'm going to start learning Rust. Can anyone suggest a good IDE to use?

all 35 comments
sorted by: hot top controversial new old
[–] dukk 19 points 1 year ago (1 children)

rust-analyzer is a pretty good LSP, and works in most modern text editors.

My advice? Just pick an editor and stick to it.

VSCode? Sure.

Jetbrains? Good choice.

Hell, Emacs? Why not?

I personally use Neovim, and it just works. No matter what I’m programming in, I’m still at home.

Just pick an editor that works for you. I’d suggest VSCode. Use VSCodium for a true FOSS experience, or Helix for a beginner friendly terminal editor.

If you really just want something Rust-focused, there’s RustRover from Jetbrains, but that’s about it.

[–] [email protected] 10 points 1 year ago

helix

[–] johnhattan 9 points 1 year ago (1 children)

Vscode works well on Mac, and it has good Rust support.

[–] [email protected] 4 points 1 year ago

Just wanted to point that rust-analyzer is the fantastic language server that powers the language support, and it runs in a lot of editors (VS Code, Emacs, Neovim, ...)

[–] [email protected] 8 points 1 year ago* (last edited 1 year ago) (1 children)

There's not going to be a rust-specific FOSS editor AFAIK (nothing like RustRover from JetBrains). However the Rust extensions are first-class experience on VS Codium, Neovim, Emacs, etc.

More importantly, unlike Java, C#, Kotlin, C++, or Python Rust doesn't benefit all that much from a language-specific IDE. There's no bulky management of a virtual environment, no make files, no maven, etc. Just a human-readable cargo.toml for your packages, an install command, and a build+run command.

[–] lysdexic 4 points 1 year ago (2 children)

There’s no bulky management of a virtual environment, no make files, no maven, etc. Just a human-readable cargo.toml for your packages

In your perspective, what's the difference between a cargo.toml and a requirements.txt, packages.json, pom.xml, etc? Is there any?

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

To get to your core point; I agree python without a virtual env, just raw python, is definintely not bulky. I'd argue its much more lightweight than cargo. My comment was because sounds like OP could be new-ish to programming, and, for a number of projects (ex; Android development), going from a big IDE to just a plaintext editor + command line commands can be a really painful jump. I remeber a Java course having a series of IDE tutorials and I could not for the life of me figure out the plaintext+commandline equivlent. The same can happen for certain python projects if a tutorial expects the editor to set the PYTHONPATH and the project has a venv, and the tutorial expects the editor's terminals start already-inside python virtual environment. That kind of stuff can make 'python without an IDE" confusing and daunting to someone merely following PyCharm tutorials.

I just wanted to assure OP they likely wouldn't have that kind of experince with Rust. AFAIK Rust tutorials rarely (if ever) assume an IDE.

Being not-bulky isn't a rust specific thing, a half-decent package manager meets the qualitification, but OP was asking about Rust and might not know.

[–] thesmokingman 1 points 1 year ago (1 children)

Vanilla cargo.toml files are more akin to a requirements.txt than any of the others, which allow you to do things like set variables or create run scripts. However, vanilla cargo.toml files have some minimal Make functionality so it’s a bit more than just project dependencies. Each of those ecosystems has a slightly different approach to handling build tooling and dependency management. Rust puts the basic build and dependencies in one file with the assumption your system has the right Rust version, which is a lot simpler than others.

[–] lysdexic 3 points 1 year ago (2 children)

So there is fundamentally no difference between cargo and any other contemporary dependency/package manager.

[–] [email protected] 3 points 1 year ago (1 children)

Also, it's worth noting that cargo is a fairly good package manager all things considered. It has a native lock file format, unlike requirements.txt. Running code that's built with cargo typically just works with cargo build. No futzing around with special build commands for your specific build tooling like in js. I can't speak for maven since I've only used it a little bit and never used it enough to be comfortable with it... but cargo just doesn't really have many major paper cuts.

Admittedly, cargo isn't really special - it's just a classic package manager that learned from the hindsight of its predecessors. It's all minor improvements if any. There's actually innovative build tooling out there: things like buck2, nix, etc. But those are an entirely different ball game.

[–] lysdexic 0 points 1 year ago (1 children)

Also, it’s worth noting that cargo is a fairly good package manager all things considered.

Yes, I'm familiar with Cargo. My point was to point out the absurdity and silliness of OP's remarks on "no bulky management of a virtual environment, no make files, no maven, etc." Once Rust fundamentalista take off their rose-tinted glasses, it's clear that Cargo is just as good (or as bad) as any contemporary integrated build system.

[–] [email protected] 1 points 1 year ago (1 children)

While part of me agrees, I will say most ecosystems have some glaring flaws in them. Python's lack of lock files in particular is something that annoys me to no end. Having to use poetry, pipenv, or whatever else people are using now to get around it sucks. Python's lack of being able to use multiple versions of the same library is also a thing... but not something I've found issues with personally.

I'm not going to say cargo is some mind blowing system cause I really don't think it's innovative, at all - but I do think it's far better than most ecosystems just due to benefits of hindsight. Having an opinionated, simple build system that does all the right things out of the box is valuable, and I can't think of any mainstream language that really hits that mark otherwise.

[–] [email protected] 1 points 1 year ago

and I can't think of any mainstream language that really hits that mark otherwise.

Go

[–] dukk 2 points 1 year ago

Well, it is standard.

That’s probably the biggest thing to consider: you use Rust, you use Cargo. It’s unanimous.

It’s built right into the language ecosystem, so there’s no divide, and everything’s just easily available to you.

[–] starman 7 points 1 year ago (1 children)

Not technically IDEs, but you can try Helix or Lapce, both written in rust.

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago) (1 children)

I love Lapce, but it is not what I'd call a Rust IDE. It's a beta/alpha general text editor with some initial extensions for Rust.

Not really a great place to start learning Rust

[–] dukk 1 points 1 year ago

I think both of these are just editors written in Rust.

[–] [email protected] 4 points 1 year ago

Doom Emacs with lsp and rust-analyzer

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago)

Definitely VSCode (or one of the many forks).

I also recommend combining it with Docker, the Remote Development extension, and Dev Containers, to keep your dev environment isolated from the rest of your operating system. That way you'll be able to easily install things you're not sure if you want to use, and cleanly rollback/remove them.

It'll also make life easier when (not if) you need to move your dev setup to another computer. Possibly even a completely different operating system.

[–] [email protected] 3 points 1 year ago (3 children)

VIM + plugins

[–] [email protected] 6 points 1 year ago (2 children)

I have to admit that while I'm old enough to remember VIM from days of yore, I never found the love that everyone had/has for it. Is it really as good as modern IDE's?

[–] [email protected] 4 points 1 year ago

Yes. Though neovim has stolen the limelight really. YCM or ALE with vim, ctrl+p plugins, nerdtree, lightline and you basically have an IDE

[–] [email protected] 1 points 1 year ago

If you're going the vim route I'd go with NeoVim. The lua support for plugins has resulted in some really great IDE-like plugins. That being said, I still prefer VScode with vim mode.

There's actually a cool plugin for VSCode that lets you bridge NeoVim into it if you want the best of both worlds

[–] [email protected] 4 points 1 year ago (1 children)

its always an option.

[–] [email protected] 7 points 1 year ago (1 children)

VIM is more than an option. It transcends languages, frameworks, paradigms. Vim will always be there for you

[–] [email protected] 4 points 1 year ago

hail VIM!

[–] [email protected] 4 points 1 year ago (1 children)

Ooorr… vscode with vim extensions/keyboard mappings. :)

[–] [email protected] 2 points 1 year ago

I tried: things like string subs didn't work, no visual block mode, macros non-existant

Real Vim for me!

[–] [email protected] 2 points 1 year ago

Rust dev in emacs using rustic and lsp-mode is quite good.