Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.
AI / Python

Python Gets Its Mojo Working for AI

Combining the usability of Python with the performance of C, Mojo is a new programming language designed specifically for AI developers.
Jul 3rd, 2023 4:00am by
Featued image for: Python Gets Its Mojo Working for AI
Feature photo by Joe Green on Unsplash

Could Mojo really speed up Python code by a factor of 3,500?

This is a claim being made about this new superset of Python, one tweaked for performance in the artificial intelligence (AI)  space.

Python, like all things software related, is fallible. But now, with open data, and AI development systems exploding in size scope, the drive to solve Python’s performance issues is intensifying.

Currently, the modus operandi is to write as much code in Python as possible and rely on C, Rust, or other performant language wrappers for specifically performant sections of code (i.e. inner loops). Even libraries such as Numpy or PyTorch don’t lean only on Python. Rather, they provide “pythonic” interfaces that allow the developer to write Python but connect to highly optimized numeric libraries.

Alas, always needing two languages — called the two-world problem, or hybrid libraries — adds a thick layer of complexity to debugging. It also makes using large frameworks much more difficult.

And AI makes this a three-world/n-problem. Innovation in the AI world is limited when it comes to programming systems. CUDA is a programming language only compatible with one hardware maker. Several new hardware systems are in development but there’s no uniform language that works with every system. These further fragments programming systems within the AI community.

Lastly, there’s mobile and server deployment which is also a huge category. Challenges in this area include how to control dependencies, how to deploy hermetically compiled “a.out”, and improving multithreading and performance.

Introducing Mojo, a Fast Superset of Python

The Mojo development team didn’t want to add to or create another fragmented ecosystem. Rather they aimed to create a strict superset of Python meaning full compatibility with the Python ecosystem. They specifically do not want to drag up the trauma from the Python 2 to 3 migration.

Though Mojo is a superset, it is also in development as a first-class language. The dev team wanted predictable, low-level performance and low-level control. They also need the ability to deploy subsets of code to accelerators (the host CPU). Mojo developers are embracing the CPython implementation for long-tail ecosystem support. Mojo will look and feel familiar to Python programmers. Mojo will also include new tools that help develop safe and performant systems-level code that would otherwise require C, C++ code below Python.

Chris Lattner started the development of Mojo a while back, by way of an “intermediate representation” (IR), a special language designed specifically for machines to read and write, through the LLVM Linux virtual machine. This development enabled a community of software to work together to provide better programming language functionality across a wider range of hardware. During his time at Apple, Lattner created “syntax sugar for LLVM,” which is a language we know as Swift.

Later, while at Google, Lattner created a Multi-Level Intermediate Representation (MLIR) to replace LLVM’s IR for many-core computing and AI workloads. Lattner went on to create a little more of that “syntax sugar” but this time for MLIR. This became Mojo.

What about that 3500x Claim?

Like everything else in this world, read the fine print. It depends on the hardware. The docs confirm a “yes” but more specifically, “Mojo enables systems-level optimizations and flexibility that unlock the features of any device in a way that Python cannot.” The Mondelbrot benchmarks shown in the launch keynote that made these claims ran on an AWS r7iz.metal-16xl machine.

3500x is a lot. And even if every machine can’t guarantee these numbers doesn’t mean this is a failure. Advertising, amirite?

The Mojo playground is where users can play with Mojo code. The docs were clear that the Mojo playground doesn’t run on the AWS r7iz.metal-16xl machine. The playground runs on a fleet of AWS EC2 C6i instances divided among all active users at any given time. 1 vCPU core is guaranteed per user but more might be available if you’re on at a slow time.

Where Does Mojo Stand Today?

This is the second article in as many months that I wrote about a solution for Python’s performance issues. Maybe Mojo is the front-runner. Maybe another development team is going to do it better or faster. Python is likely going to stay the leading programming language for big data, ML, and AI but it needs help to do the job better. Something is going to act as an intermediary solution.

The development team will open source the language but they didn’t publish a release date yet. The FAQ page also shares a lot of insight into Mojo, Python, and Mojo alternatives for anyone looking for an immediate solution.

Mojo docs writers did an incredible job with spelling out features. Since the language isn’t available yet and is still in development, the docs are the best place to read about them then head on over to the playground and give ‘em a whirl.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.