torginus

An actual high performance framework should manipulate HTML as a string directly, or through HTML templates (another feature that has existed in most browsers for a decade).

If you're not building a complex application on top of the web stack (interestingly these increasingly use WASM and their own GUI frameworks, so another moot point), but building an interactive consumption website (scrollable lists of static contents), I'd say instead of fronted frameworks, what most people actually would need is Chrome's experimental declarative partial updates:

https://developer.chrome.com/docs/web-platform/declarative-p...

Which basically stream HTML fragments from the web.

As much as possible should be happening locally, synchronously on the computer, in-process, or at least without yielding your thread context (and even then there are things like page faults which async/await wont save you from, they are 'invisible' to a regular developer).

While you might dismiss this idea, page faults used to be THE leading cause of delays back when hard drives were the norm.

https://polymarket.com/predictions/midterms

It also generates copious amount of hazardous waste. Anything that has to do with this degree of material safety hazards should not be a hobby.

Before resin printing, lots of people had a hobby doing resin casts, the forums are full of health-related horror stories, this thing can and will kill you over time.

Generally speaking, on AWS you can buy compute, storage, network and other basic 'goods' and just like a supermarket where you can get either flour and eggs, a cake mix or a ready-made cake, AWS is willing to serve it to you in various levels of ready-ness, and you can start at the level you want, and build your own layers on top if you don't like AWS's solutions.

And AWS's solutions are generally built like that as well, there's no magic to Lambda or Fargate or EKS, its just they run the same EC2s, but with some proprietary magic that lifts some complexity from your shoulders, at the cost of generally some markup, and loss of some otherwise desirable features.

But the core thing is that AWS's offerings are generally solid, so as AI evolves and companies become more willing to take on more complexity, they will move to lower level services, but not necessarily out of AWS itself.

From my interactions with them, is that they really care about customer success, and everything including AI is a means to an end to them.

I think building a cool product with undefined reliability and capabilities, then selling fantasies about what it will possibly be able to do down the line isn't really what they do - or what their customers are paying for.

Your argument suggests that there's a hard cap on AI demand (AI can't do as much as hoped), but currently compute demand far outstrips supply, it's just companies can't pay for it - it's a cashflow problem.

And the point I'm making, is that shovels are sold at min. 5x markup, and the shovel company (Nvidia and others) has no interest in seeing the market collapse, and is willing to use its generous profits to prop it up.

The thing is, these AI GPUs are sold at insane markups - a 5090 was like $1700 MSRP, and a datacenter GPU can't cost like more than triple to make - its just that there's so much demand, that people are paying these markups; thast means these companies are flush with cash, and its in their best interest that their customers don't become insolvent, because then its back to selling GPUs to us rubes, who get sticker shock at 'even' a $1000 price tag.

Therefore they both have the ability and willingness to maintain this forever.

Demand also seems to be there in droves, so the only scenario I can imagine is if datacenter or power infra buildout becomes impossible - plausible, but not what people are worrying about right now.

The fact that it did the things I wanted it to (barely), while allowing me to ignore 90% of the design intent behind it shows it was designed in an opinionated way, just not in the way I cared.

Same goes for C++.

His reasoning was that C was a pretty minimalist language introducing structured control flow and little else, yet it's flexibility and neutrality has allowed people to explore lots of approaches.

C++ on the other hand is highly opinionated, and a lot of its opinions are considered wrong or at least controversial (template metaprogramming, RAII, exceptions, diamond inheritance, just to name a few).

A lot of the C++ community doesn't use these features (for example Chrome, LLVM have exceptions turned off).

Jai on the other hand goes heavily into typed AST macros (along with a reasonably powerful type inference enigne), a very powerful extension of the language, that this language has gotten right - the feeling you get when looking at the docs is 'well, duh it obviously has to be done like this' - considering how long it took devs to arrive at this system suggests this is far less an obvious task than it looks like.

Other than this, what the language offers over C isn't much - it shares Odin's 'context' idea that you can inject an allocator or logger function and have your methods use that - which is kind of the point imo.

Blow, as outspoken and controversial a figure he is; seems to have designed a pretty unopiniated language - something designed for master programmers (like ones he has worked with in the games industry, who worked mostly in C) to express themselves, rather than a set of 'correct' opinions the language imposes on you.

