its a bad anti-pattern that trades developer convenience for performance, UX etc. Its fair to hate on it
With the advent of coding agents, I really hope we see devs move away - back to the traditional approach of using native frameworks/languages as now, you can write for 1 platform and easily task AI to handle other platforms.
This will never happen and it's a bizarre, legacy fantasy, borne of a fixed imaginary ideal of what computing should
be. Programming will continue to move in the direction of ease-of-use and every time I see an out-of-topic reference to Electron in this forum I feel insane, like I'm fighting upstream. You will not see this - you will see more Electron apps, because that is the modern way of building cross-platform apps, and if you genuinely don't understand why that is I don't know how to explain it to you. You won't see another version of those because nobody is going to waste their time building cross-platform native apps
at a native layer to performatively impress posters on HN. You, and seemingly everybody else on HN, can continue to pretend that devex doesn't matter, but that's the difference I guess between caring about devex and shipping products.
It's not out of topic. We're discussing the Zed editor. Their whole marketing ploy is "we are not electron", "we are rust", "we are native", "we are not slow" alternative to VScode.
This is literally their whole distinguishing feature and people are switching because of it and just it.
It is! If the thing runs like shit, say it runs like shit. Say it's native or not, like every topic title and comment on HN until we weep of boredom. I know it's rust! everything is rust here! Is there any other reason I should care? Are we a forum for discussing interesting technology or are we a forum for discussing alternatives to VSCode? And again, who is switching? People shipping products or HN posters with their dumb metrics?
People who install zed are switching. I don't understand what you're trying to "get" at. You're complaining about people talking about Zed in a topic about Zed.
Zed seems to have been hugely succesful recently and their only real distinguishing feature is "fast from the ground up". It has less features than vscode. Worse AI features than Cursor. but people seem to love it nonetheless.
Turns out there is a market for people fed up with VScode-derivatives.
Cross platform application development is cool but the guys who made Zed are the guys who made Atom are the guys who made Electron, and they pointed out that long term the devex sucks and that Electron simply isn't a good platform for native applications that need any kind of memory control or similar features: https://zed.dev/blog/we-have-to-start-over
> My experience in Atom always felt like bending over backwards to try to achieve something that in principle should have been simple. Lay out some lines and read the position of the cursor at this spot in between these two characters. That seems fundamentally doable and yet it always felt like the tools were not at our disposal. They were very far away from what we wanted to do.
> Nathan: It was a nightmare. I mean, the ironic thing is that we created Electron to create Atom, but I can't imagine a worse application for Electron than a code editor, I don't know. For something simpler, it's probably fine, the memory footprint sucks, but it's fine. But for a code editor you just don't have the level of control I think you need to do these things in a straightforward way at the very least. It's always some... backflip.
Thinking Javascript was a language meant for desktop applications is what is insane - even more so than the convenience of using it, which is comparatively less insane.
I find Zed has some really frustrating UX choices. I’ll run an operation and it will either fail quietly, or be running in the background for a while with no indication that it is doing so.
It does have extensions, but they are much more limited. In particular they can't define UI elements inside buffers, so you can't replicate something with rich UI like the Git integration in an extension.
Does it really? At the end of the day i need it to do my job. Ideal values don’t help me doing my job. So i choose the editor best suited and the features i need. And that’s not zed at the moment.
There's an analogue here with programming language iteration— Python, Ruby and friends showed what the semantics were that were needed, and then a decade or two later, Go and Rust took those semantics and put them in compiled, performance-oriented languages.
Electron has been a powerful tool for quickly iterating UIs and plugin architectures in VSCode, Brackets, Atom, etc, now the window is open for a modern editor to deliver that experience without the massive memory footprint and UI stalls.
I agree with the main point but I am on battery often and the difference between native vs. one or multiple Electron apps in "doing my job" is easily several hours lost to battery life or interruptions for charging. Not a huge deal, but it's not my ideals that make me frown at charge cycles occurring twice as often.
This is simply not true… that’s the problem. As much as I like Zed, using it for the sake of not being an electron app doesn’t make any sense when Cursor’s edit prediction adds so much value. I’m not starved of resources and can run Cursor just fine – as far as Electron apps go VS Code is great, performant enough. I value productivity. I’ll very happily drop Cursor for Zed the second edit prediction is comparable. I’m eagerly waiting.
I'm a hyprland zoomer but I used Niri for a bit and it worked pretty well. It slots in perfectly for someone coming from an average single-monitor Windows workflow (for most office-style tasks). I still think that more complex tiling setups have a higher productivity ceiling though. I guess if you're like this guy and keep >10 workspaces open at once you'd have to go with Niri. I wonder if the increased battery life would still hold for someone that only keeps a few windows open at once. 2 hours is insane from just a change of wm
I'm still cycling through wayland and x11, and I also do get 1.5 hours more runtime on average on my old 2nd gen t14s with x11+xmonad+no compositor. It's one of the main reasons I'm struggling to move permanently, as I really don't see any advantage from my perspective as I don't use any desktop environment or feature that would make a compositor actually useful. The only thing I do notice occasionally are black borders due to shadow dropdowns in gtk4 programs that don't respect the system theme I've set.
Any modern web scraping set up is going to require browser agents. You will probably have to build your own tools to get anything from a major social media platform, or even NYT articles.
May be misunderstanding what you mean by “browser agents” but I’ve done some web scraping that had dynamic content and it was easy with a simple chrome driver / gecko driver + scraper crate in Rust
The presence of currently unfolding areas of innovation doesn't discredit the fact that the exponential progress we've enjoyed since the Industrial Revolution has slowed suddenly over the past few decades.
Which modern language, Go stuck in early 1990's language design, or Rust that still doesn't have a comparable Web story at enterprise level?
Kotlin that leeches on Java infrastructure for its existence? And papa Google is yet to fully rewrite Android in Kotlin/Native?
C# is an alternative, provided there is an implementation for the desired OS platform. Meadow is the only presence in Embedded without the capabilities from PTC, Aicas and microEJ.
Every language new or old will have cons. However, when the perceived con is financial (yes, I realize that OpenJDK isn’t affected, but as evident in the comments many people still don’t know that, and they will never know given all the choices); you’re going to lose a lot of future users.
The part I find interesting is how Java is slowly becoming like COBOL all due to a combination of bad marketing and terrible messaging, and a flawed monetization scheme that was obviously rushed with little thought for the long term.
C# seems the obvious choice to me. One can probably compile Java to C# - it might be in the category of regex then fix compiler errors, so economically reasonable to do. Probably similar library coverage for the two ecosystems by now.
That lets one replace the dependency on Oracle, whose reputation is invariant, with Microsoft, who are known to be nice people who won't blow up your world to increase their profits.
Plus the legal team who liked contracts with Oracle can replace them with contracts with Microsoft. The developers who like Java are fairly likely to like C#, what with it being very nearly the same language.
[in case the subtext is somehow missed, I believe this will punt the problem down the road until Microsoft do something similarly expensive to you]
Microsoft is hardly much different, and contrary to Sun/Oracle once upon a time the gatekeeped .NET features behind different support levels on Visual Studio, like contracts, nowadays gone because obviously the adoption wasn't that great.
There are also some tooling features like code coverage, live testing or byte code rewriting tooling that require Visual Studio Enterprise licenses.
IKVM and J# were two ways of running Java code on .NET.
Not really no, you can't just ignore the culture context of languages.
Ruby projects are going to have a better testing coverage and culture in average than Python projects whereas in reality both languages could do the same.
Java overengineer culture is still present despite being non-existent in other languages like Go whereas in theory it could exist in both.
Nowadays you can do anything with any language, in practice the culture often goes in the way
Ruby is hardly a thing in enterprise computing, and until AI craziness, the only thing that Python mattered for enterprise shops was system administration instead of dealing with a mess of shell scripts and Perl.
Go culture has brought us YAML spaghetting and kubernetes madness at enterprise level.
Many of the features in modern Scala and Java don't exist in other languages.
I would appreciate if you could name them but I would understand if you didn’t have them handy to name. It’s unreasonable to expect you to know them off the top of your head.
