Comment by rtfeldman | Hacker News Reader

Comment by rtfeldman | Hacker News Reader

Parent Full thread

Glad you've been enjoying Software Unscripted, thank you for the kind words!

> 1. Whether they'll support macros,

The plan is not to support macros. A major reason is that macros tend to conflict with editor tooling, and I definitely have big plans for Roc's editor tooling!

> 2. Whether their decision to build a whole new IDE will take away from the work that will go into an LSP (it will take a lot to pry away neovim from my hands).

The IDE project has been deprioritized a lot (e.g. I don't expect any work to be done on it in 2024) because we realized there's a way to build the editor plugin ecosystem we want to build in a way that works across multiple editors.

There already is a preliminary language server, and there are instructions in the VS Code extension for how to get it set up [0]. I assume something similar should work for neovim!

EDIT: I just noticed that while I was typing this, the author of the Roc language server responded too...hi, Ayaz! Thanks for all your excellent contributions to Roc!

https://github.com/ivan-demchenko/roc-vscode-unofficial#conf...

> The plan is not to support macros. A major reason is that macros tend to conflict with editor tooling, and I definitely have big plans for Roc's editor tooling!

I disagree! I've been working on a macro-heavy Rust project with both proc and declarative macros and the tooling makes them better. I'll add that there is immense value in turning repetitive code into "spreadsheet" style tables of data as well as being able to combine const expressions to get user controllable compile-time errors.

A common example of a tooling problem I've run into with Rust macros is that if I use a string interpolation macro (e.g. in an argument to println!, format!, or dbg!) a lot of VS Code tooling that works outside of macros stops working.

For example, I can't use normal context menu things on an interpolated variable name, like Go To Definition or Refactor. Similarly, if I do a semantic rename of a variable used in interpolation, it doesn't get renamed. Things like this.

Maybe these are solvable problems, but we're talking about widely used macros that have been in the standard library for many years, and even those don't have basic support for normal operations that Just Work in a non-macro context, in one of the most popular Rust editors!

> if I use a string interpolation macro (e.g. in an argument to println!, format!, or dbg!) a lot of VS Code tooling that works outside of macros stops working

I imagine this isn't that hard of a problem to solve (though maybe relying on VSCode to handle renames is part of the issue), but low-enough on the annoyance scale that nobody cares enough to implement it. I'm not going to argue there aren't annoyances with macros and that they're harder for tooling to deal with, but I don't think that's a sufficient justification to not have them at all IMO.

> The plan is not to support macros.

Gotcha. In every lang I've used a lot, I've found meta-programming (compile-time or dynamic) to be valuable (and often indespensible). I can imagine that a lang like Elm that is domain-specific can do fine without the expressive power of macros, but I struggle to imagine that for a general-purpose lang like Roc.

I'm sure you've ruminated on this, so I'm excited to see how it all pans out.

Maybe a Software Unscripted episode with someone who's written a lot of macros is in order? :) David Tolnay (serde maintainer) would be great!

> The plan is not to support macros

How do you plan on supporting meta-programming, then? Code-generation as a first class citizen a la .NET?

+1 for Software Unscripted! I know barely anything about compilers, but I really enjoy being a fly on the wall of these conversations :)

Reply on news.ycombinator.com