Hold up... did I miss something, is Mojo open sourced now?
Edit: No it is still not open source. There are still same promises of open sourcing eventually, but there is no source despite the URL and the website claiming it's an open language. What's "open" here is "MAX AI kernels", not Mojo. They refer to this as "750k lines of open source code" https://github.com/modular/modular/tree/main/max/kernels
Python has a performance problem. Most people may not need it, but many people do. Languages like Rust and Go are heavily adopted by Python programmers either trying to understand low-level concepts or looking for something more performant.
And this is before we talk about the real selling point, which is enabling portable heterogenous compute.
py2many can compile static python to mojo, apart from rust and golang.
Is it comprehensive? No. But it's deterministic. In the age of LLMs, with sufficient GPU you can either:
* Get the LLM to enhance the transpiler to cover more of the language/stdlib
* Accept the non-determinism for the hard cases
The way mojo solves it is by stuffing two languages into one. There are two ways to write a function for example.
I don't think the cost imposed by a transpiler is worse. In fact, it gets better over time. As the transpiler improves, you stop thinking about the generated code.
It does matter. It already has a pretty active community and thousands of people who follow the development closely, however, most won't commit until the entire language is fully opened... including me.
I think they should say that on their /opensource/mojo website if that's the plan. Rather, they are trying to gesture at "750k lines of open source code", when that code is only meant to be fed into their closed source MAX engine. That's a sleight of hand, bait and switch misdirection, and that's what feels icky to me.
with BeOS you have instant indexed search, with no index server, and with atomic instant updates (e.g. the same moment you modify a file, the search results update) this is yet to be seen, and we are planning to implement it on Vitruvian
This is wrong. There's a misconception that you can't statically link your app when using the open-source LGPL version of Qt. From my reading of the LGPL license this doesn't appear to be the case[1]. The LGPL allows you to statically link your app as long as you provide the object files and allow users to relink your app with a different version of Qt.
I've observed many people spreading this misinformation about only being able to dynamically link with the LGPL version of Qt. Please stop this.
Yes, that is true, but in practice nobody has ever done that. And the material complexity of offering that mode is higher than just dynamically linking the library.
Also, modern compilers make this method much harder to use. It is much harder to stably relink object files like that than to just use the normal dynamic link method.
reply