JetBrains invites developers to join the Fleet Public Preview Program

Post by mdaniel » Wed, Oct 12, 2022, 10:58 PM UTC

dmitriid wrote: post #287

iudqnolq wrote: post #240

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…

Post by mardifoufs » Wed, Oct 12, 2022, 11:06 PM UTC

lemming wrote: post #281

sangnoir wrote: post #247

Earlier quoted context omitted.

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

Some years back, they decided on an IDE-as-a-service path where they were going to brick your IDE the day your subscription lapsed. No they didn't. This is a total mischaracterisation of how JB's subscription works.

Post by speed_spread » Thu, Oct 13, 2022, 12:06 AM UTC

Kukumber wrote: post #198

speed_spread wrote: post #195

Earlier quoted context omitted.

Native code makes it much harder to design a runtime plugin system. Also, other than fast startup and lower memory usage, native code does not make the app faster.

> Native code makes it much harder to design a runtime plugin system That's not true, lua, lua-jit, quickjs, v8, c#, even java Game engines already have the lead in that area and they proved that it's possible and can be made very efficient The UI and host of the program should be native to maximize performance Native code helps write fast code that runs fast with optimized memory layouts

Post by lemming » Thu, Oct 13, 2022, 12:18 AM UTC

sangnoir wrote: post #294

lemming wrote: post #281

Earlier quoted context omitted.

Some years back, they decided on an IDE-as-a-service path where they were going to brick your IDE the day your subscription lapsed. No they didn't. This is a total mischaracterisation of how JB's subscription works.

I clearly mentioned they walked back the decision within days of the initial announcement. I don't understand how you could possibly have read my comment as describing their current licensing practices, with the tenses I was using. You can go read up on the disastrous announcement and the followup at https://blog.jetbrains.com/blog/2015/09/03/introducing-jetbr...

Post by kuschku » Thu, Oct 13, 2022, 12:32 AM UTC

woojoo666 wrote: post #288

kuschku wrote: post #14

Earlier quoted context omitted.

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.

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"