Mojo as new lang track

If I’m reading it correctly, Mojo is a strict superset so you could theoretically copy all existing Python practice exercises and have them work for Mojo. It’s similar to the TypeScript/JavaScript tracks. If you were to really teach people about what’s different in Mojo, you’d be writing concept exercises (a lot more work).

I don’t see concept exercises for typescript. Are we saying that the preferred approach for successor type of languages (specially the ones that are strict super sets ) is to encode them as concepts? Or in other words like an advance concept after somebody has mastered the “base” language?

Let’s take a step back from this and look at the context.

  1. All Exercism tracks are built and maintained by volunteers. Are you volunteering? If so, please be aware that it is a LOT of work to (at a minimum) write an Exercism-compliant test runner and create a starter set of exercises.

  2. Is Mojo ready for this yet? The core libraries were open-sourced less than 5 weeks ago, and I suspect (but don’t know for certain) that key pieces will still be missing. The language is still evolving rapidly, so we could be chasing a moving target.

  3. The advantages that Mojo has over Python are in areas which may not be a great fit for Exercism in its current form: matrix operations, big data extensions, GPU support, etc. Exercism tests are run in a short-lived Docker container with no internet access and no possibility of GPU access (AWS might offer it, but at a price a non-profit certainly can’t afford).

Science-biased users and maintainers with an interest in Python/R/Julia have been discussing the idea of a data science evolution of Exercism, but there has been little or no progress on this in the last few years. It needs volunteers who combine the appropriate skills with lots of free time and energy to make it happen. People like that tend to already have busy careers!

@BethanyG probably has the most evolved ideas about this, but she already has her hands full maintaining the (very busy) Python track.

Personally, I would love to see this happen and would help if I could: I’m a long-time research scientist who does some programming on the side. However, I can’t take the lead in creating it.

Also, I love concept syllabuses, I think we should have more of them, and I’m contributed to them on other tracks. I can confirm that they are a lot of work, and difficult to get right.

3 Likes
  1. Sure.

  2. Mojo was released May 2023 (close source sure then yes). These language tracks take time. Probably 6 months or so given folks commitments. We can target release next year if folks are committed to even supporting it. I know languages come and go and who knows if Mojo will be able to turn over Python folks into their camp.

  3. I remember when we added support for the swift language it could not even run on windows and none of the code was tested in Linux. Mojo a niche language but so was Python/typescript not too long ago.

1 Like

Who are “folks”? Are you offering to build and maintain a Mojo track? Typically tracks get built when someone offers to build and maintain them.

Hi @masters3d :wave:

Let’s be clear: I am not opposed to a Mojo track, and might even be interested in organizing and building one out eventually.

But the devil is in the details for me. Especially with limited time and energy.

So I’m chiming in to re-focus on what @colinleach has pointed out:

Mojo isn’t even at v1 yet, and has (by their own admission) sharp edges that include lacking support for classes, exceptions, list and dictionary comprehensions, generator expressions, lambdas, recursion, nested-functions, closures, function-scope, and whole lot more. They’ve only recently added a dictionary type.

They also have not accounted for the upcoming changes to Python that include removing the GIL, and other optimizations. They don’t really support the wider Python ecosystem of packages and tooling, and they wrap Python for a lot of functionality.

While they’re making good and fast progress, it doesn’t feel wholly baked yet. Maybe we wait and see what they come up with between now and the beginning of next year? I think it would be highly frustrating for both students and maintainers to have to overhaul the track due to language changes.

@masters3d – what features of Mojo would actually shine in the existing Exercism environment? Keep in mind that the online environment would be a Docker container (and since Mojo only supports Ubuntu, it would be an Ubuntu container). No access to outside libraries or services, and TDD-focused.

What existing practice exercises would be interesting or useful to help illustrate what Mojo can do? Of those exercises, what would a Mojo implementation (not Python or Python called from Mojo), including tests look like?

And what would a concept/concept exercise look like for a Mojo-specific feature? For example, structs, or StringLiteral or String?

Again, not trying to be difficult here – trying to clarify what this would look like, and why we’d be interested in working hard to make it happen.

1 Like

Yes.

There are couple of things beings discussed so let’s enumerate them.

  • Who will do the work?

  • Mojo feasibility in the current infra ?

  • Mojo time to market readiness?

  • Mojo audience?

I think the most compelling discussion is if Mojo would bring value to the community in its current form to advanced users. Python is an excellent starter language but I would not consider mojo to be a good starter language without first knowing enough python.

I think it’s okay to say not yet and see what happens in the next 12 months.

1 Like

I think you’ve been asked a couple of times if you’re volunteering to do the work. Given that you have yet to say yes to that question, is it fair to assume you’re not interested in building and maintaining the track?

