Hacker News Reader

Comment by capableweb | Hacker News Reader

> Fleet is our new distributed polyglot editor and IDE.

Ok, polygot makes sense, it supports more than just one language. But what does distributed mean in this context? You run the editor across many machines? What does that mean? Coming from a backend perspective, it quite doesn't make much sense. Thinking about it from a client-side perspective, I'm guessing they mean the architecture is decoupled, meaning basically plugins/extensions but with a fancier word?

Judging by the "Features Matrix" (https://docs.google.com/spreadsheets/u/1/d/e/2PACX-1vTWt9RlJ...), sad to see not a single non C-like language is being considered.

View on HN

>But what does distributed mean in this context?

The older Jetbrains IDEA IDE is a monolithic local application. E.g. it does both UI navigation _and_ batch processing work like source code indexing.

Fleet is re-architected to be "distributed" aka "client/server" style into a "lightweight" frontend + "heavyweight" backend. E.g., the frontend does UI navigation and basic syntax parsing but the backend (which can be on remote servers) can do full codebase indexing. As a bonus, the code index database can be shared by many frontends.

Code indexing for huge repos (e.g. 1 million LOC) takes a very long time and is one of the complaints of classical IDEA IDE performance being sluggish.

Take the "code indexing" example and extend it to other "heavy" backend batch processes like linting, testing, etc. The backend can also be in the cloud.

As a footnote, Fleet is also a competitive response to MS VSCode by having collaborative features. But my comment mostly answers the "distributed" aspect.

Related articles that also have the client+server diagram:

https://www.infoworld.com/article/3664112/jetbrains-fleet-th...

https://blog.jetbrains.com/fleet/2022/01/fleet-below-deck-pa...

>frontend + backend is not distributed, but it definitely is client/server architecture

EDIT to clarify: the "distributed" is describing "distributed application" of client+server ... like 1st sentence of wikipedia : https://en.wikipedia.org/wiki/Client%E2%80%93server_model

so, modular? :)

crud app with frontend + backend is not distributed, but it definitely is client/server architecture

but that's just nitpick, iirc "distributed" means something different in their context

What would be your definition of distributed?

Going beyond the traditional client<>server/thin client architecture with at least 2 servers is what I'd consider distributed.

> with at least 2 servers is what I'd consider distributed.

There are several meanings of "distributed" :

(1) multiple servers coordination like Google's MapReduce BigTable, Cassandra, Hadoop, etc

(2) describing a split client+server architecture that may have just 1 server. This usage of "distributed architecture" in discussions was more common in 1980s/1990s with the rise of client/server computing. Visual Basic CRUD, PowerBuilder, SAP R/3, etc.

In the Jetbrains article, if you do Ctrl+F search for all occurrences of "distributed", it is clear they're talking about meaning (2): https://blog.jetbrains.com/fleet/2022/06/fleet-below-deck-pa...

To answer your previous question: >I'm guessing they mean the architecture is decoupled, [...] but with a fancier word?

It's not a fancier word. Jetbrains is re-using an existing description of "distributed==client/server" that's been around for decades. It's just that "distributed computing" has been recently dominated by the examples of meaning (1) above.

Distributed means you can run the editor UI and the actual backend on separate machines. One long-term goal of such deployments is developers just having a thin chromebook with the UI and the actual code being on a corporate server, like terminals and mainframes in ye olde days.

I believe this is a reaction to VS Code, which has supported this functionality for a while already.

Another big use case is running the "backend" inside a VM or container that has a well-defined set of dependencies installed while the host OS can be updated and managed by the user.

But conventionally the word "distributed” is for apps running on multiple servers. Your definition makes every web app "distributed". And I feel like most of HN would disagree with calling Spotify Web a "distributed app"

It's not "my" definition, it used to be a very common definition.

e.g., quassel, an irc bouncer + client, used the same term since 2007.

As you noted w/ VSCode (and others) this dev style can be done quite easily for free, what advantages does a vendor lock-in provide?

