Did Modular just reinvent Julia?

[Amval]

What ideas did you find interesting?

[lmiq]

@rikh

I’ve had to trace four layers back to figure out where the object came from

This is the kind of thing we have hopes that tools can solve/help, such that dynamism and interactivity can be reconciled with a more static and safer programing. Mojo seem to allow some of this safety by creatind a subset of python for that, but with a syntax and utility that has to be proven).

(though I don’t think Julia will ever be the best tool for every task, of course, and from my perspective the reason to write a web server in Julia would be my lasiness to learn anything else for a task that is secondary for me)

[jar1]

Static types are very widely used in Python already, so that shouldn’t be much of a stretch – moving to a language without optional static typing is a regression in user experience.

Mojo is for Python programmers who don’t want to learn a new syntax yet have no problems learning static typing and manual memory management?

I might count myself as one of those. Fundamental concepts like types and memory are useful and transferable skills. Other things are less fun to relearn: syntax, builtins, standard library, ecosystem, community… I don’t know how much of Python will be ported, but the more similar they can make it the nicer it’ll be to migrate.

The Hard Part of Learning a Language

[Benny]

For people who aren’t familiar with Python, it might be misleading to say (optional) static types instead of type hints and omit mention of the third-party static checker mypy.

@jar1

Other things are less fun to relearn: syntax, builtins, standard library, ecosystem, community

Mojo has struct/fn in addition to class/def (no classes yet), immutable let vs mutable var declarations, memory ownership…this is a hefty superset of Python and the performant examples don’t look much like Python with type hints. To me, this is more like a Rusty language intended for easier Python interop, and it doesn’t solve the “two-world problem” (basically same concept as two-language problem in Julia speak) for Python, it solves it by enticing Python users to learn a new language.

Mojo and Julia aren’t remarkable in this respect; many languages can claim to be useful without other languages. But I think Julia has a better approach to providing features that would appeal to people who reached for Python glued to C++, and has it right trying to improve on its own terms rather than modifying Python (nobody complains about Julia’s missing optimizations, compilation latency, or binary size more than Julia users).

[AMJ]

There are talks about how no GC mode in Julia should work? Does there exist any ideas yet?

[FHell]

@stevengj

Julia’s compiler is much simpler than e.g. PyPy or Numba or LuaJIT. It doesn’t need to “guess” (or “trace” at runtime) because the Julia semantics provide much more information to the compiler than Python semantics.

It’s not about how simple the compiler is. It’s about how much you try to get it to infer vs how much you ask people to annotate. Julia is designed to be more easily “inferable” for the compiler because it is designed with this goal in mind. But you shouldn’t think about this point as Julia vs Python, but as Julia vs Rust/C++/etc…

Put another way: A lot of people are trying to get away from (legacy) C++ for good reasons. If you are writing C++ code that is meant to be called by non-programmers comfortable with Python, then Mojo has the potential to be a fantastic target for you. It’s situated exactly where C++ is trying to go. Julia by comparison is in a completely different direction.

@stevengj

I think it’s hard to evaluate Mojo in its current embryonic state.

Absolutely agreed.

@lmiq

The memory safety of rust if probably its greater appeal. The syntax checker is less important, syntax errors can be much more efficiently resolved with a linter, and most of them one does not even have to look to the error message when one gets used with the language. Refactor, parallelism, requires the correctness of the algorithms, and that cannot be guaranteed by the syntax, only by unit tests.

I think you really fundamentally misunderstand this point. This isn’t about syntax at all (just like Type systems are not about syntax). It’s about having the semantics of ownership explicitly surfaced in the language and checked at compile time. This is especially useful for manual ressource management. The most prominent example of a resource we need to manage is memory, so this is important. But it does the same with files for you for example. People also report that having to explicitly think about ownership clarifies your data dependencies in the program architecture tremendously, leading to better code overall (especially in not so experienced programmers, I have heard this point from people teach CS especially). And in parallelism the semantics of ownership are sufficient to guarantee data race freedom, and that’s already huge. That’s again not something that any linter can get you. But of course Rust has many more features that are engineered for correctness over ergonomics.

@bilderbuchi

As far as I can tell from crunchbase, JuliaComputing/JuliaHub and Modular got nearly the same investment of 30M$. This does not include research grants for improving the various packages in the ecosystem (except for one small NSF grant, apparently).

Well, if a barely available embryonic language has the same amount of funding as a widely used established 10 year old language that says something as well…

But I wasn’t comparing Julia to Modular funding here. I was asking why the real heavyweights in R&D spending: nVidia/Google/Facebook/… haven’t really bought into Julia at all. I have no special insights into this. My speculation: Julia is not an interesting transition path for C++ programmers.

[Barget]

@AlexanderNenninger

But since when does exact syntax matter (bar outrageous examples)? Python’s syntax is pretty nice imho, so keeping large parts of it is not a bad decision.

Indeed, that’s a good decision to keep Python syntax. But to get performance they had to go beyond that (thus loosing simplicity).
Being promoted as a superset, it’s reasonable to assume they’ll keep all the peculiarities and, as you said, sharp edges. Otherwise, they couldn’t guarantee “if it runs in CPython, it runs in Mojo”. (To which extend this aspect is important, I can’t tell yet.)

