CoreyFieldens

I think I would agree with you. In my opinion, that already exists and is decently mature. CuPy [0] for Python and CUDA.jl [1] for Julia are both excellent ways to interface with GPU that don't require you to get into the nitty gritty of CUDA. Both do their best to keep you at the Array-level abstraction until you actually need to start writing kernels yourself and even then, it's pretty simple. They took a complete GPU novice like me and let me to write pretty performant kernels without having to ever touch raw CUDA.

[0] https://cupy.dev/

[1] https://cuda.juliagpu.org/stable/

As someone who has been playing around with (and enjoying) Mojo, I have my doubts about how useful Mojo will end up being for your average scientist. You can't get performant code out of Mojo if you're not willing to learn some deeper programming concepts like SIMD or tiling.

I don't have the exact quote on hand, but in the Mojo Discord, Chris Latner explicitly said he wants no "compiler magic" in Mojo. With that idea in mind, Mojo makes it a lot easier to do optimizations like SIMD vectorization by hand, but you will still have to do it manually. My guess is that many scientists who don't like programming would find it annoying to hand-write those kinds of optimizations. If you want a language that gives you nice, performant code on your first attempt, Julia is always a decent option.

These are the docs for some of Mojo's higher order functions that implement vectorization, parallelization, tiling, loop switching, etc. https://docs.modular.com/mojo/stdlib/algorithm/functional

I do think they are a good idea and relatively easy to use; I'm just not convinced that the non-programmer scientist will like them.

One thing that concerns me so far is that nothing put out by Mojo or said by any of the Modular leaders indicates that the language itself will ever be open sourced. The Mojo FAQ says:

"Over time we expect to open-source core parts of Mojo, such as the standard library."

In the most recent keynote, Chris Latner said the standard library will be open-sourced starting next year. I have never seen anything about the actual rest of the language. I worry that they don't actually plan to open-source all the core parts of Mojo and they're just letting others put words in their mouth to hype up the language.

> "Drought and heat have already reduced global cereal production by as much as 10 percent in recent years, according to Steffen."

I'm not sure how they define this because I find conflicting info elsewhere. Our world in data has global cereal production only going up [0]. That data only goes until 2021 so there could have been a decrease in 2022 but then it would probably be wrong to say "recent years".

[0] https://ourworldindata.org/grapher/cereal-production?tab=cha...

The majority of Americans ARE asset owners. That's exactly the kind of behavior that a non-zero inflation wants to encourage.

https://www.statista.com/statistics/270034/percentage-of-us-...

There's not a strong reason to use Mojo over cython right now, but if Mojo can deliver on their claims, I think there will be. A borrow checker, better IDE support, function overloading support, and better SIMD support are things that stick out to me in Mojos favor.

"As we continue to take a responsible approach to generative AI, we’re adding new Content Credentials which uses cryptographic methods to add an invisible digital watermark to all AI-generated images in Bing – including time and date it was originally created. We will also bring support for Content Credentials to Paint and Microsoft Designer."

This is really interesting to me. I've heard discussions about doing this, but is this the first time we're actually seeing it implemented in image software?

That's disingenuous. They are also open sourcing the standard library by the end of the year.

I'm really interested in Mojo not for its AI applications, but as an alternative to Julia for high performance computing. Like Julia, Mojo is also attempting to solve the two-language problem, but I like that Mojo is coming at it from a Python perspective rather than trying to create new syntax. For better or for worse, Python is absolutely dominating in the field of scientific computing, and I don't see that changing anytime soon. Being able to write optimizations at a lower level in a Python-like syntax is really appealing to me.

Furthermore, while I love Julia the language, I'm disappointed in how it really hasn't taken off in adoption by either academia or industry. The community is small and that becomes a real pain point when it comes to tooling. Using the debugger is an awful experience and the VSCode extension that is recommended way to write Julia is very hit-or-miss. I think it would really benefit from a lot more funding that doesn't actually seem to be coming. It's not a 1-to-1 comparison, but Modular has received 3 times the amount of funding as JuliaHub despite being much younger.

That was the release date of Rust 1.0. Not the first appearance.

If you can use LLM's to translate your code from one language to another, why would you translate Python to Julia? Even the most ardent Julia supporters will admit that Julia code will be slower than optimized C and C++ code. Why not just use an LLM to rewrite your Python into those languages?

From google, the total area of South American countries:

1. Brazil: 3,287,957 sq miles

2. Argentina: 1,073,518 sq miles

3. Peru: 496,225 sq miles

If you're a PhD student, you're probably only taking classes for around 2 years out of your 5-6 years there.

Could you link to some of those papers? I would be interested in learning more about the frontier of Fortran development. I recently learned about the LFortran project and while I think it's an interesting project, I feared it would be too late for the language.

Everytime Julia is mentioned on HN, I see a surprising amount of people who dislike the language for whatever reason. I understand a lot of their concerns (time to first plot, debugging sucks, IDE support isn't amazing yet). However, I don't see a lot of alternatives for the niche that Julia occupies. If you want to do high performance scientific computing, there aren't a lot of options in terms of languages.

Python is the de facto but it's so slow for anything that can't be well represented as vectorized NumPy operations. There are ways around that like Numba, Jax, Cython, etc. but their use cases are pretty limited, and they don't work well with other Python packages.

There is, of course, C and C++ which are commonly used to speed up Python or as standalone packages. However, C++ is such a complicated beast that writing performant and correct code takes forever. C is much more manageable, but I find that there are not a lot of scientific packages written in pure C. This isn't even touching on the horrendous build system that is CMake.

Fortran is a pretty simple looking language and would probably be the closest to Julia in terms of speed and expressiveness, but the writing is on the wall and Fortran's days are numbered. I am not aware of many new packages being developed using it.

Other than that, there's languages like Rust and Go but those have ecosystems that are so small, they make Julia's ecosystem look like Python's. I really don't want to spend my time as a grad student writing basic numerical libraries from scratch.