I wonder if the flood of vibecoding startups may end up helping long established enterprises and OSS through eroding consumer trust towards new software, and highlighting the value of the industrial software development process. Bills of materials, 4-eyes code reviews, release gates, QA testers, planning involving domain experts, external audits etc. Any time I see a new large piece of software nowadays that seems to have popped out of nowhere and has generic sounding docs and testimonials with em dashes I tend to wonder if it was generated with a one shot prompt and may include vulnerabilities, malicious code, or business domain hallucinations.
It's a bit like with books: 10+ years ago I could have trusted a book from a new author I never heard about just because the large effort of getting published was hinting that the author is likely qualified. Now, hell no.
When the barrier to publish drops to zero, the barrier to gain trust skyrockets.
How are you so sure that big corporations will also keep doing code reviews, QA testing, planning. At the current moment, they are laying off a large portion of their workforce, forcing devs to take more and more ownership and even expecting devs to assume the QA testing role. I dont think any software is trustable anymore.
It's all about responsibility. If I pay a company for functional software and it doesn't function, that's on them.
I expect a much greater emphasis on contractual performance and liability now that the customer has even less reason to trust that a vendor is doing the right thing.
Fair point: perhaps the true advantage of long established enterprises and OSS orgs is not the process, which can be considered private implementation detail, but the public track record. Either way, startups don't have that.
The real question is whether these security practices can truly survive the onslaught of 24/7 attack swarms, or if we're going to have to rebuild the entire cloud from the ground up.
Also try Lapce! In my experience somehow starts noticably faster even than Zed. Also implemented in Rust but different GUI approach. Both support LSPs.
Calling it "OpenIDEA" is a bit misleading. IntellijIDEA is free and open source (Apache 2.0) since 2009. Paid subscription basically gives you extra plugins. And as others pointed out, saying that it was rebuilt in Rust is at least as much misleading: the code processing is still standalone LSP processes, frontend is WebView with typescript, only Tauri glue code is Rust. And that in turn makes me extremely skeptical about claimed memory usage! Consider that you must compare idea.exe against combo of WebView (on windows: chromium edge) + LSP (for Java, likely Eclipse LSP, at least that's what VSCode traditionally uses for Java). Is it realistic to fit that in claimed 169 MB?
Correction: Rust is more than just Tauri glue code (https://github.com/l0ng-ai/openidea/issues/568#issuecomment-...). But considering that in an IDE the two performance critical parts are code processing (LSP) and frontend, I wonder how much benefit can you really get by making everything except of them in Rust.
Overall I actually agree that VSCode has proven that making responsive web based frontends is absolutely viable for the IDE, if you accept startup latency, size and memory use of CEF / Electron. And on Windows and macOS, system WebView may be sufficiently compatible (not on Linux anytime soon!), and they significantly amortize all of those downsides.
Except people forget that only works for VScode, thanks to the multiple processes architecture with enough components written in a mix of C++, Rust, .NET and Java, with the terminal using WebGL.
It is quite telling how many clueless folks brag about Java support in VSCode, without understanding that depending on the plugin, they are either running Eclipse or Netbeans headless.
Yeah, Electron works, provided one creates a whole circus around its performance issues.
My experience: intuitive thinking it's a shortcut, but it's less reliable when it comes to complex problems, especially involving multiple concepts that have to be reasoned about with non trivial relationships or rules. In a way I see a spectrum of approaches that range from fast to reliable:
1. Intuitive thinking
2. Language based internal monologue
3. Written scratchpad
4. Explaining the problem to another person until they understand it (rubber ducking)
Like the response from the UltraSane: my thinking is and always was 100% made of internal language-based chain of thought ("imaginary talking to myself"), with some amount of introspection / meta reasoning when problem is particularly hard. This article indeed reads to me a bit like someone proposing a physical storage medium inspired by those pictures of little squares traditionally used as "save" icon, without realizing that this digital representation was in the first place based on an existing real world thing.
Anyway, a surprising related observation is that rubber ducking by describing the problem to quiet listener still often helps me, which suggests that internal chain of thought makes intuitive shortcuts that sometimes are counter productive, while talking to another person creates subconscious pressure to make the thoughts fully complete.
He has 500+ open source repositories including very advanced stuff like GPU powered gui framework and game engine components ( https://wieslawsoltes.github.io/Home ). It's very impressive and almost hard to believe that a single person could make all of this, even with help of modern ai agents.
Its new era, you can build, experiment and do fun projects at will , takes few hours to get anything into working prototype. Some of projects might fail, be buggy but exploration pace is unmatched and fun level too.
I can't argue for the original person, but when 500 large projects are different instantiations of just a handful of fundamental primitives, it is not hard to keep track of large number of projects which might look like completely different non overlapping projects for an outside observer.
With enough competence, it boils down to an exercise in organizing discipline and first principles derivation. As I have mentioned in the past, skillsets at sufficient granularity are transferable across domains.
What you said would be true when looked at each different project as a separate domain, but real world is rarely a collection of isolated domains.
To put that in perspective, our app SlypBusiness has memberships, products, services, gift cards, privilege cards, etc. which all look like different domains to a user but is fundamentally the same primitive instantiated differently.
This looks very cool! All the demo slots are taken at the moment. I'm curious: is the frontend just a dumb display server, or do you run there subset of GUI code responsible for latency sensitive feedback loops (typing, scrolling, dragging, maybe expanding menus etc)? E.g. is it vulnerable to network latency the same way as remote desktop solutions are?
Thanks! Sorry about the slots, I just raised the limit and idle desktops now free up after 10 minutes, so it should be easier to get in.
It's not a display server. Each app's frontend is a normal web page that runs in your browser, in its own sandboxed frame, so typing, scrolling, menus and dragging are all local, just like any web app. The desktop itself (windows, taskbar, the map) also runs in the browser.
What goes over the network is only what the app decides to send: messages and events between its frontend and its backend on the server, over one WebSocket. So latency shows up where any web app would feel it, when it waits for data from its server, not on every frame or keystroke.
The one exception is something like the Terminal, where every keystroke goes to a shell on the host, so it feels like SSH on a slow link.
Salads are dishes without a fixed structure. You can randomly rearrange the ingredients without changing it into another dish.
For example, a pizza is salad on top of dough, a burger is salad between buns, and a burrito is salad wrapped in a tortilla. But as a whole, pizzas, burgers, and burritos each have a strict, defined structure, so they aren't salads, they just contain a salad component.
Additionally, anything made mostly of liquid by volume is a soup or beverage, not a salad.
Watermelon pieces are made mostly of water, but are solid as a whole, not liquid. You can't pour them. And if you actually blend them into a liquid, then you get watermelon juice or soup. (Soup vs beverage is a distinction based on the mode of serving, in a glass vs bowl+spoon)
I think my main issue is that the spectrum goes from
entire melon -> salad -> slush? -> beverage
with decreasing side length of the cut pieces.
So both the fixed structure from your definition (" Salads are dishes without a fixed structure") and solid/liquid definition don't feel really tangible to me. YMMV
It's a bit like with books: 10+ years ago I could have trusted a book from a new author I never heard about just because the large effort of getting published was hinting that the author is likely qualified. Now, hell no.
When the barrier to publish drops to zero, the barrier to gain trust skyrockets.
reply