Readit NewsCouldn't this "dark theme" stuff be mapped onto the user-configurable Win32 color schemes that have been there since the beginning? Did Microsoft break it in Windows 11?
Unlike regular Windows SDK, which lets you make use of the functionality provided by the OS, the WindowsAppSDK is entirely separate from the OS and requires the installation of a separate runtime on the user's machine. It also requires installing nuget packages on your machine to use it so good luck if you'd rather use straight CMake instead of Visual Studio.
As far as I can tell, there's no backwards or forwards compatibility, so the end user has to install the specific version of the SDK your app uses, or you need to bundle all the hundreds of DLLs with your app yourself.
A sane person might ask why not just use Qt (smaller distribution!) or Electron (about the same size) at that point, since they're cross platform and you can easily get fluent themes that look the same as WinUI3?
As far as I can tell there's no sane negative answer to this question. It's not like your app's "fluent theme" will be updated alongside the OS, it's no different from Qt or Electron in this regard.
There's no reason to do "native" windows development anymore, unless you mean using raw Win32 with no dark theme or a custom UI built on Direct2D/3D/Write. And if you are doing that, there's absolutely 0 reason to use this CLI.
The company does highly complex simulation software used by movie studios for explosions and other effects.
He got hired by word of mouth recommendation from someone at the company that had met him.
It takes as much luck as it takes skill to get these sorts of jobs, sadly.
Which leads me to: why is Kotlin implementing this in a non-JVM compatible way, instead of introducing checked exceptions with better language support? All the problems stated above can be avoided while keeping the core idea of checked exceptions, which seems to be the same as this proposal.
From the GitHub discussion, I see this comment (https://github.com/Kotlin/KEEP/discussions/447#discussioncom...):
> The difference between checked exceptions from java and error unions in this proposal is how they are treated. Checked exceptions are exceptions and always interrupt the flow of execution. On the other hand, errors in this proposal are values and can be passed around as values or intentionally ignored or even aggregated enabling the ability to use them in async and awaitAll etc.
But is this a real difference or something that can be emulated mostly syntactically and no deeper than Kotlin's other features (e.g. nullables, getters and setters)? Checked exceptions are also values, and errors can be caught (then ignored or aggregated) but usually interrupt the flow of execution and get propagated like exceptions.
Checked exceptions only make sense for errors that are relatively common (i.e., they aren't really exceptional), which calls for a different implementation entirely where both the happy path and the error path have around the same cost.
This is what modern languages like Rust and Go do as well (and I think Swift as well though don't quote me on that) where only actually exceptional situations (like accessing an array out of bounds) trigger stack unwinding. Rust and Go call these panics but they are implemented like exceptions.
Other errors are just values. They have no special treatment besides syntax sugar. They are a return value like any other and have the same cost. As they aren't exceptional (you need to check them for a reason), it makes no sense to use the exception handling mechanism for them which has massively skewed costs.
Where do you give these guardrails? In the chat or CLAUDE.md?
Basic level information like how to build and test the project belong in CLAUDE.md, it knows to re-check that now and then.
Make a commit.
Give Claude a task that's not particularly open ended, the closer to pure "monkey work" boilerplate nonsense the task is, the better (which is also the sort of code I don't want do deal with myself).
Preferably it should be something that only touches a file or two in the codebase unless it is a trivial refactor (like changing the same method call all over the place)
Make sure it is set to planning mode and let it come up with a plan.
Review the plan.
Let it implement the plan.
If it works, great, move on to review. I've seen it one-shot some pretty annoying tasks like porting code from one platform to another.
If there are obvious mistakes (program doesn't build, tests don't pass, etc.) then a few more iterations usually fix the issue.
If there are subtle mistakes, make a branch and have it try again. If it fails, then this is beyond what it can do, abort the branch and solve the issue myself.
Review and cleanup the code it wrote, it's usually a lot messier than it needs to be. This also allows me to take ownership of the code. I now know what it does and how it works.
I don't bother giving it guidelines or guardrails or anything of the sort, it can't follow them reliably. Even something as simple as "This project uses CMake, build it like this" was repeatedly ignored as it kept trying to invoke the makefile directly and in the wrong folder.
This doesn't save me all that much time since the review and cleanup can take long, but it serves a great unblocker.
I also use it as a rubber duck that can talk back and documentation source. It's pretty good for that.
This idea of having an army of agents all working together on the codebase is hilarious to me. Replace "agents" with "juniors I hired on fiverr with anterograde amnesia" and it's about how well it goes.
Turns out spending some time understanding what your CPU and GPU are actually doing when running your app, and how to make them do less work, leads to pretty speedy software.
Then it also turns out that this does not seem to impede most of the features of the software it is competing with, meaning that software is by definition wasteful.
It can't even be argued that the other software made better use of human resources since it's a large team vs one guy who is often not even getting paid, and the guy is the one with the fast software.
I don't want yet another subscription.
I see that they can still be bought (for now) but I wonder how long that will last.
> A sane person might ask why not just use Qt (smaller distribution!) or Electron (about the same size) at that point, since they're cross platform and you can easily get fluent themes that look the same as WinUI3?
The "good news" about this tool is that it is partly for making it easier to use WinUI3 from Electron, so that you can have both large distributions at the same time.
I thought they had solved the worst problem with WinUI2, a bit like the compatibility library in Android, so you only had to bundle the more "volatile" bits while still delegating most things to the OS.
But then they went and threw all that out the windows (pun intended) with WinUI3 which even has its own separate implementation of DirectWrite for some god forsaken reason.
Unlike the DirectX redistributables of old it's not even backwards compatible so you can't tell people "just download the WinAppSDK runtime", they have to install the specific version you used when developing your app.
You get that download "for free" if you use a .appx, but with a regular installer you're on your own. Even the way apps link to the WindowsAppSDK is a mess with a weird bootstrapping process.
Not worth the headache.