what are you talking about? even without aot, dotnet offers pretty stellar performance.

i have been seeing a lot better performance, to be honest. It allocates a LOT less.

when I realised I didn't have time to actually finish my own programming language (there was a big change needed in the type checker and it would have taken months with how much I can use a computer atm), I let claude something like 98% of the work, and it worked very well. The code comments are awful, but the code is ok. recently i have just let it have a go, and the code has grown more than I care for, but generally it has been doing well: https://github.com/bjoli/Bjolang

Go isn't as much fun. And is usually slower for my work until I bump up the GC and then it uses roughly the same amount of memory.

I have also found c# async to be lighter than go's concurrency story, and dotnet11 is going to make that much more clear.

Now: I write software for fun, not for money.

So for a requirement where both golang and .net would suffice, would you choose .Net over golang?

Yes. Unless I really need CSP, but then I would much rather use f#+hopac because CML is the bee's knees.

For general concurrency where async doesn't suffice, go is nicer than C#, but hopac is nicer than go.

If go had proper concurrentML I am pretty sure I would use go a lot more. Again: this is for hobby projects where I get to choose freely.

Based Hopac enjoyer. I built the Spiral's language server using it. I have to admit though that these days I just use native .NET channels for all my message passing needs.

I vastly prefer cml, but hopac has a lot of missed opportunities. I vibe coded my own language on top of c# that has a cml that is much more integrated with the language (and no other constructs are available :)). Being able to use events for things like reading from ports, so that you can select over reads and only the winning read actually takes anything from the port is more than nice to have. Or having STM that can be run as an event, so that you can choose over a transaction or a timeout in extreme congestion. Since it is composable, you can abstract away a lot of the details behind simple function calls.

I am kind of curious if it becomes faster when moving to dotnet11.

I thought it was pretty well established that JXL has a big room for improvement when it comes to encoders. There are some fundamental limitations wrt the absolute lowest bitrates, but that the room for improvement in encoders is rather substantial, especially with things like rate-distortion search heuristics.

The comparison is more about who has had the most man-hours and megadollars put into encoders quality than about the inherent limitations about the format.

With that said, I use AVIF, but I do have what can be said to be an irrational preference for JXL.

> but I do have what can be said to be an irrational preference for JXL.

Is it irrational to follow the collective "one format to rule them all" dream? Sure, the codec itself needs work, but seeing how long we've been stuck with the JPEG/PNG/GIF trio (even with better encoders like mozjpeg/jpegli or optipng/zopfli) with TIFF as a catch-all backup, getting the format right once and for all really matters.

I'm still weirded by the low amount of workforce in libjxl/jxl-rs; sure, too many cooks do ruin the broth, but too few too, in that domain.

Aren't get-in and update-in a poor man's lenses? I find similar abstractions in most functional languages.

I am just sad core.async is just the same old CSP.

I want to scream every time I have to implement nacks in CSP. It has to be domain specific every time, since there are no first class events.

I do agree that clojure gets a lot right (like an actually well integrated STM layer), the choice to go with CSP seems like a missed opportunity.

Do you also happen to support the Motorola "shake to turn the flashlight on".

Every time I buy sometning that is not Motorola I regret it, and it is like 85% because of this feature. I don't know how they do it, but it triggers reliably, never misfires.

People always suggest apps that supposedly should allow the same thing, but they never work, which makes me think Motorola uses some lower level sensor access to do it.

I've used a lot of smart phones over the years. They always, always, have a pile of supposedly useful, ergonomic, gestures or shakes or whatever that do stuff. I have never actually reliably started using them and stuck with them until my partner got a Motorola device.

Shake to flashlight is the perfect combination of easy to remember, easy to trigger, and actually useful. It should be industry standard.

There are 2 features I missed when I went to Pixel phones from Motorola: shake on flashlight and twist on camera.

On a hike a few moons ago, as I approached a scenic overlook, another hiker pulled out their phone, twisted it, and took a picture. We had a brief conversation about our love for Motorola gestures.

If Motorola comes out with a lower priced phone with GrapheneOS and a Pixel quality camera or better, I'm there.

I've been a loyal Motorola customer for almost 10 years now, mainly because of this feature.

So, many people dont know this, but if you ever meet someone who says measles is natural and strengthens the body tell them about immunological amnesia. Measles in unvaccinated people will damage the immune system for a long time.

People that have had a measles infection will have a significantly higher rate of infection for something like 2-3 years post-measles. You can get things like varicella again. Even EBV (missing disease) can re-emerge, and often sensitivity to influenza increases dramatically.

If you have Bern vaccinated against polio, you will usually need another shot.

A friend of mine, an immunologist, use to say: the idea that an infection makes you stronger only ever (if at all) applies to bacterial infections. With viruses "the fewer infections the better" is true enough that I can stand behind it in my professional role. Even common virus infections can mess you up for a long long time.

I agree, but I prefer something more immediate and scary: From https://jamanetwork.com/journals/jama/article-abstract/28377...

> As of July 23, 2025, a total of 1319 cases have been reported, mostly (92%) among unvaccinated people or those with unknown vaccination status; 165 cases (13%) required hospitalization and 3 patients died (2 unvaccinated school-age children and 1 unvaccinated adult).

My question is, did it provide POCs? I have had some security issues flagged that I tried my best to exploit, but failed miserably. Since I do not have any kind of privileged access the LLMs I use have been unwilling to actually prove that it can be exploited.

While I did fix most of the things because while they might not have been exploitable they were bugs waiting to happen, in all but one case I haven't been very impressed by any of the LARGE IMPORTANT SECURITY HOLES that were found.

No, the Mythos reports do not come with POCs. It's a lot of redundant prose explaining the bug it found (much more than I'm willing to read), it explains how it can be triggered, but doesn't generate actual exploit code.

But that doesn't matter for me. It shows me real bugs and less than 1% false positives. Some bugs are truly nasty and urgent, most are trivial and not exploitable at all, but they're bugs and so I'm fixing them.

Mythos isn't mythically superb for being the best LLM model, but only for not having these annoying guard rails that make all others randomly refuse to cooperate when you need them the most. Whoever invented guard rails - please stop! - they just slow the good guys down in the race.

Ah, Askell's work: https://mcauldronism.substack.com/p/an-automated-takedown-of...

While it is certainly good to do estimation oneself and not just blindly follow whatever the LLM outputs, keep in mind the recent PHP-related events ... Just because at some point one is not able to make a PoC, it doesn't mean, that no one else ever will be.