I have fond memories of riding the one in Duncan BC as a kid! The museum (now labelled a "discovery center" for whatever reason) ha sall sorts of old equipment for kids (and adults) to climb on and gawk at.
X3D is marketed as a gaming feature and benchmarks bear that out. Productivity workloads (video editing, compiling code, etc) benefit very little from the extra cache. You're better off buying a chip without it and a higher core count.
The US is the third largest country by population and disproportionately represented here on hackernews (given it's where ycombinator is based), so it doesn't seem that weird to me.
That said, I am jealous of the micro-center deals as a Canadian!
The use case is niche but there. I ride mountain bikes and off-road motorcycles and have a GoPro on my helmet. A phone is the wrong form factor and a DSLR is too heavy.
Same with surfers, or people who race cars etc. Having a physically small camera, with robust mounting and stabilization is not something a phone in a gimbal or a "real camera" can provide.
Self-contained != static compilation though. The self-contained binaries still have pretty poor startup time and are large since they contain the whole JIT.
I used it recently to write a useful utility related to OpenTelemetry file processing. .NET AOT produced a single-file static binary which is similar in size to what Go would produce, and can be dropped into any target system and run without dependencies, just like Go does.
Reflection, is one thing. Of course some runtime stuff are missing, but the problem is that no one is using source generators before trying out aot, so as soon you try aot you just meet a wall of compilation errors. Most people just want to be able parse a json file without jumping through hoops. Bad DX
The JSON source generators are quite good, and a small performance boost worth considering even when not planning for AOT. The logging and RegEx source generators aren't even for AOT but for improving debugging tools [1] and performance.
Everyone should be exploring source generators already whether or not they expect to try out AOT.
[1] Debugging source generated RegExes is a dream, including being able to breakpoint inside a RegEx in the .g.cs file should you need to trying to get a tricky RegEx right. The code generated by the RegEx Source Generator is incredibly readable and includes great comments that explain what the RegEx does, step by step. Those comments show up as documentation comments on the partial .cs file side once the file is generated and can be used to double check that the RegEx you wrote matches what you expect it to do as you write/update the RegEx and the source gets regenerated (which happens pretty fast).
It works through the new UnsafeAccessorAttribute [1]. This provides the information needed for AOT to know what needs to be in the final binary and not trimmed. It also removes the lookup overhead associated with normal reflection which is very nice.
> Plain old reflection that just works (why should it not?)
I definitely don't fully understand the landscape, so I could certainly be wrong, but I assumed that normal reflection didn't work in AOT because after trimming that method may or may not be there. If it was never called in a normal way then the compiler doesn't know that `Console.WriteLine` was being used as `GetMethod` may have a runtime value as a string rather than a constant value known at compile time. If the compiler didn't know it was being called then it will be trimmed out of the final binary whereas with `UnsafeAccessorAttribute` it provides the information required to not trim it.
Edit: I tried the following https://sharplab.io/#v2:D4AQTAjAsAUCAMACEEB0AlApgMwDaYGMAXAS... and it fails when I provide the type and method for Console.WriteLine as arguments. If I was to add `typeof(Console).GetMethod(args[1], [typeof(string)])!.Invoke(null, ["dummy"]);` to it before the `Type.GetType` call it seems to be enough to not trim out the `Console` type and the `WriteLine` method. The compiler seems to at least be smart that way.
It is not so dishonest, and you explicity added the small "ootb" to your statement. That is the point, out-of-the-box it might not work and you will have to do some refactorings, but if you start a new project with AoT you will keep it in mind.
This is my biggest annoyance with c#. I've always wanted to try to add jsdoc or something in the compiler. Little more annoying than having to use > and < in a comment
I don't understand why people care about Electron? Evaluate the quality of the software based on its own merits IMO. VS Code, Slack, Postman, Obsidian.. I use this software every day and my only complaint is Slack's RAM usage (which honestly has no negative effect on my machine, but just seems silly for a messaging app).
Claude is a buggy mess because it's slop, not because it's electron. Heck, it runs a full Linux VM under the covers without asking.. it's insane.
> don't understand why people care about Electron?
Most Electron apps are crap because they transparently communicate the developer prioritizing their own efficiency over the trade-offs to UX choosing a cross-platform platform entails.
In most cases, I don’t care that an app looks crappy as long as it works. For Anthropic, however, the irony undermines its argument that Claude is ready to replicate developers.
Native apps suck too. i cannot list 10 native mac apps that are truly great, including Apple’s own.
To me these days native on desktop means web, not Appkit. I can resize the whole interface with a common shortcut, I can select text trivially, native Mac apps constantly fail to do both.
Developing native apps for the Mac is a mess, with immature SwiftUI, the absolute garbage liquid glass is on the desktop, the outdated Appkit framework and iOS based Mac Catalyst.
Electron is a sane choice and good enough for Figma, Slack, Notion, leading apps in their respective categories.
reply