4 ms·

Parsing PNG Images in Mojo

38 points by nojito 2y ago

dimatura 2y ago
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.
- melodyogonna 2y ago
  Chris Lattner expects the language to be really usable by the end of this year, so maybe check it out early next year.
neonsunset 2y ago
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.
- simonw 2y ago
  Won't help you much if your goal is to learn Mojo.
  - neonsunset 2y ago
    Fair enough, though I'd argue - don't, F# is well-loved by certain research labs for these use cases :)
    - Conscat 2y ago
      But then you have to be capable of stomaching Dotnet. Modern C++ is the best tool for this job, currently.
      - WeatherBrier 2y ago
        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.
        neonsunset 2y ago
        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.
      - neonsunset 2y ago
        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)
      - williamcotton 2y ago
        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!
melodyogonna 2y ago
Excited to see what Mojo will look like by the end of the year.
mhh__ 2y ago
The MLIR aspects of Mojo are really interesting but I can't help but feel that the language itself is basically just going to be a hodge-podge of semi-random crap bolted onto python (which is already a few decades of semi-random shit held together with a committee and a dream). 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)
- melodyogonna 2y ago
  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
  - mhh__ 2y ago
    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?
    - melodyogonna 2y ago
      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.
fbdab103 2y ago
I know it is not technically Python, but seeing `list` used as a parameter made my eye twitch.

38 points by nojito 2y ago

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.

melodyogonna 2y ago
Chris Lattner expects the language to be really usable by the end of this year, so maybe check it out early next year.

neonsunset 2y ago

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.

simonw 2y ago
Won't help you much if your goal is to learn Mojo.
- neonsunset 2y ago
  Fair enough, though I'd argue - don't, F# is well-loved by certain research labs for these use cases :)
  - Conscat 2y ago
    But then you have to be capable of stomaching Dotnet. Modern C++ is the best tool for this job, currently.
    - WeatherBrier 2y ago
      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.
      - neonsunset 2y ago
        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.
    - neonsunset 2y ago
      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)
    - williamcotton 2y ago
      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!

melodyogonna 2y ago

Excited to see what Mojo will look like by the end of the year.

mhh__ 2y ago

The MLIR aspects of Mojo are really interesting but I can't help but feel that the language itself is basically just going to be a hodge-podge of semi-random crap bolted onto python (which is already a few decades of semi-random shit held together with a committee and a dream). 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)

melodyogonna 2y ago
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
- mhh__ 2y ago
  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?
  - melodyogonna 2y ago
    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.

fbdab103 2y ago

I know it is not technically Python, but seeing `list` used as a parameter made my eye twitch.