vouwfietsman

AFAIK its theorized much of the GDP growth of the US, as well as the stock market growth of important index funds, is mostly as a result of select tech companies surfing the AI hype.

In that case, a prolonged recession may occur (that would've occurred anyway), and the effect will be felt throughout the economy.

But, again, that's just a general recession being triggered by the AI bubble bursting, i.e. AI no longer propping up the economy, so that's not a bad thing. What the results of that are in terms of severity or impact I wouldn't know, I don't think anyone knows.

I am not a Rust expert either, but just a general remark: using a programming language like Rust as its intended to be used, i.e. functional/imperative programming of the problem domain, does not lend itself well to proving/disproving the kind of statements I showed above.

Yes, you could theoretically generate a Rust program that does not compile if some theorem does not hold, but this is often times (unless the theorem is about types) not a straightforward Rust program for the problem at hand.

I also think that, although Rust is blurring the lines a bit, equating formal verification and type-checking is not a valid stance. A type checker is a specific kind of formal verification that can operate on a program, but it will only ever verify a subset of all hypotheses: those about object types.

I am no expert here what I remember is mostly from CS courses, but isn't the entire point of a formal program proof that you can reason about the combinatorics of all data and validate hypothesis on those?

It's one thing to say: "objects of this type never have value X for field Y", or "this function only works on type U and V", but its a lot more impressive to say "in this program state X and Y are never achieved simultaneously" or "in this program state X is always followed by state Y".

This is super useful for safety systems, because you can express safety in these kinds of functions that are falsifiable by the proof system. E.g: "the ejection seat is only engaged after the cockpit window is ejected" or "if the water level exceeds X the pump is always active within 1 minute".

> In practice, however, LLMs don't seem to have any problem interpreting natural language instructions

I can think of a couple of reasons this may be the case.

1. There is a subset of English that you use unknowingly that has a socially accepted formal definition and so can be used as a substitute for programming language. LLMs have learned this definition. Straying from this subset or expecting a different formal definition will result in errors.

2. The level of detail in your English description is such that ambiguity genuinely does not arise. Unlikely, you would not consider that "natural language".

3. English is not ambiguous when describing program features, and formal definitions can be skipped. Unlikely, because the entire product owner role is built on the frequently exclaimed "that's not what I meant!".

I think its #1, and I think that makes the most sense: through massive statistical data LLMs have learned which natural language instructions cause which modifications in codebases, for a giant amount of generic problems that it has training data on.

The moment you do something new though, all bets are off.

> The time you spend learning Rust is so much time saved afterwards because the language is specifically designed to reduce the risk of programming errors

[Citation needed]

Ok, since you're looking for sincere feedback.

Great vision, challenging the "scale" of current AI solutions is super valid, if only for the reason that humans don't learn like this.

Architecture: despite other comments, I am not so bothered with MMAP (if read only) but rather with the performance claims. If your total db is 13kb you should be answering queries at amazing speeds, because you're just running code on in-cache data at that point. The performance claim at this point means nothing, because what you're doing is not performance intensive.

Claims: A frontal attack on the current paradigm would at least have to include real semantic queries, which I think is not currently what you're doing, you're just doing language analytics like NLP. This is maybe how you intend to solve semantic queries later, but since this is not what you're doing, I think that should be clear from the get-go. Especially because the "scale" of the current AI paradigm has nothing to do with how the tokenization happens, but rather with how the statistical model is trained to answer semantic queries.

Finally, the example of "Find all Greek-origin technical terms" is a poor one because it is exactly the kind of "knowledge graph" question that was answerable before the current AI hype.

Nevertheless, love the effort, good luck!

(oh and btw: I'm not an expert, so if any of this is wrong, please correct me)

I'm not sure why you keep spinning this as a valid response to anything.

This is the full quote of the parent: > As for people getting sick and dying, they either don’t care, or they want people to get sick and die.

Lets break it down. Lets say some of your actions are causing harm, there's basically three options: 1. you don't know this is happening 2. you know, but continue because you don't care, and you can make money not caring 3. you know, and somehow this is beneficial to you, unlikely but possible

(The default option, which is always available, is to stop operations, which they have obviously also not done.)

Since DuPont obviously knew this was causing harm, #1 is out, so #2 and #3 remain. This is just deduction by elimination, not a value judgement.

No amount of spinning this argument is going to change this. I think your last line here makes it obvious who's straw-manning.

Its not what you quoted, and its also still not supporting your point (it starts with or, maybe there's something before the or?).

Couldn't agree more. If tooling would just settle on an arbitrary archive format our lives would be better.

Lance is pretty far from a lingua franca. For instance the SDKs are only Rust/Python/Java, none of which I use.

Though I agree with your point, the idea that cookie banners in any sense contribute to "informed consent" is very debatable.

I think its a bit markety, but they explain it rather well: because of AI your data needs to be consumed by machines on an unprecedented scale, which requires new solutions to problems. Historically we mostly did large input -> small output, now we're doing large input -> large output. The existing tools are (supposedly) not ready.

Although I welcome a parquet successor, I am not particularly interested in a more complicated format. Random access time improvements are nice, but really what I would like just storing multiple tables in a single parquet file.

When I read "possible extension through embedded wasm encoders" I can already imagine the c++ linker hell required to get this thing included in my project.

I also don't think a lot of people need "ai scale".

My guess is that just the raw data size, combined with the physical limitations of your RU, makes it hard for the GPU to be fully utilized. Instead you will always be stuck on CPU (decompressing/interpreting/uploading parquet) or bandwidth (transfer from s3) being the bottleneck.

Seems that they are targeting a low-to-no overhead path from s3 bucket to GPU, by targeting: same compression/faster random access, streamed encoding from S3 while in flight, zero copy to GPU.

Not 100% clear on the details, but I doubt that they can actually saturate the cpu/gpu bus, but rather just saturate the GPU utilization, which is itself dependent on multiple possible bottlenecks but generally not on bus bandwidth.

That's not criticism: it literally means you can't do better unless you improve the GPU utilization of your AI model.

Exactly!

Yes thats a big part, but even bigger is just the alignment of teams.

Imagine team A building feature XYZ Team B is building TUV

one of those features in each team deals with messages, the others are unrelated. At some point in time, both teams have to deploy.

If you have to sync them up just to get the protocol to work, thats an extra complexity in the already complex work of the teams.

If you can ignore this, great!

It becomes even more complex with rolling updates though: not all deployments of a service will have the new code immediately, because you want multiple to be online to scale on demand. This creates an immediate necessary ambiguity in the qeustion: "which version does this service accept?" because its not about the service anymore, but about the deployments.

Jobs: "We hire smart people so they can tell us what to do"

Jobs 10 minutes later: "You did a terrible job because you are a terrible person and you should feel terrible you even exist"

I get that.

The point is that its hard to prevent asymmetry in message versions if you are working with many communicating systems. Lets say four services inter-communicate with some protocol, it is extremely annoying to impose a deployment order where the producer of a message type is the last to upgrade the message schema, as this causes unnecessary dependencies between the release trains of these services. At the same time, one cannot simply say: "I don't know this message version, I will disregard it" because in live systems this will mean the systems go out of sync, data is lost, stuff breaks, etc.

There's probably more issues I haven't mentioned, but long story short: in live, interconnected systems, it becomes important to have intelligent message versioning, i.e: a version number is not enough.

China, India and Vietnam absolutely lead in manufacturing iphones, yes.

That in itself is a critique of C#

The international community is quickly catching up to the fact that what you're saying has not been true for a long time.

I'm not sure if you're in a country that has already received some upgrade, but over here in Europe Siri is seen as a funny tamagochi that sometimes misunderstands and thinks its needed and is then quickly told to shut up.

I think the last time I talked to anyone about siri we were wondering why it was still so bad, now that we have LLMs.

I 100% agree with this sentiment, though its not clear to me at all how close we are.

In general though, advanced automation like AI will disrupt jobs, and unlike previous times, you cannot educate yourself out of a superior intelligence taking your job.

This is not about moving your manual work to another segment where different manual work is not viable to automate economically: its about your mental abilities being insufficient to produce value in the economy, full stop.

If that doesn't scare you, I'm not sure what will. However, its not clear to me yet if all this coding LLM hype will end up destroying coding jobs, or creating debugging jobs.

.... which is not really about UBI, which the post is about.

Because rather than saying: "Maybe you should read all this AI code", or even: "maybe you shouldn't be generating all this AI code", its saying "You're right to generate so much AI code, and you don't have to read it, because you can now get it reviewed by AI!".

Its like making a product to reduce hangover for heroin addicts: yes, maybe it helps, but maybe you shouldn't be a heroin addict?

I was so hoping that this would not be about AI, and actually talk about how we need to do better as an industry and start using objective measures of software quality backed by government standards.

Nope, its about AI code reviewing AI, and how that's a good thing.

Its like everyone suddenly forgot the old adage: "code is a liability".

"We write code twice as fast!" just means "we create liability twice as fast!". It's not a good thing, at all.

> Rust is a system language, so you should have the control you need

I don't think this argument is promising. Its not about the power of the language, but the power of the abstractions you provide over the various GPU APIs.

In fact, I could argue one of the main selling points of Rust (memory safety) has limited applicability in GPU land, because lifetimes are not a thing like they are in CPU land.

I'm sure there's other benefits here, not least the tooling, but certainly the language is not the main selling point...

Certainly impressive that this is possible!

However, for my use cases (running on arbitrary client hardware) I generally distrust any abstractions over the GPU api, as the entire point is to leverage the low level details of the gpu. Treating those details as a nuisance leads to bugs and performance loss, because each target is meaningfully different.

To overcome this, a similar system should be brought forward by the vendors. However, since they failed to settle their arguments, I imagine the platform differences are significant. There are exceptions to this (e.g Angle), but they only arrive at stability by limiting the feature set (and so performance).

Its good that this approach at least allows conditional compilation, that helps for sure.

> Whether it was made for that is immaterial

This is in the talk, he explicitly says that its often brought up that "OOP is made for large teams" "you're not using it as intended" "its not made to model your domain hierarchy" etc etc. The first 30 minutes is his reaction to that, disproving it.

Whether thats true or interesting is a different question, but its explicitly stated in the video, at the start, before he goes into the history.

> This is all nice color on my commentary, but it fails to address the point of my two parent comments: programming is an economic activity

I've mentioned the economics multiple times now, while you're still hung up on performance, I'm not sure why. Again, performance is an indicator of a perceived deeper underlying problem. The underlying problem is not performance, though that's the surface level gripe that is mentioned. There is no part of the argument that advocates you should redesign a specific piece of software to be faster. Rather, the argument is that our collective ability to make good software is deteriorating.

The underlying problem is nebulous and hard to catch and prove because it is hard to reason objectively about a real program in relation to hypothetical other programs that could compete with it. This makes the Muratori/Blow argument similarly nebulous and their (intentional or not) judgmental attitude does not help in the communication. I am aware that this argument is not iron clad or even clear or that the judgmental attitude is in any way warranted.

So, why does it even make sense to talk about this then? Because if there is an alternate universe where we can actually solve the same problems with vastly simpler logical structures, we should strive to make that reality precisely because of the economics, because simpler logical structures beat the pants off complexity in terms of predictability, investment, ROI, etc.

So to summarize, this is the argument (as I perceive it):

1. lots of software is slowing down over time, e.g: same problem is solved with more resources

2. More resources means not just waiting for stuff to be done, but likely also more complexity (resources are spent doing something, hence there is more to be done, hence more complexity).

3. If the same problems are solved by involving increasingly more complex software over time, there is a likelihood that we are writing software (even new software) in a more complex way than necessary, and that its getting worse over time.

4. We should figure out if that observation is true, and what we can do about it, before the cost of building software (economics) becomes prohibitive. (e.g dramatized as the collapse of civilization)

A lot of assumptions are made in 1 and 2.