Parsing PNG Images in Mojo(fnands.com)
fnands.com
Parsing PNG Images in Mojo
https://fnands.com/blog/2024/mojo-png-parsing/
18 comments
Hacker news predictions (and sentiments) about new technology always fall flat on its face.
You tried a new language that made it obvious it was still very early and evolving fast, then based your whole prediction of this language's future on this early alpha version.
Typical
You tried a new language that made it obvious it was still very early and evolving fast, then based your whole prediction of this language's future on this early alpha version.
Typical
It's a new language that has a very clear structural relationship to another language. Unless they change direction it's possible to reason about its future.
Rust now looks pretty similar to the Rust I first used in 2015-ish, surprise?
Rust now looks pretty similar to the Rust I first used in 2015-ish, surprise?
Rust was started in 2006, it had already undergone 9 years of development by 2015. in fact, it reached stability in 2015.
According to Mojo's changelog, it was started in September 2022, which makes it less than 2 years old in active development... but even then, it'll look a lot like its final form by year's end.
According to Mojo's changelog, it was started in September 2022, which makes it less than 2 years old in active development... but even then, it'll look a lot like its final form by year's end.
> Hacker news predictions (and sentiments) about new technology always fall flat on its face.
Frankly, most new tech falls flat on it's face.
Take a look at Wikpedia's list of programming languages created in the past 14 years. There's some winners, true, but there's plenty of cruft.
https://en.wikipedia.org/wiki/Timeline_of_programming_langua...
You this optimistic about Carbon as well?
Frankly, most new tech falls flat on it's face.
Take a look at Wikpedia's list of programming languages created in the past 14 years. There's some winners, true, but there's plenty of cruft.
https://en.wikipedia.org/wiki/Timeline_of_programming_langua...
You this optimistic about Carbon as well?
I am not sure what other options are really on the table. I have several grievances with Python, but it has the biggest community. If I want a library for...well anything, there is going to be one written in Python. Stuck on a problem? There is probably a blog post or SO thread from someone in the exact same situation.
Bootstrapping a new scripting language sounds incredibly difficult unless you have the cash or mindshare to get others to follow. Which is unfortunate, because I think a new language with lessons learned since Python could have a lot of performance and usability improvements vs where we are now.
Bootstrapping a new scripting language sounds incredibly difficult unless you have the cash or mindshare to get others to follow. Which is unfortunate, because I think a new language with lessons learned since Python could have a lot of performance and usability improvements vs where we are now.
This looks nice to me. Sort of reminds me of cython and to a lesser extent nim. And I sort of like cython, except I rarely end up using it in practice because I find that you end up dealing with three languages - python, cython and C - or even four, if you're also trying to use C++. (At least back when I was using it, direct cython to C++ interfacing wasn't available yet). And the borders between them were a bit fuzzy sometimes - you'd have to see the compiled C output to find out where you forgot to cdef a variable. If you use pybind11 then you just have to deal with python and C++ (though admittedly the metatemplate programming used for wrapping is a bit of wizardry).
So getting better performance in a single python-ish language with a bit of extra syntax seems promising to me, but I admit I've yet to try this. I'll wait to see if a good ecosystem gets built around it.
So getting better performance in a single python-ish language with a bit of extra syntax seems promising to me, but I admit I've yet to try this. I'll wait to see if a good ecosystem gets built around it.
Chris Lattner expects the language to be really usable by the end of this year, so maybe check it out early next year.
Excited to see what Mojo will look like by the end of the year.
I know it is not technically Python, but seeing `list` used as a parameter made my eye twitch.
Meh. Just use C# and its cross-platform SIMD API instead.
These will guarantee you the performance, might even be terser, certainly easier to deploy, and actually open-source.
These will guarantee you the performance, might even be terser, certainly easier to deploy, and actually open-source.
Won't help you much if your goal is to learn Mojo.
Fair enough, though I'd argue - don't, F# is well-loved by certain research labs for these use cases :)
But then you have to be capable of stomaching Dotnet. Modern C++ is the best tool for this job, currently.
I started using F# late last year in a *nix environment and it is really well done. There's .NET Interactive which allows for F# in a Jupyter Notebook. You can create .fsx scripts that are interpreted at runtime and handle inline dependencies from NuGet. There's the Fable which compiles F# to JS, TS, Python and Rust.
And of course it's a full on functional language with some great syntactic sugar, especially computation expressions.
The stomaching of .NET basically means getting a much larger set of third-party libraries than OCaml or Haskell can offer.
It is well worth checking out!
And of course it's a full on functional language with some great syntactic sugar, especially computation expressions.
The stomaching of .NET basically means getting a much larger set of third-party libraries than OCaml or Haskell can offer.
It is well worth checking out!
The part about C++ is true, when you need to use a combination of SIMD/CUDA/MPI there is no game in town but C++. The ecosystem is so vast, we rely on too many scientific/numerical libraries that took tiny armies of grad students to create.
But for new projects in the future, I am looking towards Mojo and Chapel.
But for new projects in the future, I am looking towards Mojo and Chapel.
Mojo has its foot in the door through compatibility with Python.
Otherwise, there is no reason to pick either when you can do `dotnet add package System.Numerics.Tensors` and access pure C# BLAS that runs at optimal hardware speed that lets you easily implement inference without ever reaching for C or C++. And for GPU-related scenarios there is ILGPU. Now, either is extremely niche compared to Python, but the overall choice will give you great support everywhere, unlike with Chapel or Mojo.
Otherwise, there is no reason to pick either when you can do `dotnet add package System.Numerics.Tensors` and access pure C# BLAS that runs at optimal hardware speed that lets you easily implement inference without ever reaching for C or C++. And for GPU-related scenarios there is ILGPU. Now, either is extremely niche compared to Python, but the overall choice will give you great support everywhere, unlike with Chapel or Mojo.
You mean...not suffering through cmake and co and having your project build the first time you type dotnet build -c Release?
(I suppose a valid excuse for suffering from C++ tooling would be getting to use something like ISPC)
(I suppose a valid excuse for suffering from C++ tooling would be getting to use something like ISPC)
I've written a tiny bit now and I can feel some new dimensionality that I'm not used to (e.g. the ownership and borrowing story in a language that doesn't really let you syntactically express ref/value seems a bit like marketing-driven-design), which can't be a good thing given that I'm not just an "AI programmer" that the mojo people seem to be aiming for.
I'd gladly switch the python code I have now over to mojo - python is slow and ugly - but in the long term the joined-at-the-hip relationship with python could put the language in a weird position: It might get you some early customers (every python-but-faster variant has) but what happens after that? It's an odd place to be (that and culturally your main influence is now going to be python programmers who are often either inexperienced or plain mediocre - selection effects)