Company blog of Modular, Chris Lattner's startup behind the Mojo language, covering AI compute, GPU programming, and compilers.
Commenters point to it for Mojo, a Pythonic language for AI, and one calls its piece on why OpenCL failed the best article on that topic.
I guess they could have implemented some of the flags as aliases or rather bash functions to a preset chain of invocations. The merging of flags would be difficult though.
There are many flags that change the behavior of the file system calls that would be made...such as getting additional information.
To support all the formatting commands, the piped output of `ls` would need to be very verbose and structured too...like json or something.
They had to draw boundaries of functionality at some point.
So the unix idea of "one thing" was probably defined a bit more vaguely or more end-user use case related. Convenience seemed to be king.
It would have be nicer if they could have added a shell-like pipe syntax to C (and designed the code in a more modular and stream-like way).
In the `ls` [source code][1] you can see simple blocks of steps like:
if (!file_ignored(file))
{
...
sort_files ();
print_current_files ();
clear_files ();
}
For example the `file_ignored` function in `ls` would have made a nice reusable library (with standardized configuration params) and a cli tool (with standardized flags).
Missed opportunity to unify the shell and C, but I guess SmallTalk was kicking around at that time which went a whole lot further.
It's funny that we are still very much lacking this unification...
We don't have a high-level interpreted language that can also perform well as a system's language.
New systems languages are popping up all…
I think this is a name collision https://mojo.ai/. Any have information on this beyond a screenshot?
This looks related https://www.modular.com/ (currently claims to be playing a "2023 product keynote", but doesn't seem to be doing so).
edit: now seems to be fixed, https://docs.modular.com/mojo/
> With Mojo, you can write portable code that’s faster than C and seamlessly inter-op with the Python ecosystem.
Doubtful. Still reading the docs, but noting
> We don’t want to rely on fancy tricks (like JIT compilers) to make things faster
Reached end of docs. I'm sold.
- Compile time language is ~ the runtime one. That's the model most systems languages seem to have ended up at. It doesn't have macros or reflection, but neither of those seem to be very popular
- The struct/let notation and lifetime model essentially give you C++ semantics with saner syntax. The class/def notation essentially give you python semantics. This is a clean answer to the gradual-typing-for-performance problem
- You can drop into MLIR at will and the std types are implemented like that. This makes the language look a lot like syntactic sugar over writing the IR which closely matches how (at least some) compiler devs think about programming languages
Yeah, I think that'll work. Python/C++ mashup is a popular dev stack and this can make that much cleaner. Faster than C is rather unproven but given the difference in compile time control should be achievable.
> but I don't see it being used for any practical applications
The industry only cares about one thing: ability to market and sell as a means to make money. Ideally a compiler translates human-understandable code into the fastest possible machine-understandable code. Every tech company is essentially a compiler company because they need people to extract the most performance from their software and hardware.
There are a gazillion AI companies nowadays, they all need training or inference to go faster, they all need compiler people. Lattner [0] knows this, and that's why he started Modular AI [1].
If you want attribute grammars to be involved, you need to make them solve this problem better. That's your task. That's the value you bring.
How do you do this? Here are links to items posted over just the last few weeks on HN. Karpathy spells out neural networks [2], so understand the computational problem. Nvidia describes the difference between CPUs and GPUs [3], so understand the spectrum of computational fabrics. Now figure out how to best solve this computational problem given the different fabrics and their differing trade-offs.
Easy.
[0] https://en.wikipedia.org/wiki/Chris_Lattner
[1] https://www.modular.com/
[2] https://news.ycombinator.com/item?id=32491440
[3] https://news.ycombinator.com/item?id=32053502
I’ve said it before and I’ll say it again: Rust feels like a Python developer’s idea of a high-performance computing language. It’s a great language for many kinds of applications — just not when you need to squeeze out every bit of performance from advanced hardware.
Even before getting into SIMD, try using Rust for concurrent, succinct, or external-memory data structures. It quickly becomes clear where the friction is.
Cargo is fantastic — clean, ergonomic, and a joy compared to many toolchains. But it’s much easier to keep things simple when you don’t have to support dozens of AVX-512 variants, AMX, SME, different CUDA generations, ROCm, or any of the other modern hardware capabilities.
Standardising SIMD in the standard library — in Rust or C++ — has always been a questionable idea. Most of these APIs cater to operations that compilers already auto-vectorize reasonably well, and they barely touch the recent capabilities of SIMD. Just consider how hard it is to build any meaningful abstraction over the predicate/register models across AVX-512, SVE, and RVV.
RVV aside, this should illustrate the point: https://www.modular.com/blog/understanding-simd-infinite-complexity-of-trivial-problems
Mojo feels like a great fit for so many domains outside of AI. It could be a killer general purpose language.
It's easy to read and write, offers memory safety without RC or GC or even much mental overhead, will (eventually) be a superset of Python, and it's very performant already.
So far I've been hesitant to invest more time in it when it's pitched as "the programming language for all AI developers", when it's distributed inside the MAX package[1], and when Modular is prioritising features around AI over all else. (I understand why for all these things, I just wish it were otherwise.)
It's great to see the library in the open, but it would be much more compelling for me if Mojo were a separate entity, with its own open site and foundation, to be used by Modular but with more diverse adoption encouraged. Of course it's early days, but I hope it takes on a life more like Rust than Swift (which — despite its potential as a general-purpose language‚ is still largely used in one ecosystem).
1: https://www.modular.com/blog/max-is-here-what-does-that-mean-for-mojo
> On the grand scale of things, Windows is the niche platform here.
They plan Windows support: ” Mojo has supported macOS and Linux for years, and Windows developers have been able to use it through WSL. Native Windows support has always been one of our most common requests from developers.
Millions of developers build on Windows every day, across an enormous range of applications and workloads. We believe Mojo can have a meaningful impact across that ecosystem. Bringing Mojo to Windows the right way requires deep expertise in the platform, which is why we’re delighted that the Microsoft Windows team sees the same opportunity we do — and that we’re working together to make it happen.”
—- https://www.modular.com/blog/modcon-announcements