If there’s no one volunteering at this point you build and maintain the track, I’m not sure any other discussion is of much value at this point.

1 Like

(Just for context here in case you don’t all know each other, Chéyo is a very senior contributor: masters3d's profile on Exercism :slight_smile:)

2 Likes

Mojo track would be great.

Are you interested in building it out?

Hi @Akshay-111 :wave:

Chiming in as a Python track maintainer.

I think my comments further up in this thread still (largley) apply - although I haven’t kept up with Mojo development, so please chime in here with any Mojo updates/improvements you might be aware of.

@colinleach - I know you follow things in this space — in your opinion, has Mojo development progressed to the “baked” stage? Is it track ready?

And to @IsaacG point — @Akshay-111 → are you willing/able to step up to launch this?

Sadly, I’ve not been keeping up with Mojo developments recently (I should try harder!).

My view remains pretty much the same as a year ago: I’m not going to create a new track myself (wrong skills, other priorities). If someone else takes the lead by creating a test runner, I will aim to help build out the track, with exercises, documents, maybe a learning syllabus eventually.

2 Likes

Apologies, I was asking the OP if he was willing to build the track! :smile:

But you’ve been very very awesome in building out Python, Julia, and R (among others) … so your help on Mojo would be enthusiastically welcomed, I am sure. :heart:

1 Like

I think waiting for Mojo’s ecosystem to become more mature is a safer bet for now. As of this moment, according to Install Mojo | Modular, Mojo can only be installed on Linux or M-Series Macs.

1 Like

To be clear, a lack of native Windows support doesn’t preclude a track from being built. Test runners are built using Linux Docker images so that’s the minimum. I’d venture that most tracks do support students working natively in Windows. For Pyret, you do have to use the Windows Subsystem for Linux, and for Bash, you probably do but I don’t know the specifics there.

1 Like

I think here it’s less about what platforms (although that is a consideration), and more about the fact that mojo is now primarily designed to accelerate AI/ML models & applications, and is not really designed with general-purpose programming in mind. The company motto is “democratize AI compute”. To quote their website:

We wanted a flexible and scalable programming model that could target CPUs, GPUs, AI accelerators, and other heterogeneous systems that are pervasive in the AI field.

So I went to catch up with where they’re at, after not looking at things for a long while.

It originally appeared to wrap Python (and the website cagily says they “build upon” Python still) - but read further and it’s clear that they’ve now built out their own lang borrowing from zig, rust, c++ and python, mimicking python syntax. They promise interoperability with Python, but just like calling R or Julia from Python (or vice-versa), there are difficulties and speed issues. Python being dynamic and mojo being static compound those issues.

They didn’t want to improve Julia, and they didn’t want to deal with the Cpython, Rust, or Zig folx telling them they couldn’t do violence to certain aspects of those languages.

It’s standard lib now heavily relies on C++, and will probably do so for quite some time going forward.

It’s also from a private company, and the compiler and some other bits are not open source ,which may or may not pose issues when developing tests and tooling.

And if you are not doing sci-stack intensive and GPU-accelerated programming, you might not be able to tell the difference over using “plain” C++, Rust, Python, or something else.

As an added caution, since very few of our practice problems would even utilize a sci stack (in any of those programming languages) in any meaningful way, anyone building out the track would essentially have to design problems and tests from scratch if they really wanted to showcase what the language can do.

2 Likes

Mojo does have a goal of being a systems programming language Mojo Manual | Modular so it should be possible to design a curriculum around it.

It also does have a goal of becoming open source Mojo FAQ | Modular.

As for supported platforms, I personally use an Intel Mac and that’s not supported at the moment. The lack of support for both non M-Series Macs and Windows is imo definitely a consideration.

1 Like

Intel Macs are deprecated. PyTorch, TensorFlow, Nix for examples.

Mojo for sure targets to teach data parallel compute, specifically GPU.
Intel Macs may appear no so good in support of such compute targets.

I just did some Zig. @Vector just allowed me to do SIMD on existing exercise without a hassle.
I expect from Mojo to do same for me for GPU in modern static type system, something like how to do usual things on GPU (what ever from exercism possible on it).

I feel like Rust, Zig, Julia, Python are hassle for teaching GPU.
I know and coded Rust/Zig/Python - so approximately aware how they do GPU. I would like to Julia - but it feels odd, similar way Uiua/R/Matlab(used this one) are. And I always had troubles with dynamic/late-binding/weak type system

Mojo feels like industrial GPU thing, no so details of CUDA/ROCm/Metal/OpenCL to learn, neither too high level. No dynamic typing magic nor macros. Good compiler errors.

And always looking forward language which improve mem management, less verbose and noisy compared to Rust, but not GC.