https://www.tcmit.org/english/research/car/car01

This is the last century version of the item that Asus is presenting here... but with a Gasoline engine.

The Engine is fixed on its own wheel and attached on the side of the bicycle.

This was apparently was a thing. It was used to motorize Japan at its industrialization debut.

On century later, electrification is now a thing and the same device is back with a battery. The loop is done.

PS: I do recommend the museum for anybody interested in industries and industrial processes.

Recursive descenrs parsers are not linear.

They are generally O(n^2) and can even can go exponential with some grammars if written naively.

It can be pretty easy to do adverserival attacks on most naive descent parser and bring it to its knees.

Packrat parser [^1] are linear, but they are by no means "trivial 200 lines" type of parsers.

[^1]: https://arxiv.org/abs/cs/0603077

My son is born at 02h30 right DST change time.

It tooks 3 f*cking days to get his birth registered in the Hospital new birth registration system.

The hospital (at the time) just got digitalized and most systems where not able to agree if he was born after or before DST changes.

PS: I guess he is born fated to be a software QA later on.

One Toyota research center where I worked had robots that would go around the office and propose Snack to people.

While probably not being the most efficient way of using a robot, it definitively brought a smile on the face of many employees.

This is a little bit like someone pointing the moon and you look at the finger.

The formal proof domain goes way beyond just finding bugs.

It has tons of usages in term of functional safety, protocol validation, cryptography, etc...

The fact Mistral tackle this kind of problem is both smart and not so surprising.

Smart because it is niche enough that they do not front face the big competitors (yet).

No so surprising because the French labs have a well known and long time expertise with formal proof tools (Coq and all its Ocaml associated tools). It has been historically mainly pushed by the aerospace and train industries (Airbus, Dassault, Alsthom).

Nope. This is not my experience.

Public pricing in token/$ is only part of the equation.

Mistral tooling to consume significantly less tokens-per-given-task than the Anthropic ones.

My bills currently reflects that.

I am. I use them primarily through their vibe CLI.

Reason is simple: They are cheaper (by almost one order of magnitude compared to Claude) and still do the job pretty well.

For small programming tasks, quick prototyping, refactoring or anything verbose and not requiring a context too large: I first go to Mistral and then eventually to Claude if I'm unsatisfied.

I also found out some of their models to be more responsive than OpenAI ones (which is not so surprising considering the size).

My tasks are mainly C++ and Python programming. People in other languages might not share my enthusiasm.

I mean: do not take this thing too seriously.

It also score Grok the closest from Macron. When someone knows how much Macron and Musk hates each other, it is not without irony.

That's also my feeling. And that's the curse of many VC funded companies. And they are not even in the classical state of enshitification yet.

> Rust is not going to win this market.

Agree. Rust will never win this market. Nor Zig, which has the same genetical flaws as C++ for accelerators (excessive usage of pointer semantics among others).

> Julia, although beautiful attempt, couldn't gather enough support outside academia.

I will look mean, but for me, Julia is a language that never went to the design board. It sticked to a "Let's put Python on top of LLVM and add a proper GC" with one single objective: "let's make a clone of Python but fast".

My feeling is also that it is an academia niche and will remain one.

> In fact, if Nvidia cuTile, Triton, Jax keep delivering, Python seems unmatched at the moment.

It is, and it is honestly pretty depressing.

Triton solves most of the performance issues of Python for accelerators but also introduces one (several on fact) more DSL, one more tooling ecosystem and solves none of the (long list of) issues related to Python/Numpy programming model.

You're right to ramble. I also believe that the world need a high level language fitting for accelerators that is not Python.

However developing something like that is by all means not a trivial task and many failed there.

This was doom to fail from the beginning.

Swift will always have the image of an Apple product binded and controlled by the Apple ecosystem. This is very unlikely to change.

Nobody sane of mind would bind there entire technology stack on something half proprietary with a support was from the beginning secondary outside of Apple platforms.

Practically, they barely pay anything significant.

The lower net salary in Europe / Asia associated with rather high local tax means that most Americans citizens oversea barely own anything significant back to the state.

However it does remain an annoyance to fill the tax declaration every year: I know several American who chose to give up their citizenahip just to avoid this specific issue.

Then you are misinformed.

Because it happens continuously.

Canton executive argumenting again "conseil fédéral".

Local Syndic (Mayor) arguing against Canton decision.

Local parlement trying to address or delay legislation or arguing against Berne ones.

Just open a random news paper.

This is democracy, like it or not.

We live in a world where free open weight-models become competitive with frontier model within a year or two.

It is much more lucrative and proficient in term of business to solve real problems affecting the industries / govs with A.I right now than it is to do the arm race with OpenAI or Anthropic.

That is what Mistral is doing and that served them well so far.

The problem is not regulation and never has been. Regulation is a best a minor stone in the shoes of A.I company in Europe.

The problem is somewhere else: People fails to understand that there is no equivalent in the EU to the unlimited money tap of American VCs and private funding. That's just not a thing here, the investor landscape is much more dry.

