torginus
Since you don't know if it's going to rain or not, you are going to value it based on how likely each of these events are. Now the weather report came out, and there's not going to be any rain.
The stock market has lots of guards against volatility, but the AI story bypasses all of them - they're saying that AI is the only thing that is going to matter economically, and AI value is exponential - meaning past performance can be discounted, since almost all value resides in the future.
This means that all companies valuations have been reduced to a single dimension - how much companies can contribute to AI, this increases volatility, since now their value is highly correllated with AI
The last cause might be a straight up blocker - certain financial regulations straight up prevent you from giving third parties to your data (esp outside national/EU jurisdiction), no matter what documents you sign.
I was just saying, in my experience, binary formats tend to be easier to parse than text, relying on machine native constructs such as binary integers, sometimes even matching up their stored formats to C struct layouts (this is the case with, Linux's inode format for example).
Whereas complex textual formats such as JSON or Javascript usually have a tokenization and parsing pass. But they are mostly human readable in exchange, which is a ton more engineering effort to build and CPU time to run.
I was just trying trying to say, that once you really get into sophisticated binary formats, you have to take on similar levels of complexity to parsing something like a programming language, meaning that the parser is not simple, or fast, but the file is not human readable either. Which is kinda the worst of both worlds, and doesn't really drastically reduce file size.
TLDR: Text-based formats are fine, expecially for complex data, and are surprisingly competitive with hand-tuned binary formats.
The thing is to get these optimizations, like variable length encoding and tightly packed structs, engineers had to work hard, while a dumb text format gives it for free.
Additionally, they gave up the biggest advantage of binary formats - that they can be mmap-ed directly and read from code.
(And doesn't make very good television either.)
That's a (bad) JS design choice, for example C# doesn't do this. Actually I'm pretty sure even in JS, async/await gets transpiled to state machines, so I think this is easily fixable by shipping a new transpiler implementation that only defers when necessary.
I get your point, but I don't think we should go back to oldschool yield-based iterators to hack around a broken implementation.
And the cost comes from the fact the browser builds its internal lightweight representation of the DOM when parsing and rendering. You can access this optimized happy path when you are manipulating the HTML through innerHTML or with the <template> DOM tag.
Whenever you access the DOM via JS, a proxy object is created by the VM for each node, and manipulation happens through that. This is a fairly substantial memory and bookkeeping cost, which you don't pay with static HTML.
You can
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.
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...