40 karma · joined April 16, 2021
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)
* 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.
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.
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 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 )
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.
Or did they port it during NET/NET Core. As Kestrel has been the recommendation from NET Core 1.0 onwards.
We're using ASP.NET Core Minimal APIS for both API and UI (if configured to run in that mode )
What are the advantages compared to e.g ASP.NET Core Minimal Api ?
(or for example FastEndpoints) ?
1. Microservices are a great tool... IF you have a genuine need for them 2. Decoupling in and on itself with services it not a goal 3. Developers who are bad at writing proper modular code in a monolithic setting will not magically write better code in a Microservice environment.. Rather it will get even worse since APIS ( be it GRPC, Restful or whatever ) are even harder to design 4. Most developers have NO clue about consistency or how to achieve certrain gurantees in a microservice setting ( Fun fact: My first question to developers in that area is: Define your notion of consistency, before be get to the fun stuff like RAFT or PAXOS) 5. You don't have the problems where microservices shine ( e.g banks with a few thounsands RPS ) 6. Your communication overhead will dramatically increase 7. Application A that does not genuinly need microservices will be much cheaper as a monolith with proper code seperation
Right now we have generation of developers and managers who don'T know any better, and just do what everybody else seems to be doing: Microservices and Scrum ... and then wonder why their costs explode.
For juniors which have no experience, any sane methodology is better than none, since otherwise you get even more of a mess.
That said, Clean code has some great advice, some mediocre advice and some frankly bad advice, but the authors point are largely irrelevant to 99 % of software engineering.
A really good developer writes clean code using the right abstraction (finding those tends to take the most time and experience) and drop down to a different level of abstraction for high performance areas where it makes sense.
The fact that bad developers suck and write bad code no matter if they use clean code or not does not reflect on the methodology
1. The technology behind it is in the open, and relatively simple ( the models are well understood, and easy to define ) To replicate that ... (with proper engineering etc a good and small team would probably need 1-3 months ) (The model itself could be built in a day )
2. Training: Here comes the biggie, training the above model on lots and lots of data is what gives it its quality. This is the bulk of time and cost, and also why smaller companies have a hard time replicating this. We are talking trainings costs in the 9 figures.
But 2 does not really matter to those giants tech companies, just smaller competitiors.
I would estimate depending on the desired outcome 3-6 months to replicate ChatGPT for those companies.
Let assume for a task of building a vision model like tesla for autonomous driving, basically taking camera feeds and turning them into 3D geometry.
For that you have to:
1. Collect Data
2. Curate Data
3. Augment Data ( i don't mean classic image augmentation techniques, but for example connecting a simulator to provide artifical data samples )
4. Label data
5. Define your model / or figure out a good model with presets/auto ml techniques
6. Train it at scale
7. Analyze/Test your model, think unit testing but for ml
8. Optimize it to run on edge hardware
9. Deploy it and distribute
All of that with proper A/B Testing, different models, and continously improving/tweaking and adding data.
THere are literally 100s of tools in that space, covering one or multiple steps. But nothing that integrates the whole. It still has an incredible lead time / engineering effort to setup / build a pipeline like that and run it at scale, handle the workflows behind it and also be able to run on premise ( using cloud resources for a lot of that is both a no go for many large companies due to security concerns and cost )
Some cloud SAAS software comes quite close e.g Google Vertex Ai, Sagemaker etc.. But they still fall very short for a production pipeline.
Working in my spare time on various side projects, but i would really enjoy some input of which project to focus on, collaborate on and potentially incorporate.
1. Digital Assistant for on premise installation, already built that as lead architect for a customer of mine but want to take the concept fruther ( think star trek TNG computer )
2. Continous integration platform for ML Models, taking data collection, labelling and training as well as optimization and automate them as much as possible.
For me its a no go to have a language that's bascially a dead end outside of one specific ui framework.. Seems like a solution in search of a problem.
I still cannot comprehed how we ended up with the shitshow that is CSS/HTML. Even Javascript nowadays is a workable language ( or otherwise typescript ) WebAssembly is great... but the actual UI Layer with the DOM and CSS .... just a nightmare
Every time i have to work on something a bit more complex on the browser, i ponder of writing my own UI Toolkit based on Canvas/WebGL or WebGPU and just draw everything myself
1. Build it runtime dependent: ( which requires the NET 6 runtime to be pre installed ) on your computer in order to be able to run: You get a single exe file.
2. Build it self contained: You get a directory with a bunch of dlls and one exe But no runtime needs to be installed on the target computer
3. Build it self contained + single exe: You a get a single exe that embeds all those dlls and unpacks them in memory ( since net 6, in net 5 it would copy them to a temp directory )
4. Build it using AOT Mode: You get a single, statically linked exe. This is probably the closest to a standard Rust (statically linked) build. However AOT mode is not yet official and requires some fiddling still, but should become stable for NET 7 next year. And you loose out on some features obviously like runtime code generation