Company here just cannot stay unprofitable for 25y while surfing on stocks valuation, it does not work like that in the EU.

And as such they cannot compete with behemoth like OpenAI that burn 80B$ a year of cash while staying afloat.

I do believe the approach of Mistral is the right one: Solve actual problems right now even if not Edge and construct on top of that.

Specially if politically speaking, the White House administration continue to give excellent arguments in favor of sovereignty for the incoming decade. It might be the best strategy they have.

Nor can Switzerland. And still it is one of the best country world wide both in term of living and economically.

Distributed federal power like Switzerland trades quick decision making for resilience.

If it might look up 'messy' on the surface, it is in fact a quality. A very valuable one in fact: because it is exactly what prevent fucked up like Trump to happen in the EU.

It was in the 2000s but not anymore.

If you go to eastern Europe, specially in the Balkans, you will see a lot of taxi drivers with Renault with milages over 500k km. They do hold the space with the usual Toyota Prius.

The current brands in the EU with bad reliability issues are Stellantis with infamous Puretech engine. And BMWs, not so much for the reliability aspect, but due to the stupidly high service costs.

"Frequent" is all relative.

The Renault Zoe, 10y ago, was already using a synchronous engine with wired rotor. And most were going over 150kkm without any issues nor brush changes.

> because the electrical currents that circulate through the rotor windings must generate heat

Currently stator heat in wired synchronous engine is less a problem than in SynRMs with permanent magnets.

Most neodymium based permanent magnets start to be irreversibly damaged id they heat up beyond 100°C. That's currently why Tesla has such a good cooling system in their engine.

Wired rotor are bunch of copper coil, as such they are much more resistant to temperature gradients.

> Some good old habit from C can still be positively used in C++, like the void* pointer and the size parameters.

That's garbage.

There is a clear interest of passing both size AND pointer in a single parameter like `std::span: It bind both value together and guarantee that you do not mess with the size of your buffer.

Pass "data" and "size" parameters through a chain of 5 function calls and there is a non-null probability that you passed "other_size" instead of "size" somewhere. This pattern happens everywhere in old C codebase and has been the source of countless security vulnerabilities and random buffer overflows for decades.

All modern languages (including freaking minimalist Golang) have now a "slice/span" concept built in.

It is not just to annoy programmers (and allow them to complain about 'complexity' in blog posts) but because it is a major improvement in term of memory safety and in term of reducing user errors.

> It seems that some people are really losing the taste for good readable code.

If 'span' or 'span' are unreadable for you. The problem is not span, the problem is you.

These are concepts that has been existing for decades in almost all modern programming languages.

Even in conservative C++, it exists since 2014 in the GSL, in Qt and in boost.

And the interface is no different from vector...no excuse here... It is itself the most basic data-structure in C++.

> Why should people complexify and uglify their C++ code with the uint8_t pointer (or std::byte), when void* works just fine??

Sure. Let's extend the logic: I do propose also to replace all typed arguments with a void* pointer.

Because after all: 'It will just works fine' right ?

Type-safety and clear interface are overrated, we could all use only bytes and remove interface all together to get a closer experience of Fortran 77.

/irony

> Or maybe something even more complicated, like this? > template void DoSomething(std::span data)

First that is non-sense.

If you want to pass a mutable buffer of byte, the correct signature is:

``void DoSomething(std::span data)``

There is no need for template signature here. You are making things up.

Second, there is also no need for the N parameter

``span`` is only used when enforcing a buffer with its size known at compile time is desirable. It can be for vectorization (e.g buffer is a multiple of the SIMD line) or to make it explicit in the interface (e.g for bloc cipher for instance)

> states that the pointer points to input read-only memory (_In_reads_)

You do that by using `std::span` in any C++ codebase.

The fact he brags about that as "an advantage" for separated parameter passing just show currently how little is known here.

> My Pluralsight Courses

The kind of C++ code proposed in this blog post would be straight be refused in any PR in almost any serious organization with a proper review process.

So bragging about it on a blog while proposing some C++ teaching is audacious to say the least.

> To finish on that.

The sad thing is that there would be very valid criticism on `std::span`:

- Span does not do boundary check on access by default. Which is a bad design decision in 2026.

- It has an impact on compilation time due to the header inclusion

- std::byte is annoying to work with because it is a hack around an enum instead of a proper C++ builtin type.

But the blog post misses all these points entirely and sticks to complaining about 'Old C being better' the same way your family Grand-Uncle still brags about 'lead gasoline being better' for his 70s Pontiac.

Your credit card protect you against nothing. Reimbursement in case of fraud is not fraud protection, it is just bare minimal customer service.

In fact, the first thing your bank will do when your credit card number has been leaked and was used for a fraud... is to replace your credit card.

Because they know that, when the number is in the wild, it will happen again. The system is inherently insecure in case of dataleak.

Visa and Mastercard spent decades and millions constructing systems like "3D secure" supposed to protect again that by enforcing external authentication factors. But since the system is not enforced in every country, it is still a problem today.