Imo it's a shame it took so long to release, as I'm p. sure Jai would've been much more influential 2-3 decades ago or more, and would've had a good chance to dethrone C++.

There were other weird things like C++/CLI which was a full-fat MSVC fork used to compile C++ either into .NET IL or x86 code which could be embedded into .NET assemblies, but could still call into .NET code.

But what most people think of as .NET (Framework) was definitely using the old MSVC-based JIT

It used to be based on MSVC, with the most expensive optimizations trimmed, things like loop hoisting, devirtualization, generally ones with long runtimes, or ones that required whole program visibility.

But otherwise it was competent, if you wrote code aware of these limitations, it could get very close to even C++, and even on naive code, it was always very competitive (with strange wildcards, that if you used raw pointers, which are an obscure C# feature, you could get code to be even faster, due to the compiler's heritage).

It also helped, that due to MS's nature; C# was meant to be used with MS frameworks, written by people who were aware of the compiler's quirks, which you could learn if you looked at these codebases.

Sure if yo measure against LLVM-compiled static languages, it falls short in certain scenarios, but it's been soldily in the pack of other GC languages like Java or Go, and always has been.

The story sounds like CashApp didn't do proper KYC, so they should be held liable. Also I very much doubt that someone built up a sophisticated operation just for 1 victim, so there must be others. Why doesn't the police connect the dots?

I've been doing a lot of devops lately, writing tons of templates, configs, scripts in like 3 programming languages, wrestling with 'cloud-based' constructs - with LLMs ofc.

LLMs make all this work easy, otherwise it'd be borderline impossible.

It's all BS. Hosting a CRUD app should be an executable for the server (written in boring lang/lib of my choice) + an SQLite db. Of course it's a bit more than that, but not by much.

There are wonderful IDEs and tools out there which help humans do the task, and good design keeps the complexity under control.

LLMs on the other hand both are sources of the mess and solutions to it. Without good tooling you'll be much more inclined to reach for an LLM.

https://synapse.patsnap.com/article/what-is-serum-antiscorpi...

Tbh, I think the issue is that old RPG designers understood players have very different values and goals, hell they even wrote some academic articles on it:

https://en.wikipedia.org/wiki/Bartle_taxonomy_of_player_type...

The devs of today played the games of yesterday, and felt that the game catered to them, and then sought out making a game like that, but they didn't put in the effort or consideration to appeal to other kinds of players.

And turns out there's economics involved - while people playing shooters want to shoot people in general, RPG players are a diverse bunch with different needs, and if you don't scratch the itch of a certain subgroup, that's part of the audience gone.

Which results in a bomb - a game made for 20% of the playerbase will sell 20% of the copies, and will be a flop.

Halo went from <200 people making a game from scratch to >2k people making the same game on an engine (without multiplayer) - so the design scope is even smaller now.

I don't get how you can lower the scope, have 10x the staff, and still overwork yourself - I mean, I certainly think it's possible, but that speaks of colossal mismanagement.

I mean the graphics got better (not that anyone cares, people still play old games, if graphics were a true differentiator, people would say new games are better because they look better, but they don't).

This is very hard to explain - and so expensive it's actively killing the industry.

SMRs are being commercialized. Likewise nuclear cargo ships have been seriously studies. Nuclear reactor powered (not just RTG) satellites have been built.

I know this is beside your point, but I think if we figured out how to commercialize this, demand would come.

But even if we think back to the previous decade or two (sans AI), most of tech has been a a red queen's race - developing and improving stuff, without any real substantial results.

Microservices and orchestration are not better than old monoliths. Electron apps are not better than native. Most programs people actually use have decades-old codebases.

Video games of today don't look substantially better or play different than ones from 15 years ago.

The only answer I could come up with is hedge funds. Everyone else fails some part of my criteria.

Rust also builds a pretty small binary, which is cool. This isn't really meant to be a 'C# is better than Rust' post, but more pointing out that Blazor (which is the official MS implementation) builds huge binaries; often >10MB, which is a real problem. This fixes that.

All other models are also either by <1k labs or side hustles by tech companies who are not particularly known for LLMs

> firmware

Either said 'firmware' is a Windows app, or somebody has Stockholm syndrome