Congratulations on the launch and work so far! This is indeed very interesting. I believe a language like this is necessary for future progress. I have also been impressed with Julia and its progress. I would have liked to see more progress on Ahead of Time compilation and using it to write Python extension modules.
For Mojo, I'm interested in seeing how the language can be used as a path forward for the Cython community. This could be a stepping-stone towards reimplementation of Python in Mojo. For the past 3 year, I have been talking about the need for a Python-Steering-Council-recommended extension language for Python. This will be particularly important as WebAssembly keeps progressing and potentially redefining what we mean by virtualization and containers.
We have already been using LLVM extensively in Numba and there have been several explorations around MLIR and related technologies. There are several potential paths forward and I'm looking forward to finding ways to cooperate.
Understanding what will be open-source is of course, critical for that.
This is a very good point. You must support AOT compilation if you are going to have a general purpose system. This was clear when Julia came out and I interacted with core developers communicating our experience with creating SciPy and the critical reliance on the AOT features of Fortran/C/C++ as well as the bindings to Python. I believe simpler spellings can be achieved (i.e. more unification between scripting, dynamic JIT, and foundational AOT use-case), but the ecosystem is not close to a one-language to rule them all scenario.
There is some work to bring it up to 3.12 and some resistance to merge it into 3.X because of the impact on extension modules (they all have to be recompiled and in some cases changed a bit).
If you are interested in it, reach out to Sam. He has done a pretty impressive piece of engineering work.
I'm sorry about triggering you. I can see your point. I did not mean to focus attention away from what happened and how to avoid it.
I am sincerely interested in seeing if the HackerRank leadership will reach out and discuss. I was not intending to promote anything I'm doing right now. I suspect they won't but I will talk to them respectfully if they do.
Let's promote the SymPy maintainers, though. Let's also promote NumFOCUS, because they do a valuable service to community-driven projects and could help SymPy respond to this sensibly. Let's also promote NumFOCUS because they efficiently and tirelessly work to help the projects they fiscally sponsor (like SymPy) -- providing legal support: https://numfocus.org/.
Perhaps something good can come out of this, still.
Thanks for showing up here and replying. I can understand the net being cast too wide for a real problem you are trying to solve. It does have real consequences for already under-resourced communities, though.
I appreciate the "fix-it-twice" attitude implied by the RCA promise (Root Cause Analysis for those who also had to look it up). Also, consider recognition and restitution for the unnecessary work you created for the NumFOCUS director, a NumFOCUS lawyer, and the SymPy maintainers.
A $25k donation to NumFOCUS would be a good start.
If you are willing to talk about what happened publicly, I'm starting a podcast/video series to discuss business and open-source. This would make an interesting conversation. Perhaps we can turn this into a positive to raise awareness and inspire better behavior in the industry? Ping me.
This author misses the point that the first problem a business faces is how to get customers and how to please them. Getting customers is the number one priority -- perfect architecture is only important to the degree that helps get customers.
Business owners and managers do need to understand that they may have to rewrite the software from the ground up because the first version will have all the problems the author talks about.
Most business owners and managers actually do understand this already. The goal of the first version is not to be architecturally perfect. The goal of the first version is to see if anyone will care if it exists. This is a good argument for not always building on the first version of a startup idea -- but actually build it again once you know people will buy.
For Mojo, I'm interested in seeing how the language can be used as a path forward for the Cython community. This could be a stepping-stone towards reimplementation of Python in Mojo. For the past 3 year, I have been talking about the need for a Python-Steering-Council-recommended extension language for Python. This will be particularly important as WebAssembly keeps progressing and potentially redefining what we mean by virtualization and containers.
We have already been using LLVM extensively in Numba and there have been several explorations around MLIR and related technologies. There are several potential paths forward and I'm looking forward to finding ways to cooperate.
Understanding what will be open-source is of course, critical for that.