301–310 of 332 posts
Earlier quoted context omitted.
Would you happen to have an invite for zed.dev ? I typically have 10-15 VSCode windows open and have been looking for an performant but modern IDE
Yes I have a few - is the email in your profile current?
My email is in profile.
jack [at] weakphi [dot] sh
This looks really promising. But by far the biggest moat that Jetbrains is going to have to cross to get into VSCode territory is the plugin ecosystem. Personally I work on React projects so my first thought was: "is there a Prettier[1] plugin?". Looking through the landing page it looks like Plugins are in the works but until that is implemented, it's going to be hard adopting it. ALSO I just noticed this but can so…
Fleet seems like a new lighter architecture. Which is fantastic. My hope is they can actually bring the tools from their other platforms into this.
Otherwise... they might as well just sell a IDE plugin architecture for VSCode.
Earlier quoted context omitted.
When I last used them for Rust about two years ago they were racing neck and neck against a language server being refactored to share a backend with the reference compiler. I switched to the language server because I felt running the actual compiler will in the long term always work better than writing your own parser. I was on the Jetbrains student discount, so I made a small recurring contribution to the rust langu…
> running the actual compiler will in the long term always work better than writing your own parser. No, it won't. A compiler and an IDE code analyzer have completely different non-intersecting goals. As an example, consider error recovery. Where a compiler can just fail with an error, in an IDE you need to continue to provide full correct syntax highlighting, display all other potential errors and warnings, continue…
That's the conventional wisdom. The rust team's theory was that they could make it work. They did.
> As an example, consider error recovery. Where a compiler can just fail with an error, in an IDE you need to continue to provide full correct syntax highlighting, display all other potential errors and warnings, continue providing code analysis (including suggestions on how to fix the error) etc.
Possibly the Rust compiler's unusual prioritization of friendly error messages with helpful suggestions meant this wasn't as big a difference as you thought?
> None of these are provided by the language server team. These are provided by whoever wrote the code to analyze your stuff and provide data to the language server.
That's how it works for many languages: the language server implementation is a thin wrapper around an existing tool. That's not the case for rust. I've watched the work the Rust language server team did on their language server implementation and the compiler. It was impressive.
Earlier quoted context omitted.
>It's leaps and bounds ahead of VSCode It's also paid vs free. For some reason, some people are very reluctant to pay for tools, even though they use them every day in their job.
> For some reason, some people are very reluctant to pay for tools, even though they use them every day in their job. I used to pay Jetbrains annually, out of my own pocket. I continued paying fir a personal license even after my employer bought me another license. Jetbrains then made a stupid, greedy decision[1] (and walked or back within days), but I was done with them and canceled my subscription. Since then, my e…
IDEs as in plural, like several IDEs? What IDEs are you using now? I'm yet to find something that is as good for several languages as Idea Ultimate? Yes, for some languages Vscode plugin is superior, but overall as a polyglot I find Idea experience the best all things considered.
Earlier quoted context omitted.
> running the actual compiler will in the long term always work better than writing your own parser. No, it won't. A compiler and an IDE code analyzer have completely different non-intersecting goals. As an example, consider error recovery. Where a compiler can just fail with an error, in an IDE you need to continue to provide full correct syntax highlighting, display all other potential errors and warnings, continue…
> No, it won't. A compiler and an IDE code analyzer have completely different non-intersecting goals. That's the conventional wisdom. The rust team's theory was that they could make it work. They did. > As an example, consider error recovery. Where a compiler can just fail with an error, in an IDE you need to continue to provide full correct syntax highlighting, display all other potential errors and warnings, contin…
They didn't. Does the rust compiler support continuous analysis required by an IDE?
> That's not the case for rust.
Funny. Rust analyzer blog would have us believe that they have their own parser and analyzer.
Earlier quoted context omitted.
That is why one has the IT department configuring development images. I remeber there was a blog post from JetBrains where they complain about VSCode taking over InteliJ market, by indirectly asserting they don't understand why VSCode adoption was rising. Surprise surprise, a couple of months later Fleet was announced.
I'd say they still don't understand why VSCode adoption is rising. There are two reasons: - People don't know better (yes, they really don't) - Language server allowed languages with abysmal tools to finally have some semblance of an IDE None of us know the future, but in my opinion Fleet is a mistake: - It tries to fight VSCode at VSCode's turf (an editor with primitive IDE functionality) - while trying to be a test…
Earlier quoted context omitted.
While annoying, all intellij EAPs (early access previews) are very cpu intensive, as they run in debug mode by default to create diagnostics and crash reports. Kinda similar like if you would keep the debugger open in your browser. Not sure if you can disable it, but thats the main reason why I stopped using EAPs for work. But the ram is typical intellij, they take what they can get from the OS :)
> But the ram is typical intellij, they take what they can get from the OS :) Aha, thanks! I was wondering about that (using CLion 2021.3 with Rust plugin with currently a tiny test project open, currently using 2.3 GiB RAM, puah)... .
Earlier quoted context omitted.
> running the actual compiler will in the long term always work better than writing your own parser. No, it won't. A compiler and an IDE code analyzer have completely different non-intersecting goals. As an example, consider error recovery. Where a compiler can just fail with an error, in an IDE you need to continue to provide full correct syntax highlighting, display all other potential errors and warnings, continue…
I once heard that an editor spends the majority of its time in an error state, and only periodically someone stops typing in hopefully(!) a valid state. Thinking how to generate helpful recovery states in an ide's parser sounds like an incredible amount of work
It is. Error recovery is one of the biggest issues precisely for the reason you mentioned :)
So I tried it out. I own a CLion license and have been using Jetbrains products since IntelliJ 3.0. It seems ok, but very very VSCode-ish. I tried it with our Rust codebase and it seemed to be fairly competitive with CLion in terms of analysis. I didn't try any refactorings but I did notice that it doesn't have many of them. It was fairly snappy, felt more responsive than CLion. I was disappointed that even after I s…
but more importantly, i like that intellij is full featured and has proper windows and dialogs and keybindings. vscode tries to cram everything into a single textbox or ui element and it makes everything worse.
give me intellij but let me build a language backend in whatever language i want instead of forcing java on me. and also so that i can run it at my work which doesn't like code on laptops
Earlier quoted context omitted.
> But the ram is typical intellij, they take what they can get from the OS :) Aha, thanks! I was wondering about that (using CLion 2021.3 with Rust plugin with currently a tiny test project open, currently using 2.3 GiB RAM, puah)... .
Well, they cache many things to make code analysis fast, so they are one of the few softwares that do make good use of memory. Some older version had very low heap size set and that can cause slow downs, so 2+ GB is recommended at least in my experience.