ptrwis

Not the OP, but yes - just imagine a web server talking to DB over one connection without any connection pooler

When you pair-programming with AI, even Haiku is very good. Just treat is as you assistant.

I'm currently writing simulations of trading algorithms for my own use. I'm using worker_threads + SharedArrayBuffer and running them in Bun. I also tried porting the code to C# and Go, but the execution time ended up being very similar to the Bun version. NodeJS was slower. Only C gave a clear, noticeable performance advantage — but since I haven't written C in a long time, the code became significantly harder to maintain.

You can fix you code 10 times you will fix it.

I'm saying Haiku isn't that bad, it's good enough for my needs, and it's the cheapest one. Maybe it's because I'm giving it small, well defined tasks.

I also use Haiku daily and it's OK. One app is trading simulation algorithm in TypeScript (it implemented bayesian optimisation for me, optimised algorithm to use worker threads). Another one is CRUD app (NextJS, now switched to Vue).

I mean, aren't system calls thread-safe?

Doesn't (honest question) the operating system kernel prevent data races in memory accesses at the level of system calls like brk? I wonder at what level the operating system handles such things?

What do you think, there are milions of people or companies running NetBSD on 486 to protect the planet from e-waste? How many times have you replaced your phone with a newer model in the last 10 years?

Maybe in the future, if the language has very good AI support, security guarantees of the language won't be as important, as it (ai) will find potential bugs well enough. This may be the case with Zig, as the language is simple and consistent, and the lack of macros will make it easier for LLMs to understand the code.

For me it is natural that since the desktop environment is the most important part of the desktop operating system, it should have its own distribution.

For some background, it is now a single guy paid by Microsoft to work on implementing async direct I/O for PostgreSQL (github.com/anarazel)

Maybe such operators for basic linear algebra (for arrays of numbers) should be just built into the language instead of overloading operations. I'm not sure if such a proposal doesn't already exists.

With comp-time reflection you can build frameworks like ORMs or web frameworks. The only trade-off is that you have to include such a library in the form of source code.

let name = $state('blastonico')

SQLite for embedded or desktop apps.

Durable Objects have a bit weird programming model for me, I hope this one will be easier.

In my experience, long polling is more stable and you can enable transfer compression. Maybe it would be good in Blazor to disable the persistent connection completely, having only requests and responses. Often we just want to call a backend method and update the view in response.

In DDR5 you have two memory channels per module.

If you care more about development experience than users, that's fine, but in the case of SPA, JS frameworks will be faster and lighter.

For me the problem with TypeScript is not the language, JS/TS are fine for me, the problem is the entire toolchain - NodeJS, all the node_modules, configuration files, the need to compile.

Maybe Svelte, where they got rid of TypeScript and the types are now in JSDoc, could be a compromise.

My applications run on intranet/VPN behind IIS with Windows Authentication. If not WA, I would always choose Blazor Wasm, it gives you more control over what you do.

When building internal applications, you can make many assumptions - where are your users and how good is their network connection, how many of them do you have - dozens? hundreds? maybe even thousands, but not millions, so scalability is not a problem. Whether the app will be used on a mobile phones or not. Will it be a problem if your application takes 20 seconds to open? :) If the employee will use it half of the day, then probably no.

You can, but then JavaScript frameworks or "old" SSR/MVC are just better.

On the other hand, remote work is very popular today, but if employees want to work remotely, it's their problem to have a good internet. I tested the Blazor server on a poor cellular network where packets could be lost or there were random long delays in packet delivery, and the application was unstable. It was better to set long-polling and enable compression, which is disabled by default. This is also a problem with websockets - messages are not compressed. Long polling again was less resposnsive on good internet connection. I'm curious how this would work in various configurations of quic/http3.

In Blazor Server, for things like drag and drop or any mouse movement events, you should avoid tying them to server-side handlers, but you can also just write JavaScript code. The backend needs to know what to render, not necessarily where, you can keep it on the frontend.

You can also just use Blazor WASM, but I've had trouble setting up Windows Authentication when in Blazor Server it works out of the box.

Blazor is not intended for websites, it is intended for enterprise, intranet CRUD applications with interactive forms, tables, etc. Especially if you already have .Net on the backend. I just finished one such application on Blazor Server and it works great. Programming was easy having previous experience with Angular.

Edit: And the most important advantage, next to productivity, is maintainability, without the entire JS/TS/Node toolkit.

This is cool, Svelte5 may be the lightest signal-based library. I hope that the old, outdated things mentioned at the end of the article will be finally removed in the future. I like it's API for signals more than in SolidJS returning an array with setter and getter.

Except Spring also has its own way of doing beans, people keep forgeting about it.

“Bean” is a broad term. It certainly didn't have a container to run standalone modules as ejb-jars. Spring is just a framework, not an application server with isolated classloaders that the JaveEE application servers were based on.

I stand by my comment, rather Websphere than Kubernets/YAML/WASM. Agree Agree

By my earlier statement I meant that the old JavaEE application servers with standalone EJBs deployed as ejb-jars and JMS were good infrastructure while now JavaEE tries to become the next SpringBoot. In .Net I would prefer to have application servers instead of an operating system performing the same function. Blazor is nicer to use than JSF and Entity Framework than JPA.

Because it's tries to follow trends. The tech is not driving sales guys, they are driving the tech.

I don't know, but maybe these application servers are certified in some way so that they can be used in the right places that require certification (I'm guessing, not sarcastic)? Which would make sense, but some people host applications written in Spring on JavaEE application servers, which is like adding ketchup to a Greek salad. For me, Java EE standardization makes absolutely no sense. You code to common programming interfaces when you need to break them down to use the underlying implementations. Now I code in .Net and at least I don't have such dilemmas.