I watched a video talking about multi thousand times speedup in some cases.
I think this relates to GPI programming however where of course the speedup for highly parallel operations will be prefers of magnitude. But that’s not about the language per se.
You mention coming into this from the ML world, but any mention of timelines to leveraging Python's ML ecosystem seem absent. Any idea what's in the works in that regard?
> The Mojo standard library, compiler, and runtime are not available for local development yet, so we created a hosted development environment where you can try it out. We call it the Mojo Playground! To provide the best experience possible, the Mojo Playground currently supports a limited number of people.
> Sign up for access to the Mojo Playground. When you receive access, log in to the Mojo Playground using the email address you provided in the above form.
A programming language as a service. Exactly what we all needed.
The fire emoji as file extension is odd, complicated, and unprofessional. That's my main take away. (I know .mojo is also supported but it seems you're pushing .[fire emoji] as default.)
An FAQ entry on how it's faster than C would be appreciated.
What does the word "Mojo" has to do with fire to begin with? Is this some new output of meme culture? Do kids today consider the ability to create mojo using stones as the first step towards human civilisation?
Mojo is a word for magic. Meme magic is a thing. Fire emoji is a meme.
That’s my attempt at making the connection.
It also just seems like a fun thing kids do. I don’t even know how to enter an emoji as a file extension so it could be a way to filter out oldsters who don’t know the new ways.
It might have accessibility implications too. An extension which is visually busy, hard to type, and confuses people on screen readers seems like the worst of all worlds.
Love the idea, but it seems right now very much tied to their platform.
If I can't install it and run it on my machine, including in prod, it's a hard sell.
But given the tone of their articles, they seem passionate about it, and genuine, so I want to believe Mojo will be released as a FOSS project in the future and they will make money with the service itself.
How are they supposed to fund the development then?
Open source would have been ideal, but when people ask for open source it's mostly them asking for free. We know that most developers don't truly care about open source beyond the surface level given how popular VSCode is.
If you want to make money and pay rent, Open Source has shown to be disastrous for almost all business models.
I suppose the same way other open source languages fund themselves.
For a language, I think opennness and standards are so important because the usage is broad. The licensing aspects are also important, but I’m even hesitant to use open source languages that are largely run by a single org (eg, Go).
I don’t know if this is a naive statement or you’re saying it with action because basically every open source project with huge adoption have a single org
I generally have the same sentiment, but languages I believe are one place where you can actually make money on consultations and support unlike other types of opensource projects.
I will predict they OSS this within 18 months. They will make money on the execution engine, which people are ignoring, but was a bigger announcement imo.
I've used Python on many large projects over the past 20 years. IME it's been extremely usable for big projects.
Additionally I've consulted on a couple of large Python that were a mess, but on closer inspection, the team was doomed to fail no matter what tool they used, and honestly I think Python just helped them get further than they otherwise would have. :)
"Superset of Python with added features for systems-level code" sounds exactly like Cython. Strange that Cython isn't ever mentioned in any of the comparisons.
There are a few key properties of Python that make it a really great language to develop in, especially at the start of a project: no need to figure out type annotations up front, high signal-to-noise syntax, and Python's absurdly dynamic nature. These all work together to speed development, especially the early stages where you're modelling the program's design.
As the program gels, then it becomes a much better time to nail down precise data types and then 99% of Python programs no longer need an extreme level of dynamicity (dynamicness?). So far, Mojo seems to be getting this right: stay out of my way when I'm roughing things in and rapidly iterating, and then if and when it's needed, I'll happily lock in data types in exchange for more speed, AOT compilation, getting onto a GPU or microcontroller, etc.
So I mostly agree. Python makes it great to start with and iterate. Unlike say golang. What I've found is while python gets you started quickly it also lets you "sprawl" on your bad habits. A team that got into python with little experience in good habits ends up writing a lot of python code, fast that is hard to read and maintain and continue improving without fear. Having moved to golang (for services only) the idioms are more in your face. Frustrating at first but once you pay the tax it is smoothish sailing. Now I could be biased given experience in "general" software design.
49 comments
[ 3.0 ms ] story [ 105 ms ] threadSome of the performance gains look absolutely ludicrous.
I think this relates to GPI programming however where of course the speedup for highly parallel operations will be prefers of magnitude. But that’s not about the language per se.
https://news.ycombinator.com/item?id=35790367
> Sign up for access to the Mojo Playground. When you receive access, log in to the Mojo Playground using the email address you provided in the above form.
A programming language as a service. Exactly what we all needed.
Devs: “The server is down…”
Nowadays easily replicatable with cloud development, Web IDEs and shells.
An FAQ entry on how it's faster than C would be appreciated.
That’s my attempt at making the connection.
It also just seems like a fun thing kids do. I don’t even know how to enter an emoji as a file extension so it could be a way to filter out oldsters who don’t know the new ways.
Like it's meant to be represented as mojo[fire emoji]...
We should strive to make the world more accessible, not less. We can’t even discuss the extension on HN without spelling it out in different ways.
Decisions like that make me very wary about the quality of other decisions made in the language.
God forbid in this era of corporate assimilation any rogue geeks do something unprofessional!
If I can't install it and run it on my machine, including in prod, it's a hard sell.
But given the tone of their articles, they seem passionate about it, and genuine, so I want to believe Mojo will be released as a FOSS project in the future and they will make money with the service itself.
Open source would have been ideal, but when people ask for open source it's mostly them asking for free. We know that most developers don't truly care about open source beyond the surface level given how popular VSCode is.
If you want to make money and pay rent, Open Source has shown to be disastrous for almost all business models.
For a language, I think opennness and standards are so important because the usage is broad. The licensing aspects are also important, but I’m even hesitant to use open source languages that are largely run by a single org (eg, Go).
https://docs.modular.com/mojo/faq.html#will-mojo-be-open-sou...
The closest I get to this is hot-deploying a C dynamic lib compiled with debug on a core C++ engine compiled with release.
That way I get stacktraces from "the moving code" I can read remotely without losing performance (move the heavy parts into the core engine).
The engine needs to be extremely stable for this to work though.
Additionally I've consulted on a couple of large Python that were a mess, but on closer inspection, the team was doomed to fail no matter what tool they used, and honestly I think Python just helped them get further than they otherwise would have. :)
As the program gels, then it becomes a much better time to nail down precise data types and then 99% of Python programs no longer need an extreme level of dynamicity (dynamicness?). So far, Mojo seems to be getting this right: stay out of my way when I'm roughing things in and rapidly iterating, and then if and when it's needed, I'll happily lock in data types in exchange for more speed, AOT compilation, getting onto a GPU or microcontroller, etc.
But can't they just open source it and not accept PRs?