How so? Practically everything that should be async, can be, and in a straightforward fashion. Biggest pain point was the reliance on generated code that complicated debugging and potentially reduced performance, but this is being addressed in upcoming .NET releases.
It just doesnt generally work how I would expect it to work until you learn the details of how to make it work how you expect. Especially as you get into RX it gets really confusing about which execution context you should be on. And execution contexts in mobile land are pretty convoluted to setup IMO.
So yes "async" is easy, but "multithreaded/parallel" is a lot more error prone and explicit.
EDIT: I should also note I havent been in the space for a few years so Im not fully current on how it looks today
Async carries its own ExecutionContext that crosses threads.
Multi-threaded/parallel is a LOT easier now with the Task Parallel Library (TPL, https://learn.microsoft.com/en-us/dotnet/standard/parallel-p...) and System.Threading.Channels. Channels in particular are nice because it can fan out and then back in to one aggregator, removing the need for self managing synchronization primitives.
I usually default to channels first, TPL when I want threads.
C# async is great. One of the best implementations of cooperative multi threading you can get, IMO.
Greenthreads or what have you are not a replacement if you want to do things like have a UI thread or bind to a native thread for interop. But you _can_ with async/await.
That is the saddest part: there is already a fantastic green thread concurrency for dotnet: hopac. F# then got Task {} and people kind of left hopac behind.
ConcurrentML really brought dotnet's concurrency story into the 1990s.
Yes, there is constant drama but the ecosystem is healthy and you have a choice of multiple upstream "vendors" to hitch your wagon to in terms of your nix experience, and for the the most part they all compile down to the same set of hydra packages so its not really an issue.
Its much easier for the agent to look at a nixos module and decide that it should do `services.nginx.enable = true` vs reverse engineering everything it should do to install nginx on the system.
And likewise if theres an issue then its much more straightforward for it to unwind what it did in nixos vs a traditional software install and not accidentally mess with other users/services on the system.
Right, and yet the openai/anthropic models are still a tier above other options despite everyone gunning for them for at least one if not multiple years. While there are numerous jev-likes being spun up _in less than a month_ that are performing (as far as I can tell) up to and sometimes exceeding jev's accuracy.
This isnt the same as dropbox putting in a bunch of work to make the UX "just work", or even stripe doing the same for payments. This is "send me an api call that is in 1 of 3 forms, and get a response back in this form". The heavy lifting is in making that fast and cheap, and because they havent demonstrated a secret sauce in making it hard to outperform actual results that leaves a lot of room for competitors to get their existing models to run faster and cheaper for the same use case.
I mean, a large majority of "pro jev" posts I see purely focus on the speed/cost and take their word on the accuracy. The entire product is "we guarantee the response will fit this schema, and will do it fast and cheap". Personally, I dont see how anything in this class can be "production ready" as a general classifier without the ability to fine tune on top.
I have been running evals versus other models on my own data. For my use case, Jev comes out on top at least 2/3 of the time. This is purely about accuracy. For cost and speed, it is on top 100% of the time. I agree that people should test their own data against it before blindly assuming that it will get better outcomes.
Great, cant wait for the inevitable "Are you sure you want to grant full disk access" prompts every week for eternity until the user is exasperated and revokes access.
Well in a lot of ways this demo actually is a mix of jev for simple stuff + a very intelligent harness to fill in the rest. Pay attention to the "jev counter" on when api calls actually happen and the kinds of decisions its making. Its very rarely in a tight loop, and when it is (eg in an item menu) it tends to randomly walk through options.
Its very cool, but the harness is doing a _ton_ of heavy lifting.
reply