I guess we’ll see how they’ll make the syntax evolve. Will they add some kind of decorator to hide some of the complexity or not, and will they stick to a strict “supersetness” or not.

Also, in the example they provided, it’s great that some lower level programming was made available (cache tiling, SIMD), but it was not as nice as a regular Python (very personnal opinion here).

To me, it’s wait & see.

[lmiq]

@FHell

. It’s about having the semantics of ownership explicitly surfaced in the language and checked at compile time

Does the concept of mutable global variables exist in Rust? It is interesting to think of a Julia variant not allowing that at all, and a strict control of variable passing among functions would maybe help inference, as no value would be able to change type in the scope of a function, unless that’s done inside that scope. Makes any sense?

I do see the advantage of the ownership model, particularly for system programming.

For what I do the important and hard errors rarely are related to the programming itself, but to the algorithms, concepts, etc, so that the ergonomics of the language and testing are more important for correctness.

[FHell]

Accessing mutable globals in Rust is unsafe.

@lmiq

For what I do the important and hard errors rarely are related to the programming itself, but to the algorithms, concepts, etc, so that the ergonomics of the language and testing are more important for correctness.

I think this is at the core of it. For this usecase Julia is pretty damn good. That said, we often run into corner cases in major crates in the ecosystem that are just buggy or under-specified. So once you start gluing together the algorithms of other people this type of correctness also becomes more tricky.

[Sukera]

@FHell

So once you start gluing together the algorithms of other people this type of correctness also becomes more tricky.

Really, we all ought to program with formal methods, to ensure correctness ;D

[FHell]

There is a lot of space between formal verification and the C approach. We do have bounds checking on per default in Julia for good reason.

[stevengj]

@FHell

But you shouldn’t think about this point as Julia vs Python, but as Julia vs Rust/C++/etc…

Please, let’s not turn this into yet another Julia vs Rust thread (i.e. dynamic vs static languages) — that’s taking an offtopic thread to yet another offtopic thread.

[FHell]

@stevengj

Please, let’s not turn this into yet another Julia vs Rust thread (i.e. dynamic vs static languages) — that’s taking an offtopic thread to yet another offtopic thread.

That was not my intention. Maybe I should have said “Julia in comparison to …” rather than “vs”. You talked about the complexity of compilers, and only mentioned Python/Lua. Yet my point was exactly that Python/Lua and the like are not the right languages to think of with respect to Mojo. Mojo follows in the footsteps of Rust/C++/Swift/etc… and it should at least also be understood in the context of the evolution of those languages.

[stevengj]

@FHell

Mojo follows in the footsteps of Rust/C++/Swift/etc… and it should at least also be understood in the context of the evolution of those languages.

That’s not at all clear to me. Mojo is starting with a dynamically typed language (Python) and building/diverging off of that (claiming Python compatibility as a feature), so the closest comparisons seem to be other compilers for dynamically typed languages or subsets/variants thereof (LuaJIT, PyPy, Numba, Pythran, … not to mention Julia itself).

Again, however, Mojo is in such early stages that’s it’s not clear yet quite what it is. Maybe it will indeed turn into a statically typed language that just shares some surface syntax with Python, and with features to ease interop with Python. i.e. Cython redux, but based on more modern static languages than C.

[Benny]

The struct/fn part is statically typed, and the def part is dynamically typed (class hasn’t been implemented yet). Most of the performant examples do the former so FHell’s perspective of Mojo being a Rust aiming to be compatible with Python makes sense.

[FHell]

@stevengj

That’s not at all clear to me. Mojo is starting with a dynamically typed language (Python) and building/diverging off of that (claiming Python compatibility as a feature),

Actually they are building a systems language with the intention to eventually implement a layer on top that is Python compatible. Real Python compatibility seems a long way off for them. (see also Chris Rackauckas comments on the challenge of actually getting there in the Hackernews thread).

[PetrKryslUCSD]

So, what they appear to want:

1. Ability to run Python (use Python libraries).
2. Ability to run some code fast.

Isn’t that what Python+C, Python+C++, Python+Julia do?

I think they are able to sell it (have been able to so far) because they make
it look as if a Python programmer was going to still work in a single language.
I will believe it when I see it, but not right now…

[Tamas_Papp]

@FHell

if a barely available embryonic language has the same amount of funding as a widely used established 10 year old language that says something as well

Possibly, but not about the design or potential of either language. Software is one of those curious industries where people implement great ideas in their spare time (eg early Linux), and projects can soak up the GDP of a small country without leading to anything interesting (examples too numerous to list here).

I am not saying Mojo is in the latter group. It’s just too early to say.

I think that it is OK to admit that we have too little information to judge Mojo, and suspend judgement until we know more. That may take years.

[jt1]

True, but they build it on top of MLIR which allows them to run their code in production on CPU, GPU, TPU and more.

[PetrKryslUCSD]

Isn’t Julia capable of that too?