Does the New 'Mojo' Programming Language Offer a Faster Superset of Python? (infoworld.com) 71
InfoWorld explores how the new Mojo program language "resembles Python, how it's different, and what it has to offer."
The newly unveiled Mojo language is being promoted as the best of multiple worlds: the ease of use and clear syntax of Python, with the speed and memory safety of Rust. Those are bold claims, and since Mojo is still in the very early stages of development, it will be some time before users can see for themselves how the language lives up to them. But Mojo's originator — a company named Modular — has provided early access [through a limited-enrollment preview program] to an online playground: a Jupyter Notebook environment where users can run Mojo code and learn about the language's features and behavior...
Mojo can be described as a "superset" of Python. Programs written in Python are valid Mojo programs, although some Python behaviors haven't yet been implemented... It's also possible to use the actual Python runtime for working with existing Python modules, although there is a performance cost. When Mojo introduces new syntax, it's for system-level programming features, chiefly manual memory handling. In other words, you can write Python code (or something almost exactly like it) for casual use cases, then use Mojo for more advanced, performance-intensive programming scenarios... Mojo's other big difference from Python is that Mojo's not interpreted through a runtime, as Python is. Mojo is compiled ahead-of-time to machine-native code, using the LLVM toolchain. To that end, the best performance comes from using features specific to Mojo. Python features are likely to come at the cost of emulating Python's dynamic behaviors, which are inherently slow — or again, by just using the Python runtime.
Many of Mojo's native language features do one of two things. They're either entirely new features not found in Python at all, or expansions of a Python feature that make it more performant, although with less of Python's dynamism.
For example, Mojo has its own fn keyword which defines a function with explicitly-typed and immutable-by-default arguments, and its own struct keyword which is less like a Python class and more like its C/C++ and Rust counterpart "with fixed layouts determined at compile time but optimized for machine-native speed."
But "At a glance, the code closely resembles Python. Even the new Mojo-specific keywords integrate well with existing Python syntax, so you can run your eye down the code and get a general idea of what's happening." And then there's the speed... The notebook demos also give examples of how Mojo code can be accelerated via parallelism, vectorizing, and "tiling" (increasing cache locality for operations). One of the demos, a 128x128 matrix multiplication demo, yielded a claimed 17-times speedup over Python (using the Python runtime in the Mojo playground) by simply running as-is with no special modification. Mojo added 1866x speedup by adding type annotations, 8500x speedup by adding vectorized operations, and 15000x speedup by adding parallelization.
Mojo can be described as a "superset" of Python. Programs written in Python are valid Mojo programs, although some Python behaviors haven't yet been implemented... It's also possible to use the actual Python runtime for working with existing Python modules, although there is a performance cost. When Mojo introduces new syntax, it's for system-level programming features, chiefly manual memory handling. In other words, you can write Python code (or something almost exactly like it) for casual use cases, then use Mojo for more advanced, performance-intensive programming scenarios... Mojo's other big difference from Python is that Mojo's not interpreted through a runtime, as Python is. Mojo is compiled ahead-of-time to machine-native code, using the LLVM toolchain. To that end, the best performance comes from using features specific to Mojo. Python features are likely to come at the cost of emulating Python's dynamic behaviors, which are inherently slow — or again, by just using the Python runtime.
Many of Mojo's native language features do one of two things. They're either entirely new features not found in Python at all, or expansions of a Python feature that make it more performant, although with less of Python's dynamism.
For example, Mojo has its own fn keyword which defines a function with explicitly-typed and immutable-by-default arguments, and its own struct keyword which is less like a Python class and more like its C/C++ and Rust counterpart "with fixed layouts determined at compile time but optimized for machine-native speed."
But "At a glance, the code closely resembles Python. Even the new Mojo-specific keywords integrate well with existing Python syntax, so you can run your eye down the code and get a general idea of what's happening." And then there's the speed... The notebook demos also give examples of how Mojo code can be accelerated via parallelism, vectorizing, and "tiling" (increasing cache locality for operations). One of the demos, a 128x128 matrix multiplication demo, yielded a claimed 17-times speedup over Python (using the Python runtime in the Mojo playground) by simply running as-is with no special modification. Mojo added 1866x speedup by adding type annotations, 8500x speedup by adding vectorized operations, and 15000x speedup by adding parallelization.
Lost it (Score:4, Funny)
I downloaded a copy of it and now I cannot find it.
Re:Lost it (Score:5, Funny)
did you try turning it off and on?
Re: (Score:2)
Language Designers... (Score:4, Interesting)
Re:Language Designers... (Score:4, Interesting)
His last hobby project got acquired by Apple, he has some justification to be optimistic about uptake.
Re: (Score:2)
That is how you know this is a trojan horse. He's trying to convert you to use Mojo instead of Python in the same way he tried to convert Objective C programmers into Swift programmers.
This nonsense again?! (Score:3)
Re: (Score:2)
Does Mojo sponsor Slashdut?
It must be, this is a dupe [slashdot.org] of a dupe [slashdot.org].
Re: (Score:2)
Someone imported JoJo and now it repeats everything 3 or 4 times with slightly different wording.
monetization of python (Score:1)
it's popularity and wide use has many MBAs lying awake at night figuring out how they can monetize it.
Expect a lot of companies to be releasing press releases to figure out what that way might be.
Slashdupe (Score:1)
Tabs or spaces? That's all that matters (Score:1)
Because only some dinosaurus from the past centurt develops a language which applies restrictions based on his government provided 40 character CRT at the expense of the Dutch government because he apparently was fine with wasting tax payers money on his side projects at his department.
Call me when it's complete (Score:3, Insightful)
Mojo can be described as a "superset" of Python. Programs written in Python are valid Mojo programs, although some Python behaviors haven't yet been implemented...
Life is easy when you can choose to not do the hard parts.... https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:3, Insightful)
Indeed. At the moment this thing is a _subset_ of Python and you can bet that they avoided the hard parts as far as possible.
Ambitious but interesting, imo (Score:5, Insightful)
There is an in-depth interview with Chris Lattner about Mojo on the Lex Fridman podcast [youtube.com].
My impression is that the first adopters would not be Python application programmers, but the people maintaining math-heavy libraries such as numpy, pandas and pytorch. Those libraries are currently mixes of Python and C++ and with Mojo it would be possible to write all of it in a single language without losing performance and perhaps even gaining some due to autotuning and wider accelerator support.
Of course, that all depends on Mojo delivering on its planned features before their funding runs out. The plans sound realistic enough to not dismiss them, but far from easy.
Re: Ambitious but interesting, imo (Score:1)
Re: (Score:2)
Is there some drama that I missed? YouTube's algorithm suggested this interview, I watched it and I found it informative, that's all there is to it.
Re: (Score:2)
Lex is fine. He's just not.... discriminate.... about who he interviews leading to a few situations where I'm left to question whether he's a guy whos bookmart but not so wise.
Re: (Score:2)
Anyone who uses the term "disinformation" unironically deserves to be ignored forever.
Re: (Score:2)
The users don't have to abandon Python. The libraries I mentioned currently ship wheels (Python packages) with platform-specific binaries in them. The code for those binaries could be written in Mojo, but the library interface would stick to the Python subset of Mojo. Maybe they would supply some optional Mojo-only modules, but I don't expect them to drop Python compatibility any time soon, if ever.
not what I'm looking for (Score:4, Interesting)
For systems programming I would much prefer a new Bash. Bash is the best programming language - because it's not one.
Bash is great because programmers hate it and users can get shit done with it. Rather than sitting around arguing over some computer science bullshit, Bash just lets a power user string together external programs with some basic logic and useful functionality.
Bash's major downside is the syntax isn't intuitive, so amateurs tend to use it wrong. It also could stand to build in the tools most people use frequently with it, like those that come with BusyBox. And there are some commonly-used functions which there is no portable solution for, that should probably just become a built-in: realpath, JSON/YAML support, Curl, etc.
If somebody could take Bash, merge it with BusyBox and Curl, and add some missing features, I would use that for virtually all programs I write.
Re:not what I'm looking for (Score:4, Funny)
But first we'd need to slap a big, bloated GUI on it that was filled with many unique and interesting bugs.
Then 241 hobbyists could fork it endlessly with no coordination or plan so they could all wreck it together.
Re: (Score:2)
GENIUS
Re: (Score:2)
Yes! We could call it "GENIUS"!
GUI Extended Needlessly Including Useless Snippets
It's perfect, lol. I'll get to work on it tonight so you can fork it right away with incompatible extensions.
Re: (Score:1)
Re: not what I'm looking for (Score:2)
Re: (Score:2)
sssshhhhhhhhhh....... the computer science nerds will hear you! they freak out if something is practical, or has curly braces
Re: not what I'm looking for (Score:4, Insightful)
Re: (Score:2)
If somebody could take Bash, merge it with BusyBox and Curl, and add some missing features, I would use that for virtually all programs I write.
Are you sure you have any clue what you are talking about?
The mods certainly have no clue.
Re: (Score:2)
As someone who has programmed bash scripts for decades, I strongly disagree. Bash is terrible to do almost anything in, once you cross the threshold past the most simple of programs. There are so many cases of "How do I do this complicated thing in Bash" that are answered with "You can do it this way, but it's the ugliest and unsafest thing you'll ever see", that it makes me want to reach out for almost any other language besides Bash.
Bash also
Re: (Score:3)
unsafe? is bash going to cut off your finger?
hugely insecure? because JavaScript and Python is secure by default? remind me again how security works - you just pick the right programming language and all security holes go away?
Re: (Score:2)
Well, I'd guess that 98% of Bash scripts execute commands on some system. Since Bash lacks elegant ways of partitioning arguments to functions and function output, script authors typically rely on hacky workarounds that, combined with inherent problems in Bash parameter expansion, often result in many Bash scripts being prone to exploit, such as doing malicious things when specially-crafted filenames appear in the local filesystem, etc.
Re: (Score:1)
See, this is why programmers are completely out of their minds insane. They think programs need to put on tuxedos and ball gowns. Your claims about Bash scripts being insecure are total bullshit, by the way. Many *all kinds* of programs are prone to exploit. If you think JavaScript and C are some paradigm of secure computing, think again, bucko.
Re: (Score:2)
Now you're just spewing uneducated vitriol.
Let's ask some of the smartest people in America, the students at MIT, how to make Bash scripts secure:
"Writing shell scripts leaves a lot of room to make mistakes, in ways that will cause your scripts to break on certain input, or (if some input is untrusted) open up security vulnerabilities. Here are some tips on how to make your shell scripts safer. Don't: The simplest step is to avoid using shell at all. Many higher-level languages are both easier to write th
Re: (Score:2)
I've been programming for two decades, and doing security research just as long. Programming languages are not secure. They have to be made secure. For *any* programming language, if you use the language wrong, you create insecure code. No language will prevent you from footgunning your own code. You do have to actually use your brain.
"subvert programmer expectations", aka:
"some moron who refused to read the documentation to learn the actual syntax, and instead blundered into trying to write a script with z
Re: (Score:2)
The point is that Bash makes it EXTREMELY easy to write scripts that have negative side effects that are not obvious, with many of those side effects leading to filesystem and operating system-level vulnerabilities. No other programming language makes destroying your system so easy.
I'm sorry, but if you're telling me that it's reasonable to expect a programmer to get a Ph.D. to understand how file system globbing injected into variable expansion could result in complete system compromise, just to be able t
Re: (Score:2)
And a sharp knife makes it easier to cut yourself. So you shouldn't use sharp knives if you don't know how to handle them properly. Does that mean you should not use sharp knives? Professional chefs tend to prefer them. You tell me, are sharp knives terrible? Should we all prepare our meals with butter knives because they lead to fewer cuts?
Re: (Score:2)
I certainly wouldn't want kids to play with sharp knives, just because some adults are proficient with them.
Re: (Score:2)
Bash is awful for anything serious. It's great for a quick bit of glue or whatever, but for anything 'big' you quickly get into a mess of unreable, untestable crap.
I'd love to see a slight increment on it though - as you say, something with some modern workflows built into it, and with some real programming capabilities (eg. unit tests), and preferably something to avoid the "rm -rf ${UNDEFINED_VARIABLE}/*" type problems that Bash seems to attract. But by the time you've done all that, you've probably got a
Re: (Score:2)
Bash is great because programmers hate it and users can get shit done with it. Rather than sitting around arguing over some computer science bullshit, Bash just lets a power user string together external programs with some basic logic and useful functionality.
I agree, this is the best part of Bash.
However, in my experience, if a Bash program grows large enough, it can become a maintenance hassle. If you are doing a lot of processing to figure out what work to do, Bash isn't the best.
And IMHO the worst thin
Re: (Score:2)
As long as you know what it's good for I agree. I've seen some high performance code that was just a shell pipeline. There may have been a lot of start-up options and stuff, the script could even be somewhat complex and more than a one-liner as the user is permitted to configure it; but when you get to the part where it's scanning and processing gigs of data with a hand full of programs written in C, that's where it all comes down to one line and *NIX is optimized to do pipes very fast, and it just works
Nope (Score:4, Insightful)
Next question.
Seriously, it is not about programming languages. These are entirely a side-show today. It is about coder competence. And that sucks in way too many cases. Programming languages will not fix that because they cannot. If they could, that would have happened a while ago. It did not.
The whole "Mojo" (what a pretentious name...) thing is unfinished and currently only a _subset_ of Python works. The benchmarks given are bogus and irrelevant. Sure, it is easy to be faster than Python. Python is not for heavy lifting and that is entirely fine. You get a lot of flexibility in exchange for that. But that also means performance is _not_ a reason to replace Python. If you need heavy lifting with Python, put the core code for that into a C extension module. It is not hard to do for anybody competent. (But see above under "coder competence").
Also, license? "We expect that Mojo will be open-sourced" does not cut it at all. This looks like yet another embrace-extend-extinguish attempt against something that works well.
Re:Nope (Score:5, Interesting)
Seriously, it is not about programming languages. These are entirely a side-show today. It is about coder competence. And that sucks in way too many cases.
If you have a solution for making coders more competent, you can propose it; otherwise you are just pounding the table.
Meanwhile, what we can do is provide coders with tools that make it easier for them to write "good" code and/or harder for them to write "bad" code. There's a reason we use the languages we use today rather than writing everything in assembly language or CPU opcodes. Language matters.
Re: (Score:2)
Seriously, it is not about programming languages. These are entirely a side-show today. It is about coder competence. And that sucks in way too many cases.
If you have a solution for making coders more competent, you can propose it; otherwise you are just pounding the table.
I have done that here often enough. I do not need to repeat it every time I comment on the abysmal skills of the average coder. But it is really simple: Education, certification, liability. Like any engineer or qualified technician in an _established_ tech discipline has. The current amateur crap-show has to stop. FOSS needs some special approaches, but even there most people that write good code can directly prove on-topic qualifications.
Meanwhile, what we can do is provide coders with tools that make it easier for them to write "good" code and/or harder for them to write "bad" code. There's a reason we use the languages we use today rather than writing everything in assembly language or CPU opcodes. Language matters.
Not really. All you do is shift the mistakes to areas where they are
Re: (Score:2)
Assembler code is not inherently more buggy than other code.
Sure it is. Writing assembly is like writing C but without any compile-time type checking. Imagine writing a C or C++ program using only (int) and (void *) as types, rather than defining domain-specific classes and structs to help enforce correct behavior. It's technically possible, but your chances of introducing runtime bugs are much greater because the assembler can't flag your high-level mistakes for you.
That simply is not true (Score:1)
Seriously, it is not about programming languages.
Seriously - it can be.
That's because sometimes the primitives and things a language optimizes for, and incredibly important for some specific tasks.
For trying to to write good ML code, Mojo adds unique capabilities to Mojo to let you use Python for things you'd have to drop down to C++ or C for.
Different languages are good tools for different jobs.
Re: (Score:2)
Along that curve, but one of the biggest downsides of new languages is the toolchain needs to be done for a whole other language.
Things like security tools, 'devops', IDEs, various libraries...
All these things help with respect to 'coder competence' and getting the job done. Half the time a new language is released, I think the 'new stuff' could probably have been done by a library or god forbid a code generator or something. They may not be as ideal, but then you keep the rest of the tool chain in tact.
The
Re: (Score:2)
Something like the jump to VM languages (C#, Java...). But those are rare.
Indeed. It is a major move and that means there must be a set of really convincing reasons. Typically there are not.
Julia (Score:3, Informative)
Julia is a high-level programming language that offers several distinct advantages. First and foremost, Julia combines the ease of use and readability of traditional programming languages with the performance of low-level languages like C or Fortran. It achieves this by utilizing just-in-time (JIT) compilation, enabling fast execution speeds. Additionally, Julia's extensive mathematical and scientific computing capabilities make it an excellent choice for data analysis, modeling, and simulation tasks. Its rich ecosystem of packages and libraries provides a wide range of tools for various domains, from machine learning and optimization to signal processing and visualization. Furthermore, Julia's ability to seamlessly integrate with existing code written in other languages enhances its flexibility and interoperability. Overall, the combination of performance, versatility, and ease of use makes Julia a compelling choice for scientific computing, and data-driven applications, and general programming.
Re: (Score:1)
Julia is much more ambitious in terms of what it was trying to do in order to address scientific computing. That's a blessing and a curse. but ultimately one that I have more confidence in than carrying Python's legacy.
Deja vu all over again (Score:2)
Re: (Score:2)
However we are nearing the end of the era of human written computer programs and the start of the age of AI written programs.
As long as people have to write programs that never have been written before: unlikely. Extremely unlikely.
I work on a toy language. I like to have it to import something like - slightly improved - Java properties files. It takes much more time and effort to tell an AI what I want then to just program it.
AI might help in business programming where e.g. a DB or many DBs already exist,
Re: (Score:2)
However we are nearing the end of the era of human written computer programs and the start of the age of AI written programs. In the next decade the majority of software will be written by machines making manually written programs, no matter how elegant, superfluous.
That's precisely what they said about COBOL.
Language community more important (Score:2)
Modern programming languages all have enough capabilities to accomplish the tasks those languages are suited for. But the language itself isn't what's important, it's the community around the language. If a language is really good at one thing or another, that's great! But without a community of developers to provide tips, examples, and improvements, it's nothing.
Re: Language community more important (Score:1)
Good languages tend to accumulate communities. If it turns out to be useful, it will have a community sooner than you think.
Re: (Score:2)
That is a very naïve view. Great ideas, great inventions, great languages--none of these are enough to lead to success. The idea, invention, language is the easy part. The hard part is selling it.
Apple was not the first to invent a phone that could play music and browse the web. They were just the first to successfully market it. History is full of great ideas--and programming languages--that never went anywhere.
Re: (Score:2)
Some day we'll get even further, and a community for the *language* won't be necessary. Instead, the community will be focused on the problems and the language will be in the background. Language innovation will slow to a trickle, and that'll be a good thing. It will be like music notation. There is a lot of discussion about music, but notation is mostly standardized. I say "mostly" because a few interesting things still come along, like a number of years ago I saw a notation for turntable scratching!
Re: (Score:2)
I like your thinking. It's true that in many ways, language plays too large a role in the software development process. It's also true that over time, language has become less important. Most modern languages have converged around basic concepts, it has become common to expect that any language will have built-in support for things like date arithmetic, threads, event handling, and so on. Once upon a time, you had to build these things yourself.
On the other hand, I don't think language can ever go away comp
Totally overhyped, not open source (Score:2)
There is no reason to bother until they -- perhaps -- decide to open source this. Their current strategy of not allowing download, not opening the source code is just silly and their excuse for doing this is even more silly.
Let's wait and see if the will become a proper, downloadable, open source software. Until then, I am not interested.
Python is not fast ... (Score:2)
...So if you want fast use a fast language ... not Python, and not Mojo ...
Easy answer (Score:2)
> Does the New 'Mojo' Programming Language Offer a Faster Superset of Python?
Betteridge has you covered: no.
Why Not Julia? (Score:1)