Zhenhao Li

Follower of Jesus. Founder of PairTime. Live for truth, love, and freedom.

[Rock the JVM @rockthejvm]

The Scala 3 Macros and Metaprogramming course is out!

This is the most magical stuff you can ever do with #Scala: the ability to manipulate well-typed Scala code at compile time, with Scala!

What's inside, deals and more 🧵

[Gergely Orosz @GergelyOrosz]

Devin (named “the world’s first AI engineer” from the start) and looked to me it’s far more marketing and hype than reality.

But even I didn’t assume how their own staged video would blatantly lie. It does. A software engineer looked closer. Damning:

https://t.co/iKu8yfuFbA

[Arthur Mensch @arthurmensch]

We have heard many extrapolations of Mistral AI’s position on the AI Act, so I’ll clarify.

In its early form, the AI Act was a text about product safety. Product safety laws are beneficial to consumers. Poorly designed use of automated decision-making systems can cause significant damage in many areas. In healthcare, a diagnosis assistant based on a poorly trained prediction system poses risks to the patient. Product safety regulation should be proportional to the risk level of the use case: it is undesirable to regulate entertainment software in the same way as health applications. The original EU AI Act found a reasonable equilibrium in that respect. We firmly believe in hard laws for product safety matters; the many voluntary commitments we see today bear little value.

This should remain the only focus of the AI Act. The EU AI Act now proposes to regulate “foundational models”, i.e. the engine behind some AI applications. We cannot regulate an engine devoid of usage. We don’t regulate the C language because one can use it to develop malware. Instead, we ban malware and strengthen network systems (we regulate usage). Foundational language models provide a higher level of abstraction than the C language for programming computer systems; nothing in their behaviour justifies a change in the regulatory framework.

Enforcing AI product safety will naturally affect the way we develop foundational models. By requiring AI application providers to comply with specific rules, the regulator fosters healthy competition among foundation model providers. It incentivises them to develop models and tools (filters, affordances for aligning models to one's beliefs) that allow for the fast development of safe products. As a small company, we can bring innovation into this space — creating good models and designing appropriate control mechanisms for deploying AI applications is why we founded Mistral. Note that we will eventually supply AI products, and we will craft them for zealous product safety.

With a regulation focusing on product safety, Europe would already have the most protective legislation globally for citizens and consumers. Any foundational model would be affected by second-order regulatory pressure as soon as they are exposed to consumers: to empower diagnostic assistants, entertaining chatbots, and knowledge explorers, foundational models should have controlled biases and outputs.

Recent versions of the AI Act started to address ill-defined “systemic risks”. In essence, the computation of some linear transformations, based on a certain amount of calculation, is now considered dangerous. Discussions around that topic may occur, and we agree that they should accompany the progress of technology. At this stage, they are very philosophical – they anticipate exponential progress in the field, where physics (scaling laws!) predicts diminishing returns with scale and the need for new paradigms. Whatever the content of these discussions, they certainly do not pertain to regulation around product safety. Still, let’s assume they do and go down that path.

The AI Act comes up with the worst taxonomy possible to address systemic risks. The current version has no set rules (beyond the term highly capable) to determine whether a model brings systemic risk and should face heavy or limited regulation. We have been arguing that the least absurd set of rules for determining the capabilities of a model is post-training evaluation (but again, applications should be the focus; it is unrealistic to cover all usages of an engine in a regulatory test), followed by compute threshold (model capabilities being loosely related to compute). In its current format, the EU AI Act establishes no decision criteria. For all its pitfalls, the US Executive Order bears at least the merit of clarity in relying on compute threshold.

The intention of introducing a two-level regulation is virtuous. Its effect is catastrophic. As we understand it, introducing a threshold aims to create a free innovation space for small companies. Yet, it effectively solidifies the existence of two categories of companies: those with the right to scale, i.e., the incumbent that can afford to face heavy compliance requirements, and those that can’t because they lack an army of lawyers, i.e., the newcomers. This signals to everyone that only prominent existing actors can provide state-of-the-art solutions.

Mechanistically, this is highly counterproductive to the rising European AI ecosystem.  To be clear, we are not interested in benefiting from threshold effects: we play in the main league, we don’t need geographical protection, and we simply want rules that do not give an unfair advantage to incumbents (that all happen to be non-European).

Transparency around technology development benefits safety and should be encouraged. Finally, we have been vocal about the benefits of open-sourcing AI technology. This is the best way to subject it to the most rigorous scrutiny. Providing model weights to the community (or even better, developing models in the open end-to-end, which is not something we do yet) should be well regarded by regulators, as it allows for more interpretable and steerable applications. A large community of users can much more efficiently identify the flaws of open models that can propagate to AI applications than an in-house team of red-teamers. Open models can then be corrected, making AI applications safer. The Linux kernel is today deemed safe because millions of eyes have reviewed its code in its 32 years of existence. Tomorrow’s AI systems will be safe because we’ll collectively work on making them controllable. The only validated way of working collectively on software is open-source development.

Long prose, back to building!

[Zhenhao Li @data_fly]

@Ruurtjan Happy birthday!

[StreamNative @streamnativeio]

✨Pulsar Virtual Summit Europe is next week! Register for free and build your agenda today. Don't miss the #ApachePulsar community in action with 5 keynotes and 14 breakout sessions. https://t.co/xy9yRfFbdU

[Zhenhao Li @data_fly]

@jboner I think the Akka team forgot to publish Akka Protobuf 2.8.0 because I got compile error with the new versions. I see the latest Akka Protobuf is still 2.8.0-M6 on Maven.

[Zhenhao Li @data_fly]

@MagnusMadsenDK @scalajos @flixlang Imagine there is a new Apache Spark/Flink supporting the Datalog queries. That can be a gateway of selling the language to enterprises. A second best would be an Akka-like library. Of course, it has to be interoperable with Java.

[Marina @BesseIFunction]

I had Scala coding workshop for 30 kids 8-12yo. They did great! We went from computer memory and how different data types stored in it to Case Classes, functions, Collections and .map. Kids were coding in Scastie.
Below screenshot from code editor of 9yo future engineer 🙂

[Yann LeCun @ylecun]

My unwavering opinion on current (auto-regressive) LLMs
1. They are useful as writing aids.
2. They are "reactive" & don't plan nor reason.
3. They make stuff up or retrieve stuff approximately.
4. That can be mitigated but not fixed by human feedback.
5. Better systems will come

[Zhenhao Li @data_fly]

@rockthejvm Surely they both embrace immutability :)

