In Julia, the community has to interface with packages from the vendors for each kind of target device.
Whilst with MLIR, you can assume each vendor will do that for you. This will also be the case for Quantum Computing and things like that.
If Julia wants to stay competitive, it has to be able to compile to MLIR (in my opinion). Even if mojo fails, eventually there will be a MLIR language that does solve the 2 language problem like Julia does.
One of the main selling points of Mojo is compiled binaries. How would Julia implement compiled binaries for multiple dispatch? Since the number of methods for an unconstrained multiple dispatch call grows exponentially, the size of the binary would grow exponentially. Given the unconstrained Julia base, I don’t see how this problem can be solved. I know a company that solves it via PackageCompiler.jl and 100% coverage but that has a big problem, namely 100% coverage.
In fact, my recollection is that only two applications were mentioned in the docs (and they were repeated a few times): ML and systems programming.
In most (or many) cases, you are just interested in compiling for a single input type, or a single set of input types.
Does any other language solve the problem of generating small binaries without this constraint?
But can you guarantee that all methods are compiled for all types flowing through the program? Differently put, not all Julia methods are inferrable, that is, some are inferred as Any. Can you guarantee that this Any output will, in practice, remain within the compiled branches?
More formally, can you guarantee that you have provided sufficient inputs such that you have found all possible output types for all functions. If there is some function f for which you only encountered f(::A)::B in the compilation and not f(::A)::C, then this can crash your program since C will be passed into some other function, which might have not seen C before during compilation.
If every part of the program is inferable and type stable, why not? Then every type flowing through the program should be deterministic, and uniquely determined by the inputs.
Or else not.
I guess I don’t really understand your argument.
AFAIK it’s been mostly speculative discourse threads but people have suggested that precompiling can catch those Anys at type inference, and those sort of methods will have to be avoided if the JIT compiler is removed. Some have suggested that those methods could be accommodated by having the compiler do vtables for precompiled methods and throw an error if something unexpected comes up. But strict type stability seems to be more accepted, considering what small binaries are usually for. When the JIT compiler really is necessary, there are also ideas to reduce the PackageCompiler size but that’s still not really “small binaries.”
This should be impossible, or rather type inference should not miss the possible C even if it never happens at runtime.
I just got access to the mojo test environment and am reading their “HelloMojo” document.
I’m not quite through the document, but my takeaway so far is this: if your primary goal is to take the large amount of python ML models that are out there and make them as portable as possible, this seems like a great tool for constructing that type of system. Modular is in the business of running ML models across many architectures; this tool feels specifically oriented around that goal, and I imagine it’s achieving that quite well.
I am somewhat surprised that they didn’t use Swift or Rust for solving these problems. I suppose it will be seen whether this can resolve the two language problem for existing Python users, especially outside of this use-case, but I have my doubts. I do not believe that Python users will move en-masse toward a compiled, typed systems language simply because it looks more like Python than C.
It’s taken a lot from Swift. For instance, values can be declared immutable by using let, or mutable by using var. Mojo also introduces struct, similar to that found in many languages.
where classes are extremely dynamic with dynamic dispatch, monkey-patching (or dynamic method “swizzling”), and dynamically bound instance properties,
structs are static, bound at compile time, and are inlined into their container instead of being implicitly indirect and reference counted.
Another alteration is method declaration. A user can implement a method with def just like in Python. But they can also implement the same method with fn. The semantics of the method call are the same, but fn calls must contain type signatures, and arguments are immutable by default. In other words, fn is more amiable to strict memory and type constraints often required for systems programming, like Swift:
defis defined by necessity to be very dynamic, flexible and generally compatible with Python: arguments are mutable, local variables are implicitly declared on first use, and scoping isn’t enforced. This is great for high level programming and scripting, but is not always great for systems programming. To complement this, Mojo provides anfndeclaration which is like a “strict mode” fordef.
fnanddefare always interchangeable from an interface level: there is nothing adefcan provide that afncannot (or vice versa). The difference is that afnis more limited and controlled on the inside of its body (alternatively: pedantic and strict). Specifically,fns have a number of limitations compared todefs:
This, to me, looks like Python + systems programming features, tackling a different set of problems from Julia, and with a very different approach. Essentially as advertised! I have no doubt it will find use and success, and I think as a language it will have strengths and weaknesses similar to Swift. It will be interesting to see how the community receives it and develops it.
what? statistics?
if user wrote same amount of typing information in Mojo and Julia I don’t see why Julia can’t compile with the same strategy… if anything, Python is a much more flexible language than Julia.
Marketing doesn’t mean anything, I don’t see how you can just magically compile any Python code by some type hinting… there’s so much random stuff in Python user may rely on https://www.youtube.com/watch?v=qCGofLIzX6g
I think what’s being missed with most of these comments is that Mojo is not actually a Python accelerator like PyPy. Mojo is a completely new language with Python-like syntax (so, a lot like Julia). It will not be compatible with Python; instead, it’ll be interoperable, the same way Julia is, but their marketing material ignores this distinction. Python code in Mojo will work by calling the CPython interpreter, and will not be any faster.
As for the differences from Julia, I’ll bundle them Julia into 4 groups:
0/1-indexing honestly couldn’t matter less. The only good reason to use either one would be to make people stop complaining about it. Honestly, I would just add this package to base to stop wasting time answering questions about this.
UFCS would be nice for method discoverability, have ~0 downsides, and would go 80% of the way to solving most complaints about the lack of OOP.
The off-side rule matters even less than everything else, but probably has the biggest impact, and is kind of rational. The off-side rule is a shockingly good heuristic for readability. Think of Python, Nim, Elm, F#, and CoffeeScript. How do those compare to C, C++, Java, and JavaScript, or with R, Matlab, and Fortran for scientists? Julia (and Lua) are just outliers here. Python users think explicit blocks indicate “ugly languages,” because this is true of all the languages they know. (I almost decided not to learn Julia because of this!)
The Scala approach (insert missing curly braces implied by indentation during parsing, or for Julia, missing begin and end keywords) seems to have few disadvantages, can be done without breaking anything, and would probably get a lot more Python devs joining.
Type hints were standardized in September 2014. In March 2019 data one analysis found 20 percent of files in their open source sample were using at least some annotations. Presumably it’s more now.
In the corporate environment, Dropbox, Microsoft, Facebook, Google have all invested in making their own type checkers, which I imagine they’re running on a lot of code. Eg Our journey to type checking 4 million lines of Python - Dropbox
Company coders I don’t care, they can have an internal policy of 100% no template programming in C++ (google) and that means nothing to the wider users.
we’re talking about users here, do you think most users doing scientific computing use type hints? 20% is upper limit in 2023 is my estimate
The story I read from people familiar with Julia MLIR efforts is that MLIR was changing so rapidly that it wasn’t worth trying to keep up. And that now MLIR might be stable enough to pick it up again.
It definitely is–no ML ecosystem is going to be even close to competitive without an MLIR compiler. You may want to go through StableHLO, which is even more stable and offers more optimizations. Coil.jl lets you do this, but is not widely-known or used, and seems to be in early development. It’s probably not going to get any adoption unless it’s moved under a bigger org with the implicit promise that it’s going to be maintained into the future.
what makes you be so sure of this? I don’t think PyTorch uses MLIR and it’s competitive as an ecosystem on its own…
where do you cook up these super confident takes?
As far as I can tell both Tensorflow and Pytorch heavily interface with MLIR.
Multiple Vendors use MLIR as the middle layer mapping from platform frameworks like PyTorch, JAX, TensorFlow onto MLIR and then progressively lowering down to their target hardware.
TLDR: In my opinion: Julia developers shouldn’t care about static compilation for type unstable code and code that does dynamic dispatch
If it is worth something to anyone, for me the perfect language has:
Multiple dispatch + parametric types
Because I don’t think that Mojo can achieve the amount of modularity that Julia has without multiple dispatch. I do like that each mojo functions can have a @generated subpart to handle types. In Julia you often have to rely on constant propagation, which is hard to predict.
Decent syntax
Julia’s syntax is perfect. I don’t want to write ** for exponentiation. I hate seeing self in code. And to me 1-based indexing is more natural.
Option to let the compiler type check at compilation time
Like the difference between def and fn in mojo. There if you want your function to be type checked, you use fn, otherwise you use def. Maybe having the choice with a macro to let JET.jl run automatically is enough for this.
Compilation to binaries for multiple backends
Maybe MLIR is needed for this, maybe not. In my opinion, this feature should only be available for Type stable code (i.e. fn in mojo). Julia developers shouldn’t care about compilation for type unstable code and code that does dynamic dispatch. I don’t think there are people that care about running dynamic code in production anyway.
(Note: I use Julia full time for half a year and I love it, this is ment as a way forward, not as critique)
