Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JetBrains invites developers to join the Fleet Public Preview Program

blog.jetbrains.com

Post reply on HN
Print view View original

311–320 of 332 posts

Re: JetBrains invites developers to join the Fleet Public Preview Program

#311

Post by ranguna »

FlyingSnake wrote: post #274
mmastrac wrote: post #253

Earlier quoted context omitted.

It's a single toggle to turn off all telemetry (anonymized, limited to feature usage - no reporting of source files/projects that I've seen), which takes a few seconds to configure at install time as it's literally a menu item (Code > Preferences > Telemetry): https://code.visualstudio.com/docs/getstarted/telemetry You can also dump all possible telemetry events at the command-line.

You can’t really shut down all VSCode telemetry. Source: https://www.roboleary.net/tools/2022/04/20/vscode-telemetry....

You can, just install vscodium

Re: JetBrains invites developers to join the Fleet Public Preview Program

#312

Post by ezschemi »

kobepanda wrote: post #223
pgo wrote: post #220

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?

If you have another invite for zed.dev, could ask for one too? No worries if not!

Email is en [at] ruw.io

Re: JetBrains invites developers to join the Fleet Public Preview Program

#313

Post by dmitriid »

dmitriid wrote: post #305
iudqnolq wrote: post #303

Earlier quoted context omitted.

> 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…

> That's the conventional wisdom. The rust team's theory was that they could make it work. They did. 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.

More to the point. Sadly I can't locate a great article outlining all the problems, bt these quotes will do

From rust-analyzer's main contributor [1]

=== start quote ===

The essential complexity for a server is pretty high. It is known that compilers are complicated, and a language server is a compiler and then some.

First, like a compiler, a language server needs to fully understand the language, it needs to be able to distinguish between valid and invalid programs. However, while for invalid programs a batch compiler is allowed to emit an error message and exit promptly, a language server must analyze any invalid program as best as it can. Working with incomplete and invalid programs is the first complication of a language server in comparison to a compiler.

Second, while a batch compiler is a pure function which transforms source text into machine code, a language server has to work with a code base which is constantly being modified by the user. It is a compiler with a time dimension, and evolution of state over time is one of the hardest problems in programming.

Third, a batch compiler is optimized for maximum throughput, while a language server aims to minimize latency (while not completely forgoing throughput). Adding a latency requirement doesn’t mean that you need to optimize harder. Rather, it means that you generally need to turn the architecture on its head to have an acceptable latency at all.

=== end quote ===

Rust analyzer uses a custom parser [2]

=== start quote ===

a hand-written recursive descent parser, which produces a sequence of events like "start node X", "finish node Y". It works similarly to kotlin's parser, which is a good source of inspiration for dealing with syntax errors and incomplete input. Original libsyntax parser is what we use for the definition of the Rust language. TreeSink and TokenSource traits bridge the tree-agnostic parser from grammar with rowan trees.

=== end quote ===

[1] https://matklad.github.io/2022/04/25/why-lsp.html

[2] https://github.com/rust-lang/rust-analyzer/blob/master/docs/...

Re: JetBrains invites developers to join the Fleet Public Preview Program

#314

Post by iudqnolq »

dmitriid wrote: post #313
dmitriid wrote: post #305

Earlier quoted context omitted.

> That's the conventional wisdom. The rust team's theory was that they could make it work. They did. 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.

More to the point. Sadly I can't locate a great article outlining all the problems, bt these quotes will do From rust-analyzer's main contributor [1] === start quote === The essential complexity for a server is pretty high. It is known that compilers are complicated, and a language server is a compiler and then some. First, like a compiler, a language server needs to fully understand the language, it needs to be able…

I was totally wrong. Thanks for the correction. Looks like it was planned but never implemented (yet): https://github.com/rust-lang/rust-analyzer/issues/10765

Re: JetBrains invites developers to join the Fleet Public Preview Program

#317

Post by afroboy »

ranguna wrote: post #311
FlyingSnake wrote: post #274

Earlier quoted context omitted.

You can’t really shut down all VSCode telemetry. Source: https://www.roboleary.net/tools/2022/04/20/vscode-telemetry....

You can, just install vscodium

Than we are talking about different product.

Re: JetBrains invites developers to join the Fleet Public Preview Program

#318

Post by andrewaylett »

bogwog wrote: post #172
ethanbond wrote: post #80

Earlier quoted context omitted.

It's not. At least as far as I can tell, the different Jetbrains IDEs are more like configurations or flavors of the same underlying thing. You can do most things in most of their IDEs. You should try paying for an IDE. VSCode is great but if you're an engineer getting paid anywhere close to a Silicon Valley wage (or you can expense devtools), you deserve better :)

I was considering CLion, but decided against it because I frequently need to work with a bunch of different programming languages in a single project, not just C or C++, and not just the languages they happen to have an IDE for. It seems like Jetbrains does this so you're forced to buy multiple IDEs if you need support for a multiple languages. I don't even know how that's supposed to work. If I need to switch to edi…

I often have all three of CLion, WebStorm, and PyCharm open. I'm pretty sure I could use IntelliJ for all the use-cases, but the configuration presets make it easier to open all three. As far as memory use goes, I've not had problems -- it seems much more that resources scale with the number of projects open, rather than the number of IDEs open.

I open polyglot projects in whichever IDE is the closest superset of the languages it uses. Which normally means whatever language the service is written in, and plugins for other languages.

Re: JetBrains invites developers to join the Fleet Public Preview Program

#319

Post by andrewaylett »

lopkeny12ko wrote: post #193

I'm pretty confused by the product positioning. If Fleet is built on the same technologies as other Jetbrains IDEs, describes itself as an IDE, and is natively polyglot, why shouldn't it replace the other language-based IDEs? From the marketing material, it's not clear to me the value proposition of, for example, IntelliJ compared to Fleet.

Maybe eventually the other IDEs will evolve into Fleet. But in the meantime, I can see why they'd want to avoid spooking their existing customer base into worrying that their investment in existing tooling is at risk.

Re: JetBrains invites developers to join the Fleet Public Preview Program

#320

Post by mekster »

MikhailVink wrote: post #116
_fat_santa wrote: post #45

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…

JetBrains employee here, and I can clarify the point about “Requires login and periodic connection to JetBrains servers to verify the project”. If you are using Fleet in a Free (hobby) mode, we are verifying that the project comply with one of three criteria: 1. your project is local (no Git or Git Remote). 2. your project is public on GitHub. 3. your project is private but has less than 3 committers. In this case, w…

Manual rule that never gets defined for good sounds like a trouble waiting to happen. It will cause many support tickets asking for every edge cases and some will be angry for not being approved.

If you're really trying to win VS Code users, such a flexible rule may scare them away.

Post reply on HN