4,250 karma · joined August 4, 2017
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.
It was unsafe and surprisingly easy to DOS servers using it incorrectly. And by "incorrectly", I mean how a lot of (most?) people used it with user data. An API that happens to be safe by accident when people use it should be deprecated.
Iirc Weidel herself has made statements regarding how the society should always promote heteronormativity.
Or as we say: It it sieg heils like a duck...
ConcurrentML really brought dotnet's concurrency story into the 1990s.
I haven't seen it in many many years, but at the time it struck my giggle button every time.
The only error then is when there are no choices or they set the weights to 0, negative or NaN. I am but a lowly musician though. I can't say I always think floats are simple...
I mean, it can still reason about it, but the code it (Claude and Gemini) frequently doesn't compile and it throws edits onto it until it does. When it then compiles this pretty much c# written in a functional HM-typed sexpr language that lacks classes.
AI has been great help in writing the compiler, though. I got stuck in codegen after having written a lexer, parser and type checker, and not only did it make a faster and better code generator than I ever could, it also made the type checker about 5x fater.
It is really the best corner of the internet.
Now I am generating two bodies for every defun that touches any suspending function, using asyncmethodbuilder, meaning I don't get any of the runtimeasync benefits coming in dotnet11.
Hopefully they'll give us a new asyncmethodbuilder that is somewhat more constrained but guarantees runtime async.
For delimited continuations I only managed to find mostly extremely inefficient ways of doing it. CPS transformations on dotnet are, at least if kept to be useful as delcc, slow as molasses.
Which is ultimately why I chose to compile to c# to use asyncmethodbuilder do do the state machine translation for me.
The colour situation is ok, but us still a bit rough wrt higher order functions.
https://bjolang.koketteriet.se/
It uses local HM inference and traits instead of OO, and the concurrency is based on concurrentML. The design process was mostly about what I dont like about other languages and what I think racket and OCaml does correctly. All default data structures are immutable (using an RRB tree, a champ, b+trees and linked lists) with pretty fast implementations.
Speed wise it is about the same as c# without spans and ref structs, since that is what it compiles to.
Every function that touches IO is compiles in a sync and async variant, so writing "bjoroutines" is most of the time the same as writing regular code.
The GitHub page is borked, since they removed Org mode support a day ago, but the manual and reference can be found on the web page.
Green threads and channels are not anything new. They were all the hype back in the 80s, but the pthreads came and ruined the party. Then we rediscovered them in the 2000s.