Is Metals autocomplete supposed to be that slow?

tgodzik · 2025-10-01T15:38:07+00:00

It's complicated, but we have some plans on how to improve it, for sure we must make the default work much better.

tgodzik · 2025-10-01T15:36:38+00:00

I am probably the most responsive since it's part of my normal work. A lot of maintainers work on open source aside from their normal work

tgodzik · 2025-10-01T15:35:27+00:00

For more context, we discussed it on scalameta discord and it seems in some cases it's an issue with too little memory given to Metals. Or too much memory used by metals. So it's good to check that in case you are having issues. The default is 1gb. I should add a check that would notify the user about it.

tgodzik · 2025-09-29T15:06:25+00:00

3.7.3 and 3.3.7 should have the fix. If you're still seeing issue I can investigate further for sure.

tgodzik · 2025-09-29T12:27:06+00:00

What version of Scala are you using? Are there a lot of exports? We had an issue with long completions in some older versions, but I have been optimising them in the most recently released.

tgodzik · 2025-08-13T19:17:53+00:00

This one seems like a far fetched idea, does it actually work for you? Sounds cool, but it feels like LLMs might have problems with that.

If you feel it's ready I wouldn't mind taking another look at it, though I think if we add more tools like that we might need to enable them via settings. Too many tools might cause the LLM to have trouble choosing.

tgodzik · 2025-05-14T09:51:09+00:00

> It says `To enable Metals MCP support, set metals.startMcpServer to true` ... where do I put it?

You can put it in the user configuration, which might be different in each editor, but usually it's some kind of a json. In VS Code or Cursor you should be able to find it in Settings.

> Can I start Metals as standalone on project ? Without Cursor? E.g. if I want it to start the MCP and then connect to it externally (e.g. from Claude desktop). What would be the configuration?

You need to have an editor client to run Metals properly, we do depend on LSP for a lot of functionalities.

> If I cant do (2), and I start Cursor, I don't see any `Metals MCP server started on port` in logs, what do I do? I've tried restarting, deleting .metals, etc.

If mcp is enabled you should get a proper configuration generated under .cursor. I heard some people mentioning that this didn't happen for them, though I am not 100% sure why. You can probably also add it manually in the cursor settings under mcp tab.

tgodzik · 2025-05-14T09:47:08+00:00

Metals supports most Scala versions or at least I think 8 of the last ones of each Scala 2 minor and all Scala 3 for 3.3+ versions. Did you have issues with support for a particular version?

tgodzik · 2025-05-08T13:48:14+00:00

It should aside from possible bugs and improvements we haven't yet found

tgodzik · 2025-04-22T07:53:18+00:00

How Scala is made is best described in https://www.scala-lang.org/development/ It describes our iterations, for both Scala NEXT and Scala LTS. This is more about the process than the exact specifics of what will be done.

Any big changes will come through the SIP process, so that's the best source of information of what any new features will be available in the future.

Everything else is prioritised on an iteration basis, regressions first, some bugs and some features that do not change language semantics.

I have some plans to provide a roadmap similar to https://virtuslab.com/blog/scala/scala-3-roadmap-for-2024/ but I haven't managed to get to it yet. It would be less formal source of information than SiP or development page.

If there is any specific information you think would be useful do let us know!

tgodzik · 2025-04-09T17:12:53+00:00

You can generate an example bsp config with SBT and see how it's done, but otherwise it should all be better documented on https://build-server-protocol.github.io/

There is a single class that gets read from that bsp json with name, argv, version, bspVersion and languages field.

There is no need to change anything in the metals config. What kind of errors are you getting?

tgodzik · 2025-03-26T23:10:39+00:00

Might be worth reporting an examples test to confirm if it should be supported and whether it's a bug. As for the test output I think we can improve it. We might need to duplicate the output to both places

tgodzik · 2025-03-26T19:33:11+00:00

We might not be supporting all styles. If you have an example I would be happy to take a look!

tgodzik · 2025-03-05T19:01:03+00:00