[Yann LeCun @ylecun]

A New article by ZDnet's @TiernanRayTech on my analysis of recent progress in AI and future opportunities that is considerably more informative and positive than his previous one.

[Domen Kožar @domenkozar]

Today I've been improving Scala support in https://t.co/9d2694cFRx.

https://t.co/U2d4jsPav6

If you're doing Scala development, please let me know, I'd like to make sure things work smoothly now.

[Rock the JVM @rockthejvm]

Eugene is a gem. Highly appreciated in the #Scala small world and passionate about tooling.

This is an unrequested endorsement, but his skills (especially in his combination) are rare.

@IntelliJScala, give him all your money and hire him

[Zhenhao Li @data_fly]

We are now the maintainer of the open-source project https://t.co/PTVaWLMzlH, a tool to build your Scala project in Nix.
Feel free to try it out and give us feedback :)

[Tweag by Modus Create @tweagio]

We're pleased to announce the weekly Nix Hour, a QA-style lecture on Nix hosted by
@infinisil! The first one was done in-person last weekend at #NixCon, whose recording is now available on YouTube https://t.co/qKwcen7u0U. For more information, check out https://t.co/luoHVswJA6

[Veerle Nouwens 温丽玉 @VeerleNouwens]

Dutch news reporting that the Dutch MFA has confirmed the apparent existence of two illegal Chinese police stations in NL - one in Rotterdam and one in Amsterdam - that have been in operation since 2018. https://t.co/Gss0w2FTHi

[NixOS @nixos_org]

Streaming information for #NixCon is now available! 📺

https://t.co/Vd7V1qN6LB

[DevInsideYou @DevInsideYou]

New video with the list of places to search for remote Scala jobs: https://t.co/TTbPwgucst Please RT to help people who are searching!
@scala_lang @ScalaJobsDev @TheFpTower @data_fly @UMATR_io @Signify_Tech @Functionalworks @hackernews @softwaremill @scalac_io @zivergetech

[Zhenhao Li @data_fly]

@Azure Is it ethical to say Azure Cosmos DB API for MongoDB is compatible with MongoDB when you don't support all MongoDB commands and pipeline stages?
I'm calling it out for my client. This costs companies money and time.