Any hope of an integration to Openrouter ?

> All shared libraries depend on the specific glibc version to load them into memory to be able to use that specific glibc version as their C library

That's currently the real core of the problem.

The loader (and libdl) need to be decoupled from the glibc itself under Linux.

Without that, any attempt to ship static binaries (or any binary with a different Libc) will be a source of perpetual pain.

nss plugins and its associated pain (sssd and avahi) are an other examples of that.

libdl is the loader FWIW. It's all one big glibc codebase.

What we name the loader is typically ld.so, more precisely /lib/ld-linux-x86-64.so.2 under x86_64.

But I do agree with you, the glibc is all one giant codebase shipped in one giant blob, dispatch under several names.

Even libdl.so is barely more than a wrapper and some glue around the libc.so itself.

If some of you ever have the occasion to go to the Toyota commemorative Museum, in Nagoya (Aichi), you will find this:

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.

> A simple recursive-descent parser is easy to write by hand and runs in linear time.

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

I can relate:

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.

This commenter says he has different birth dates in different countries' sytems, which is correct if you consider the exact time of birth, but... that's probably a bug? https://news.ycombinator.com/item?id=48853128

> I had a NAO robot (from another great French company) and it walked to employees to motivate them to do some movements.

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.

haha how cool.

Not sure if I’m out of touch (not doing robotics right now) or if things just slowed down. Back in ~2013 it looked like humanoid robots were just around the corner. Boston Dynamics became a hit. Aldebaran’s Pepper was presented. And the DARPA Robotics Challenge was on everyone’s lips.

And then suddenly, nothing.

> It also found the bug that Leanstral 1.5 found and the authors highlighted

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).

> Mistral because it performs the best, by whatever secular metric of your choosing?

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.

Your reason can't be cost because there are superior models that are cheaper than Mistral models, for coding. So i re-ask the question

> Your reason can't be cost because there are superior models that are cheaper than Mistral models

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 think other commenter is talking about smaller/cheaper models like Qwen that outperform mistral on just about every metric

I played with Qwen few months ago, I do prefer Mistral vibe for everyday usage (significantly faster if not self hosted).

Compare to Xiaomi MiMo-V2.5 you will be shocked

> This thing told me Gemini is closest to Anthony Albanese, the current Australian Prime Minister. Is this a geolocation thing

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.

> sorry for rambling.

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.

Though, Modular should have been the team to do it. My theory is that they raised too much money too soon. With that kind of money, you get anxious investors waiting to see some magic on quarterly timelines. So Modular was forced to be compatible with Python as there's no other way to win quick developer mindshare. (Though I don't think they managed to do that either).

A closest counter path I would have expected Modular to follow was Zig or Oxide computers (I know not apples to apples comparision). Start actually attacking the problem with hindsight and lessons of 30 years of Python, build something fresh, and try to patiently win the market.

Rust is not going to win this market. The language has too much syntax friction to win over data science/AI folks and doesn't offer too much in parallel programming world. Julia, although beautiful attempt, couldn't gather enough support outside academia.

In fact, if Nvidia cuTile, Triton, Jax keep delivering, Python seems unmatched at the moment. It is likely to be in the similar position that C/C++ have been in embedded and firmware world.

Julia and the Python JITs from GPU vendors will.

Mojo already lost the moment AMD, NVIDIA and Intel decided to fully support Python and Julia.

Additionally all of the parallel programming improvements in ISO C++ are coming from them as well, Modular did not have much moat when being a follower and not a driver.

How did Mojo already lose when Qualcomm just made a $4B bet on it? You're forgetting that the language is still pre-1.0. The way I think of this... if Modular is able to remain an open platform, being part of an established corporation with existing customers is a better way to drive penetration compared to acquiring new customers.

I'm not really sure if Mojo has lost or not, but the community has felt quite different than other language communities I have encountered. The development feels less organic and more driven by venture capital. This is most acutely felt in the current closed source development of mojo itself, which seems like it will continue into the near future.

I look forward to seeing open source mojo and the community that will bring.

> The development feels less organic and more driven by venture capital

The development has been driven by the needs of Modular.

> This is most acutely felt in the current closed source development of mojo itself

Mojo compiler is closed, the language development is quite open. Some of the proposed changes have been shelved or tweaked based on community feedback. However, you should understand that the compiler is closed to avoid design by committee and bike-shedding, Modular will and does veto decisions on core language semantics, see: https://forum.modular.com/t/canonicalize-apis-around-int/253...

> which seems like it will continue into the near future.

The compiler is getting opened this August. I must admit, a lot of people who would be normally interested in the language are hesitant to poke at it with a stick with the current license (myself included).

The language has really great set of features and functionalities wrapped in a familiar syntax, I have zero doubt it'll reach mainstream adoption.

> I have zero doubt it'll reach mainstream adoption

Be careful. I said this 10 years ago about OpenCL, and I've ate crow ever since.

> I have zero doubt it'll reach mainstream adoption.

I'll gladly put $1000 in escrow as a bet that it never reaches more than 1% on literally any index of your choosing (TIOBE or whatever)

The founders won the lottery, the language most likely will never make mainstream.

Ha! I think whether Mojo will make mainstream or not is already a forgone conclusion. It solves too much of a technical problem to be niche. To me, it is a matter of when... not if.

It is not the only solution to that technical problem though. Past attempts at this have shown a clear preference for solutions that actually are extensions of CPython rather than distinct tool chains.

Past attempts at what exactly, I'm not sure I follow. Are you talking about two-language problem, heterogenous compute, or cross-platform accerelated compute stack?

With Qualcomm doubtful, but good news for the founders.

> How did Mojo already lose when Qualcomm just made a $4B bet on it?

NVDA market cap is $4.7T.

The difference between a billion and a trillion is roughly a trillion.

> My theory is that they raised too much money too soon.

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.

I think this is unfair to Julia. It has a strong lisp lineage, the just ahead of time compilation model is interesting and I think they were the first to make it work.

I agree that it's lacking in many ways, but it's not just Python on LLVM.

I do not think Julia ever intended to be a Python clone. Julia was created in 2009 when Python was not as popular as today.

I think the statement is a strange one to make about a language that emerged from a PhD thesis. While one could say the objectives of Julia's design were academic (e.g. multiple dispatch) and more attention could have been paid to the practical application of the approach (e.g. where and how do we cache all this machine code we are generating), I find it incredulous to say a six year long PhD dissertation process was not a design phase.

The thesis in question can be found here: https://github.com/JeffBezanson/phdthesis/blob/master/main.p...

Lisp, see Connection Machine and Star Lisp.

Several decades of their time.

Best of all, it is actually compiled without JIT drama.

This is the reasoning behind the guys that have created a whole new Common Lisp frontend to LLVM for biochemistry research at MIT.

What is the drama with JIT? Vs AoT?

The JIT adoption drama in Python versus other programming languages ecosystems, equally dynamic.