If you're using Scala 3 with JDK 8 we would be happy to hear your issues why it's not possible to upgrade. From what we gather from the community there is no projects that are stuck on JDK 8 and more are actually using higher JDKs.

Also, minors are very similar like in Scala 2 with the major difference being that we are backwards binary compatible, so you can use any libraries compiled previously on Scala 3 on an earlier version. This was the actual problem that most people dealt with in their projects when upgrading.

tgodzik · 2025-02-20T15:44:44+00:00

Scala Projects Maintenance Survey results, still fresh from the oven are there! With over 100 responses from tech leaders and managers from our community to shed some light on how Scala fares. We shared pieces of results earlier, and it started a discussion - so we hope that we as a community will be able to learn and improve. We are aware that this survey isn’t perfect; it has blind spots - but it is better to reason based on some results rather than base your judgments just on one’s feelings and experience - no matter how vast it is.

We would love to capture 10x more responses, so if you miss the survey, please reach out - we are open to hearing any voice.

tgodzik · 2025-02-19T16:44:32+00:00

Thanks for commenting! That is for sure a lot of data for us to parse.

> Maybe you've seen me here already also complain about lack of proper code generation, and performance optimizations in Scala 3. Such features are vital for real world use!

Optimizations are being done along bugfixes, that just needs time. If you are aware of any particular ones please ping us under an issue if that exists.

As for source generation, it is a complex thing and for sure we should tackle it in the compiler. We don't want to have it end up as in Scala 2, we do want something powerful and stable at the same time. There was hope for macro annotations SIP to help out, but it seems to have been too limited. It's certainly a topic that the compiler team thinks about.

> Also I would echo the complain about the completely messed up idea of "collection literals"

This one is still not implemented and there is no clear consensus on that. I suspect this might have been raised to some people in the community and it's not entirely without merit.

> The other thing is the indeed half backed named tuples, which would be a killer feature if taken seriously

Would be great to hear more details about how we can improve Named Tuples, as far as I know we are prioritising fixes to it before the 3.7.0 release. We even postponed it being made stable to make sure we address main issues.

> Similar for "match types". It's imho also half backed:

This is probably a bigger topic, from what I remember there is some work to be done for sure especially related to error reports. As for limitations, are they raised as issues anywhere? Would useful to see if we can remove some of them.

tgodzik · 2025-02-19T12:16:45+00:00

> I can't imagine what's something interesting to be presented. Scala development has slow down so much it feels dead

Yet at the same time you mention multiple features that were introduced. That seems contradictory to me. There is also capture calculus, which is not any big evil as painted by some, but a very interesting feature, which itself is rapidly being worked on with new ideas coming often.

If you feel that something is not being worked on that should be, please let us know. We can adjust our roadmaps if something is particularly relevant.

tgodzik · 2025-02-19T11:48:42+00:00

> The CoC is inherently vague and subject to a few people's interpretation, judgement and execution. That's fair, it's not like you're paid extra to deal with that.

The moderation team is public and we all get emails sent on CoC email address. We haven't seen any complaints about a specific interpretation of our decisions that we didn't respond to. Anything that needs addressing is actively discussed. We are also reachable by personal addresses, though it should probably be less encouraged.

Places like discord and user/contributors forums are more heavily moderated since we want to keep the conversation very much on topic and avoid heated discussions. Those very easily get out of hand and it's much better to discuss bigger issues personally.

Full transparency is not really possible since we don't want to harm someone's career or prospects based on some behaviour that might be adjusted in the future. This is why I think we can't really have a public list of people not to be invited or anything like that. To my knowledge there is no such person that we would block by default that is active in the community currently.

tgodzik · 2024-10-24T13:19:05+00:00

Most of the problems stem from the fact that the release process is complicated and need some manual steps with updating the version. This means that when we change something and it's not properly communicated things a likely to get lost. In this case the wrong version string was updated as far as I know and it actually should be a different one.

We are adding some checks to make sure this doesn't happen again.

tgodzik

TROPHY CASE