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.
Microsoft already switched its release support to the "series" model. There are still big games coming out on PS4. With the PS6 expected to be very expensive, we may very well see games simultaneously released on the 4, 5, and 6. We may be moving away from discrete console generations. Older consoles still have a massive library you can cycle through as well.
Yeah, the console companies want to be profitable, but consumers are pushing for new stuff, too. I don't care a whole lot about graphics improvements, but going from HDDs to SSDs was a huge improvement and worth the upgrade for me. And software engineers as a whole have long favored requiring new hardware over optimization for current hardware. I hope the great electronics crunch will curtail that.
The only parts that really feel OLD on previous Sony machines is the load times. Ps4, is fine but you are waiting a little while. Ps3 is painful! You are waiting on a lot of stuff just to swap on and off the HDD or worse pulling from the sluggish Bluray drive.
Once the things is going in a straight direct it is great but it can be tough getting there.
I don’t think the appeal is just to the less technically inclined masses. I’m a developer with a MacBook Pro and a Linux workstation. Proton has come a long way, but consoles just work for the most part; I never have to question whether the game will function and perform well on the console (setting aside the random buggy messes we see).
Then there’s the convenience. I don’t want to play games where I work. I want to play on my TV. I have no interest in moving my workstation into my living room. Streaming with Moonlight works well enough, but there’s still lag. Even if I wanted to move my PC to the living room, the setup isn’t as nice. The Steam Machine has HDMI CEC and can power on with a controller — all the major consoles have had that for years.
Even if I accepted all that, no one else in my household could play anything while I’m working on my computer.
Things are a little weird now. If I’m going to have to go all digital, Steam Family is by far the best option of those with DRM. But, due to the astronomical cost of components, consoles are still pretty attractive.
Can you please elaborate? The recent moves I’ve seen have been announcing a shift to digital-only and another about clawing back movie purchases. Neither are appealing to me, but also aren’t related to game performance or compatibility.
How does that relate to "I never have to question whether the game will function and perform well on the console"?
The point being, if the game says its made for that generation of Playstation, it will run well on that generation of Playstation. There's no comparing specs to figure out if it'll run well on your specific hardware arrangement.
When I get a new Switch game, I know it will play perfectly fine on my Switch as how the developers intended it to be experienced. When I try and play a new game on my PC-gaming handheld, who knows how well it'll run until I try it or spend time reading reviews from others with similar hardware trying to play the same game.
I was talking about game compatibility and you brought up an utterly unrelated point and referenced non-specified “recent moves by Sony”. Forgive me for giving you the benefit of the doubt and inquiring if there were platform changes that would affect compatibility.
Clawing back games isn’t a particularly new risk. If you issue a chargeback, Sony bans your account, losing your library and any wallet funds you may have. And I already indicated that if I have to go all digital, then Steam is far more attractive. But there’s no guarantee any given game I buy on Steam is going to play on any given device. If I purchase a PS5 game I can be fairly certain it will run on a PS5 and what the performance is going to be like.
But, yeah, thanks for reminding me: physical games are still a major benefit for consoles. I buy Switch cartridges almost exclusively because Nintendo's DRM implementation is horrible for a family library. I lend games to friends and family members. I've even sold games and bought used ones. Steam Family is great, and the best of the current DRM options. But, while physical still exists, it's a good reason for favor consoles that has nothing to do with technical acumen.
reply