Gemini is required for the context management sub-agent. You can use any of OpenAI, Anthropic, or Gemini for the main planning and coding agents, but GPT-5 performs the best in my experience. Claude 4 Sonnet works well too, but it's about twice as expensive.
Could you help me understand why the remaining 5% is not bit-for-bit reproducible? For example... if you download a tar of sources pinned to a version, and you run `./configure` and `make` in some kind of container and it doesn't embed some kind of timestamp... why are 95% reproducible and some aren't? Would like to learn/understand.
Hashtables keyed off the address of objects would be an example.
On multiple runs, malloc gives out different addresses (thanks to threads or security concerns) which means things end up in different slots in the table. Then you iterate through it in memory order and you're seeing objects in non-deterministic order, which you do things with.
Embedding file paths / timestamps / git shas and similar was popular for a while too and unhelpful for reproducible builds.
Node.js is a runtime, not a language. It is quite capable, but as per usual, it depends on what you need/have/know, ASP.NET Core is a very good choice too.
In my experience ASP.NET 9 is vastly more productive and capable than Node.js. It has a nicer developer experience, it is faster to compile, faster to deploy, faster to start, serves responses faster, it has more "batteries included", etc, etc...
It has terrible half-completed versions of everything, all of which are subtly incompatible with everything else.
I regularly see popular packages that are developed by essentially one person, or a tiny volunteer team that has priorities other than things working.
Something else I noticed is that NPM packages have little to no "foresight" or planning ahead... because they're simply an itch that someone needed to scratch. There's no cohesive vision or corporate plan as a driving force, so you get a random mish-mash of support, compatibility, lifecycle, support, etc...
That's fun, I suppose, if you enjoy a combinatorial explosion of choice and tinkering with compatibility shims all day instead of delivering boring stuff like "business value".
I used to agree but when you have libraries like Mediatr, mass transit and moq going/looking to go paid I’m not confident that the wider ecosystem is in a much better spot.
Node is a lot like PHP of old. Pretty bare-bones, but has lots of other people's code you can use. The problem is most of it doesn't work.
Dotnet is batteries included. It has all the features you'll need, almost. If you need something else, the packages you find are just much higher quality.
It's still single-threaded, it still uses millions of tiny files (making startup very slow), it still has wildly inconsistent basic management because it doesn't have "batteries included", etc...
This is the first I'm hearing of this, and a quick Google search found me a bunch of conflicting "methods" just within the NestJS ecosystem, and no clear indication of which one actually works.
nest build --webpack
nest build --builder=webpack
... and of course I get errors with both of those that I don't get with a plain "nest build". (The error also helpfully specifies only the directory in the source, not the filename! Wtf?)
Is this because NestJS is a "squishy scripting system" designed for hobbyists that edit API controller scripts live on the production server, and this is the first time that it has been actually built, or... is it because webpack has some obscure compatibility issue with a package?
... or is it because I have the "wrong" hieroglyphics in some Typescript config file?
Who knows!
> There's this thing called worker_threads.
Which are not even remotely the same as the .NET runtime and ASP.NET, which have a symmetric threading model where requests are handled on a thread pool by default. Node.js allows "special" computations to be offloaded to workers, but not HTTP requests. These worker threads can only communicate with the main thread through byte buffers!
In .NET land I can simply use a concurrent dictionary or any similar shared data structure... and it just works. Heck, I can process a single IEnumerable, list, or array using parallel workers trivially.
If you read my comment I said there are downsides:
"But yes there are downsides. But the biggest ones you brought up are not true."
My point is.. what you said is NOT true. And even after you're reply, it's still not true. You brought up some downsides in your subsequent reply... but again, your initial reply wasn't true.
That's all. I acknowledge the downsides, but my point remains the same.
No. Because C#, while far from perfect, is still a drastically better language than JS (or even TS), and .NET stdlib comes with a lot of batteries included. Also because the JS package ecosystem is, to put it bluntly, insane; everything breaks all the time. The probability of successfully running a random Node.js project that hasn't been maintained for a few years is rather low.
reply