seabrookmx

You're going to need a source for an LLM one-shotting a port of a AAA title from one graphics API to another...

Self-contained != static compilation though. The self-contained binaries still have pretty poor startup time and are large since they contain the whole JIT.

Lots of replies to this comment but a simple answer from my side: compatibility with ASP.NET attribute routing.

Here I am wanting the opposite. I want C# compiled into a static binary like with the GoLang toolchain!

Maybe .NET AOT will get there one day..

Likely not. A lot of debuggers don't work under WSL1 either due to missing syscalls.

I know some folks love the "purity" of WSL 1 but it's really hard to recommend if you care at all about Linux compatibility.

I'm a big C# fan but XML docstrings definitely suck.

We also got stuck with XML-based project files somehow, despite .NET Core/.NET 5+ being a complete rewrite.

It's not any better on the other OS' either. MS hasn't had a sane native app strategy in a decade and the GTK/QT divide remains on Linux.

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.

I just visited this beauty[1] a few weeks ago. Not 400ft tall, but over half that and over 13ft round at the base!

We're lucky to have a handful of big Doug Firs, Sitka Spruce, and Western Red Cedars left on Vancouver Island.

[1]: https://en.wikipedia.org/wiki/Big_Lonely_Doug

Sure, but that doesn't mean it works that way everywhere or is inevitable.

Where I work, a senior would be reprimanded for such behavior. A key metric to their success is how well they can transfer knowledge and teach others, and their peers' feedback is used to determine this.

The senior that "punches down" does not go far in this case.

If that's how it functions where you work, I'd be looking for a new job.

Or maybe corporations hate competition. We'll never know!

I don't disagree with you, but technically speaking MacOS is still proprietary and Asahi is not compatible with the latest and greatest Apple devices.

While they don't _prevent_ Asahi from doing what they're doing, they certainly don't go out of their way to make it easy for them.

I didn't have a single Apple device in my house until a month ago when I bought a Neo. The last Apple devices I had before that were an iPod Nano and a PowerMac G5 many many years ago.

Apple has pretty good competition in every segment with the exception of maybe the iPad, but I'm not a tablet user.

The base PS5 does not have better hardware. Though the PS5 Pro outperforms the Steam Machine and is still cheaper than it..

It supports HDMI CEC, it has a built in dedicated radio for the steam controller, it ships with Steam OS, and will receive support from Valve.

If you are comfortable building a custom PC and fixated on the spec sheet sure, it's not that exciting. But there are some rough edges with PC couch gaming that are sanded off with this machine.

I used TenFourFox to extend the usefulness of my PowerMac G5 for many years, though I last used it about a decade ago. I'd imagine running the modern web on a machine that slow would be painful.

The G5 was actually the last Mac I owned until buying a Neo just for giggles.

Tokio uses a thread pool with work stealing so it is definitely more advanced than Windows 3.1's model!

As other commenters have pointed out, cooperative multitasking is actually a great fit for I/O bound code.

I'm with you. I have the Claude web app pinned as a PWA for quick queries, and then use the CLI for everything project-based.

I did consider experimenting with the Routines feature on the desktop app, but I'm leaning towards whipping together something with cron. I saw another poster here who has a daily PR summary routine that I think would be handy, as I have quite a few repos where I'm a sporadic contributor but would like to keep tabs.

Everyone parrots this but I don't think it's true. The Linux kernel does famously have a stable ABI (we "don't break user space" after all).

The issue is folks expect this to be at a higher level, so when libc or GTK or Qt etc. have breaking changes, all your apps using the old versions fail. This is a legitimate pain point with traditional distros.. I don't want to sound like I'm downplaying it.

However, this is basically solved by flatpak (and others like it, eg snap) which contain _all_ these dependencies in the package. Layering (ala containers) is used for deduplication so you don't have 20 copies of a given GTK version.

While MacOS provides the windowing toolkit etc. at the OS level, it's otherwise similar to how a .app file works. Installers aren't dropping dynamic libraries and resource files all over your disk, the app is "self-contained."

Have you considered flatpak support? I know it's has its rough edges, but I use many apps across arch/Fedora/Ubuntu that are delivered as a single flatpak.

Flatpak mostly solves this for GUI apps.

The DGX spark desktop shipped with Ubuntu, but I haven't seen if it has a bunch of Nvidia specific repos for drivers etc. needed to make it function.

Assuming all that stuff is upstreamed (and they aren't using oddball webcam/input devices etc) it should have much better support than Qualcomm.

Fingers crossed!

Yeah ChromeOS has the same problem. They have a Javascript-native terminal emulator, and a wasm (formerly PNaCL) implementation of open-ssh. But they have to use ChromeOS specific browser extensions in order to allow native TCP connections to port 22 from wasm, and Google only gives themselves this privilege, not any random dev like us.

I'm curious to see if this weird stack gets ported to the Googlebooks or if they just make a mouse-friendly Android app instead.

I've never thought about it that way, but that makes sense!

Sure, in a web server context you'd probably want to instantiate that executor globally and re-use it, Then you could write helper functions around that. But it's still considerably more code and legwork than the async alternative, while also being slower and using more memory if you care about those things.

I said nothing about "stand-alone" services. I'm all about using the right solution to the problem. We run on Kubernetes and have access to message queues. But if all I want to do is make a couple of HTTP calls concurrently, I don't think I should have to manage a thread/process pool to do so, or lean on a message queue or redis based RPC mechanism. In an async context I can do this with a single line of code.

Every rich client-side experience in your browser is written using async code in Javascript or Typescript, as is every electron app. Every developer at my company is comfortable with this pattern, and frameworks like FastAPI make this a similarly smooth experience when using Python.

If async was a solution in search of a problem, it wouldn't have been stolen from C# and added to Rust, Python, Kotlin, etc. The engineering effort required to bring this solution to all these languages is immense, so I'm clearly not the only person seeing value in it.

Say I need the results from two expensive REST API calls, so I want to run them concurrently. Managing a thread pool you find a _better_ experience than

one, two = await asyncio.gather(callOne(), callTwo())

?

Same with the BEAM languages like Erlang, Elixir, and Gleam. Though it still bothers me that they call their green threads "processes".

You not only leave performance on the table (which depending on your use case/environment, may not matter if you can just throw more threads at it) but also some developer ergonomics.

asyncio.gather is a lot less code than having to manage a thread pool or something like Celery with all it's underlying infrastructure.

If you're in an ecosystem where a lot of the async boilerplate is free/cheap (ex: FastAPI) then the developer overhead of sprinkling awaits on your I/O bound calls is pretty low IMO.