As luck would have it, you can just pay the provider and use their service. Others may want to run locally for privacy reasons or just for the fun of it. I think at-home AI is incredibly awesome and I applaud the enthusiasts pushing it forward. Just because that's where it's at today doesn't mean it's the best we can do.
Plus, you know, this thread was about running AI on "lame consumer hardware". There are more power efficient options available.
I use only providers because I don't have the hardware, but if, and that's a big if, the only moat left for humans is our ability to steer and make bigger picture decisions with our personality, I think it makes sense not to want to send all that conversation data to a 3rd party.
I don’t disagree, but to me web components solve a different problem. I want rich widgets without being bound to any particular JS framework and without having to ad hoc it everywhere.
As an example, I still like the simplicity of Rails for basic apps. I also enjoy the numerous component libraries, such as Antd, available for React. I don’t want to have to pull in React just so I can get a reasonable way to work with a Tree widget.
I’m not trying to only use the platform. The components are free to be built with whatever lightweight lib they need (Lit, UI5 Core, etc.). But that’s contained in the component. I’m free to use my framework or web technology of choice for building my app.
> I don’t disagree, but to me web components solve a different problem. I want rich widgets without being bound to any particular JS framework and without having to ad hoc it everywhere.
The point is that the "platform" way of doing things is lagging behind virtually all JavaScript frameworks particularly in developer experience, and even when the platform tries to catch up with JavaScript frameworks such as web components... The results are between underwhelming and unusable.
> The components are free to be built with whatever lightweight lib they need (Lit, UI5 Core, etc.).
You're still resorting to using JavaScript frameworks. The problems created by the platform are still there if you replace framework foo with framework bar. In fact, it seems React 19 rolled out full support for web components.
The very next sentence after the one you posted is "We expect normal porting activities to eventually add support for all major architectures." Goals and non-goals inform the scope of the proposal. Given this is effectively an "add-on", I don't think it's unreasonable to prioritize the most popular platforms. Others will continue to execute Java perfectly fine in JVM mode.
If you haven't checked it out yet, GraalVM's Native Image [1] already let's do AOT compilation suitable for distribution. You have to do some configuration to deal with reflection and dynamic class loading since there's no JVM in the produced build, but it comes with tooling to simplify that. And that restriction is being addressed by Project Crema [2].
The slight drawback is that AOT compiled Java code's performance isn't as good as the JIT compiled form running on the JVM.
There's a reason why folks keep coming back to JIT compilation. It's hard to beat the value that can be gained from actually gathering data on how the code is actually used, which leads to a whole set of potential optimisations (which is the problem Profile Guided Optimisation attempts to solve for AOT compiled code.) The JVM is arguably one of the most advanced and capable JITing runtimes.
As with anything it's a trade off. Fast start times, pretty fast running (I think maybe less memory usage?); vs the full JIT speed you can get on the JVM at the cost of start-up speed and memory consumption. All depends on what you want to use the application for.
If you're talking something like a serverless function, go native. If you're talking production server where you're measuring runtime in more than dozens of minutes, probably better to stick to the JVM & JIT.
Full agreement with everything you said. Just one detail to add on serverless (and potentially in a scheduled environment like k8s), startup time can be an order of magnitude or more faster in a native build. For instance, I have some quarkus applications that can take 10 seconds to ready running via the jre that take 10ms or less to start as a graalvm built binary.
Java has many dynamic features where runtime optimization is required to remove the overhead. Virtual method calls are opt-out instead of opt-in, and there is an open world assumption. The possibility of doing stack allocation of objects depends on the call hierarchy (in the future it will get a bit easier with value objects). Also, C/C++ are not managed languages, therefore the effects of bad optimization don't hurt as much.
Have you checked your fs.inotify.max_user_watches value? Maybe your value is too low and Zed can't watch the files that are changing. I know the JetBrains IDEs need the default to be increased on Linux because they detected it and prompted me to increase it.
Even if that's the case, max_user_watches is never less than 8k unless you've set it lower for some reason. If the editor is prioritizing currently open files as it should, there should basically never be a problem even if project sync suffers.
The limit is per-user, not per-editor. Every process under your UID shares the same max_user_watches pool. So the editor's "prioritize open files" behavior can't help when a resident daemon like Watchman has already consumed the budget. Zed doesn't error out when it hits the watch limit. It logs a warning and periodically retries to establish the watch. Until it can do so, external file changes aren't reflected in the editor.
I just checked my workstation and found Watchman alone holds ~556K watches across 34 roots. It keeps those watches even after the tool that spawned it disconnects. Notably, I've never invoked Watchman manually -- other tools do. And the 8k floor isn't much of a floor. My nixpkgs checkout alone is 37,686 directories, 4.6x that.
Truthfully, I had no idea Watchman stays resident and accumulates watched roots. But, that's kind of the point. It's a very easy thing to miss.
Nintendo Switch cartridges don't have this problem, mostly. It's the reason I buy physical for the family library. Nintendo's digital licensing is terrible (slightly less so with Virtual Cartridges, but miles away from Steam Family) and doesn't really work for a multi-Switch household.
But, I was traveling for work and brought the non-"home" Switch with me along with a copy of Breath of the Wild on cartridge. I fired it up on the airplane, ready to go. And then discovered that because I had bought the DLC and the DLC license check couldn't pass, I was locked out of playing at all. It's given me pause on buying any other DLC on a Nintendo platform.
...huh, do the online license checks only happen if you have the cartridge sharing stuff enabled? Wondering when/if I would run into this, I haven't yet. But I never use their "virtual game card" system, I only have one Switch and I think the whole thing is overcomplicated and too limited.
i have flaky internet and i am always able to play my virtual cards. I've never had an issue with wifi off, either. I just assume it needs to phone home because everything does, but it doesn't need to phone home to play right then.
Now, i got my kid another switch and he decided he wanted his own account tied to the family nintendo plan and now i am learning what a pain the virtual cards are. If he had just let me put my account on his switch he could have all the games i have, but that's not what we went with ;-)
While not great, the virtual cards are an improvement, unless your kid and you never play the same games. One Switch gets to be the home console and doesn't need checks. The other would have to be logged in as you, which requires a license check every time you play. But, save files are tied to the account and you can't move them between accounts. If you use cloud save files, you and your kid are going to be bumping into each other all the time. Then, if you introduced a 3rd Switch, only one of the non-home Switches could play a game under your account at a time, even if they're different games.
I know 3+ Switches sound like a lot, but Nintendo was pushing the Switch Lite like the latest Gameboy. Maybe you concede and decide to buy the same game multiple times to avoid all of this. Well, there's no gifting. You need to enter your billing details into your kid's Switch and buy it there. Assuming you don't want to leave your credit card setup in their Switch, you get to go through this whole dance every time you buy something.
Virtual cards let you avoid a lot of this nonsense for two weeks. You'll rapidly get annoyed having to keep the original Switch and the new one in close proximity to do the exchange, but it'll work. But, it's nowhere near as nice as Steam Family or the iOS Family Sharing.
If you click the “favorite” link it’ll be saved to your list of favorites. But, it doesn’t actually have to be your favorite —- it’s just a user-defined collection of HN posts.
Thanks for mentioning this. It seemed odd to me, too, so I spent some time trying to work it out. As a reviewer, I'm not sure how I'm supposed to assess database or API changes without knowing how they're intended to be used. And deploying them independently seems odd, too, especially if you need to roll it all back.
I think in my ideal world there would be a clean history and I could review a PR commit-by-commit. But, you can't just approve a single commit, so there's a tooling problem there. And most CI runs on an entire push rather than individual commits. And increasingly I see devs using git as an offsite backup for whatever change they just made, rather than breaking commits up into logical chunks. In that workflow, squashed merges make the most sense.
It's probably flawed, but the mental model I came up with is each stacked PR collapses into what would have been an individual commit in a clean PR, with the advantage of being able to be reviewed separately from the other changes and forced to clear CI. And then the whole stack becomes what would have been a clean PR in the old model. That, I can kinda see the benefit of. But, merging only part of the stack into trunk is the mental hurdle I can't clear; it'd be like merging only some commits from a PR. It kinda reminds me of when projects used CVS.
I've really only seen stacked PRs used on projects where history is little more than an audit log. I'm keen to see how this gets employed by open source projects. I think there's a disconnect and it's likely I'm not going to really get it until I see it.
Yeah, clean, neatly seperated and logically independent PRs are very nice for reviewers, but usually it requires one to complete the whole feature and then go back and think about the best way to seperate it into a series of smaller changes again. It works for projects like linux where there is tons of motivated manpower such that requiring authors put in a day of additional effort to make a change as presentable as possible is acceptable.
I usually just amend commits as I go and don’t find it all that onerous. Sometimes it gets tricky, particularly if a rebase effectively changes what the code would have looked like. But, with LLMs even that’s gotten much easier.
Ok, then how do you approve/take the first 2 commits and not the last one? Or how do you insert a commit in between 2 commits or address feedback on a given commit?
The person making the change is now going to have to run multiple confusing interactive rebases and git shenanigans, the rewrite the history of the PR branch on every feedback, then you have to re-review all the commits again because they are all different.
It’s possible of course to push all that complexity on the tooling. Have GitHub and git provide tooling for doing all that within the context of a single branch/PR. But why is that better? Multiple branches are easier to manage in git, and as long as they don’t conflict on the merge. Obviously if a feedback on PR#1 causes a conflict in PR#2 which causes a conflict in PR#3 it’s still tedious, but it’s a lot more doable than managing interactive rebases on every feedback comment.
Jujutsu makes the author-side of it all fairly nice, indeed. But the reviewer-side has been so horribly abandoned by github that it has been frustrating me for a long while now.
Regarding reviewing commit-by-commit, I actually do believe a branch is a unit of work to be reviewed, as long as it is fully standalone and implements a usecase end-to-end (no matter how small, and small it should be).
Commits on a branch are a tool for a developer, and they will go back and forth a bit as they learn more about it, perhaps explore a path, and then go back on it.
With bzr (Bazaar, since abandoned by Canonical, but maintainers forked it as Breezy), you had a nested history: top-line merges look like squashed merges in git, but you simply do a bzr log -n1 and get to see the next level of commits in each merged branch and you can understand the build process and explore what other things original author tried out which did not work. It is simply a way to get the best of both worlds IMO (it was noticeably slower than git, though).
I did find it hard to get the product and design to adopt a similar mindset of developing a feature iteratively, so it was usually the developer who'd come up with in-between designs and UX flows while they converge to the final design over multiple small branches.
I bootstrapped two companies in my 20s. While living off savings to get going, $20k in medical would have been the end of that venture. I'm glad it's working out for you. I don't have hard data, but I suspect being so healthy you don't need a doctor favors younger adults without dependents. And being able to afford up to $20k without losing your business implies a certain amount of wealth before getting started. That matches the profile of most tech founders I know -- certainly all of the ones that bootstrap. I only managed to make it work because for the first one I was on my parents' health insurance and for the second I had COBRA and a funded HSA.
If we want to encourage people to start new businesses, some form of universal healthcare would be a massive catalyst. Starting a business is never going to be risk-free, but there's a big difference between risking your retirement or even your house and risking the health of your child.
It's an interesting idea, but it's hard to tell what the native parts are. The home page has a section titled "Native Targets" with an arrow icon that looks like it'd go to some docs, but appears to just be an icon. The running example is a straightforward responsive web page. The docs are centered around UI components for this tool and the lack of a Tree component really makes it look like this is a web framework.
Does it actually generate a native mobile or desktop application? I probably overlooked it, but I couldn't find an example app to build and experiment with locally.
I mean an application that does more than what I can do in a mobile web browser. If it's just a web page I'd rather just do responsive web design. Presumably you've developed this to build native apps with rich functionality.
Very frankly, I’m assuming that you typed something sloppy into AI and asked it to make a big project and a big web page for it, and now you have little or no idea what it did, except that it strung programming concepts together.
I understand why the current website might give that impression, but Dowe was not produced from a single prompt.
Before arriving at this architecture, we experimented with several languages and rendering approaches, including using WebViews for mobile. We ultimately rejected that approach. Dowe now maps its UI components individually to Jetpack Compose on Android and SwiftUI on iOS. The generated mobile applications are native and their source can be inspected.
Desktop is currently different: it packages the generated web/static output inside a native platform window. I don’t want to misrepresent that distinction.
The component model grew out of what we learned while building UiSvelte https://ui-svelte.sappsdev.com, our earlier Svelte UI library with around 80 components. Dowe does not depend on Svelte; that work provided much of the design experience behind its component contracts.
I invite you to evaluate the implementation directly. After installing Dowe, creating and running a project is simply:
dowe init
dowe dev
You can inspect the generated Jetpack Compose and SwiftUI projects under .dowe/apps/android and .dowe/apps/ios. Feedback based on the actual output would be genuinely valuable.
Plus, you know, this thread was about running AI on "lame consumer hardware". There are more power efficient options available.