Gluber

Basically nothing that i can think of. Especially when it comes to power efficiency...

If its about hardware performance, (e.g for doing ML research on the go ) the Razer Blade 16 or 18 with RTX 5090(mobile) are the best i know of ( and own ). But this comes with way worse battery life ( and of course since the RTX 5090 gives you about 4-6x the performance that a M5 MAX gives you for ML training/inference this is kind of justified)

Sure, thats a good way of working.. I just have the experience when handing over a project ( consulting ) anything i have put in place will never get replaced or kept for too long outgrowing its capacity by far, and offset with huge expenses in hardware or operations. Technically not my problem anymore ( except when it breaks on a maintenance contract ) but i still like to avoid it early if i can

Also to note: (Not a fault of PGVector again just a limit of our algorithmic knowledge) PGVector does HSNW or IVFlat indices ... (there is nothing better persistent) however it breaks down with high latency at LARGE amounts of vectors ( 100MIO+ ) that seems like a high ceiling, but when designing production RAG systems, you tend to do per chunk embeddings, or even visual patch embeddings... e.g one page of a document becomes 1024 vectors in itself (for visual patch embeddings ) ... so you hit those limits at 100000 pages already.. something larger organizations definitly have.

I tend to agree with quite a few points in the article, but some topics warrant some careful scrutiny.

* As a message queue: Only if your required features are very basic, like if you need cluster communication and run your own coordination protocol on top.

* High Volume Time Series: TimeScale works, but composes badly with other workloads on the same DB server ( from an operational perspective at scale )

* Vector Database: The same issues as with TimeScale.. PgVector for example lives in its own seperate "world" and the query planner sees it as a very opaque thing. Forget about adding vector storage to an existing high volume db, that must server other complex queries.. PGVector will either trash your caches, or take over your cpu so that workloads that used to work fine stall. This is IMO not a pgvector problem itself ( Kudos to those guys ) but rather that postgresql extension apis are not very good at exposing custom costs and tradeoffs to the system as a whole.

* Raw Data: Works for small files... why anyone would want to store large amounts of data in it would be a mystery, where it shines is accessing LOTS of small files where internal caching etc help a lot compared to raw filesystem access ( also a bit dependent on the filesystem and its tuning though )

* Microservice: If your service is ONLY exposing json data from some database model, then it should not exist at all IMO. Create a view and be done with it.

In Austria a lot of times as second line ( after melatonin etc ) quetiapine is prescribed for its off label effects.

The guidlines are where i live (Austria) First Colo at 45, if nothing found -> Every 5 years. Once a poly is found and removed get one every 2-3 years.

My take on AI ( at least for coding ) is the same as for dynamic languages ( python,ruby etc )

1. Its a great tool to reduce boilerplate 2. Its great for experimenting with ideas without the overhead that comes with starting a new non trivial project 3. Its great for one offs, demos or anything like that. 4. It helps me to work on some personal side projects that would have never seen the light of day otherwise.

The downsides:

1. As with dynamic languages its a great tool for EXPERT engineers ( not that i am calling me one ) but is often used by Juniors/Entree Level engineers who do not understand the problem, can't tell it exactly what to do, and can't judge the result. And thus it leads to codebases riddled with issues that are hard to find and since they produce a lot of code are a huge liability.

"But look what i made" .... no... no you didn't you don't even understand why its doing something.

I agree with you that these things are important. However they are ( in implementation terms ) rather small issues, and determining i rather pay 4-8x more in development and maintenance costs just for this, while you can go the other way and make those features a bit hardware to implement seems like a not so good business case to me.

e.g we are using Avalonia. Of course everything is drawn in a scalable way, with responsive design etc... Accessibility is built in of course ( with integration with the relevant browser apis ) screenreaders work perfectly as do other accessibility features ) Its not the hap hazard way that flash did this (before there were relevant standards for these features anyways ) Invoking a brower api / interop is easy, the difference is we do not need to compromise our productivity for small things.

The browser platform with HTML/CSS is fundamently legacy over legacy and broken for most application styles ( not general pages ), and incurs insane development costs for even simple things ( been there done that for close to 17 years )

The current best option IMO is: Open Full Browser window size canvas (with webgl, webgpu backend graphics ) and draw everyhing yourself ( meaning with something else than the browser layout engine, lots of options available, Flutter, Avalonia etc... ) and deploy with your favourite programming language through WASM.

In fact a next generation browser should bascially be this, with the legacy browser functionality implemented as a WASM module that draws to this single canvas... The browser would become small and much easiert to secure ( only input, audio and general WASI style apis missing and to secure )

Did your friend get genetic sequencing done on his tumor. There are some recent promising results for braf mutated gbm

Avalonia

Last time i looked Kestrel already uses most of the techniques above ( sans an IOUring backend for Socket ) Almost all allocations are pooled, and zero copy as well. Header parsing is even done with System.Runtime.Intrinsics using SIMD where possible.

The higher level ASP.NET Core stack is also quite efficient and optimized.

BUT: as soon as you gove above the basic middleware pipeline its tends to get bloated and slow. ASP.NET COre MVC is particulary bad.

System.Text.Json is also quite nice, and often is allocation free.

We bascially just us the middleware pipeline and nothing else, and can get millions of requests per second on basic hardware.

Isn't HttpListener still windows only ? I Remember the times we used it and it relied on http.sys on windows...

Or did they port it during NET/NET Core. As Kestrel has been the recommendation from NET Core 1.0 onwards.

It is actually possible, to seperate those things, but it's tricky. Our current product can run in several modes, one with a web ui and api and one without. If running without there is no trace of the ASP.NET Core Pipeline ( and Kestrel is also not running )

We're using ASP.NET Core Minimal APIS for both API and UI (if configured to run in that mode )

Dammit you were first to ask that question :-) I also don't see the difference.