You'll get actually useful suggestions and refactoring abilities. VS Code is today still just a editor with syntax highlighting and very basic suggestions. Even with language servers it can't come close to what JetBrains does.

JetBrains first major product was an addon to improve the suggestion abilities of Visual Studio, and VS Code is a downgrade even compared to normal VS

Interesting... I will have to check it out properly at some point then, thanks for the insight.

So... every X-Window application is "distributed"?

I'd not have described them that way.

Yes, that's what X-Windows was created for. The original goal was for terminals connected to large servers, where you'd have the application distributed with the UI on the terminal and the backend running on the remote server.

> But what does distributed mean in this context? You run the editor across many machines? What does that mean?

It means that the editor is split into two (or more) parts: a UI that runs locally on the machine you're sitting in front of, and a server that can run anywhere that does I/O, analysis, debugging, etc. It's useful e.g. if you're running Windows but target Linux (run the server-side in WSL), for dev containers (run the server-side inside a container with the toolchain for your project), or to develop in/for the cloud.

> But what does distributed mean in this context? You run the editor across many machines? What does that mean?

Yes:

> distributed architecture. For more details check out the Fleet product page [link].

> [Fleet product page:] Distributed for flexibility

> Fleet’s architecture is designed to support a range of configurations and workflows. You can simply run Fleet just on your machine, or move some of the processes elsewhere – for example by locating the code processing in the cloud.

Ok, so I could kind of understand the use case of running the UI on one machine and the backend for the UI on another machine. Lots of complexity for small amount of gain, but somewhat makes sense.

But then they say "distributed" so that would mean many backend machines, not just one. What on earth is the backend doing where one instance is not enough for one client? How could one client UI possibly need more than one backing instance? Sounds horribly inefficient.

Maybe the possibility of compiling and running on different platforms?

Microservices ... laptop user sets breakpoints on a Django/Python API/web server, a Java financial transaction processor, and a golang outgoing webhook queue server.

> Lots of complexity for small amount of gain

Being able to develop on a huge beefy cloud instance, with managed background services, possibly with different architectures, from your laptop is huge.

> But then they say "distributed" so that would mean many backend machines, not just one.

‘Distributed’ doesn’t mean ‘many’ - it’s distributed over two.

A "huge beefy cloud instance" comes with a premium price, especially if you're planning to use it for a year or two, while also coming with its own set of problems: No internet connection? No luck! Downloading dependencies for your backend? Start paying per GB downloaded, and so on.

> ‘Distributed’ doesn’t mean ‘many’ - it’s distributed over two.

A client<>server architecture is generally not considered "distributed" unless there is multiple servers involved, at least how the terminology have been understood until today, if it changed suddenly.

Usually when it comes to these kind of architectures, you'd refer to them as "thin clients", and the architecture has been around since mainframes if not longer.

> A "huge beefy cloud instance" comes with a premium price

Ok? What's that got to do if it's useful or not.

> Usually when it comes to these kind of architectures, you'd refer to them as "thin clients"

Ah well the difference here is the client does a lot more work - it's running the editor, the editing and the editor state, it's not just transmitting input and receiving drawing commands.

Distributed program vs distributed computing. One is anything from MMORPGs to P2P to thin clients. The other is for heavy computations distributed across a network of task processing nodes.

VS code can connect to a machine running SSH and you edit locally, but all the code, extensions, etc runs on the other machine. It is not just a matter of copying the files back and forth either, and the experience is super smooth. If you open a port on the remote computer with your program, it will even be forwarded.

I assume this is their answer to that.

Their IDEs support this workflow today

> sad to see not a single non C-like language is being considered

They are reusing the IntelliJ backend, which I don't believe has out of the box support for a language not on that list

Presumably this is just easy to configure integrations so you can do things like run a build job on your CI/CD platform, push/pull artifacts, deploy applications, etc.

apparently no Scala as well??!

Reply on news.ycombinator.com