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.
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.
Great way to get $25k (and I'm with you, I don't mean that sarcastically or that you don't deserve it), the company needs to pay up to manage somewhat their reputation.
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.
What are you doing about all the other bogus DMCA claims you company has sent (itself or via its external contractors)?
What are you doing to ensure this never happens again?
Why should we believe your answers, and how can we see concrete evidence that you've stopped doing this and made up for all the times you've done it in that past?
> What are you doing about all the other bogus DMCA claims you company has sent
Multiple commenters asked him this and he never replied.
Disappointing but not surprising. It's all just superficial hand waving. They are sorry but only for bring caught.
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.
I think this is true. I have used the Python C-API heavily having started SciPy and NumPy and Numba. I have a pre-alpha plan for addressing the C-API by introducing EPython (a typed subset of Python for extending it). It is not usable and in idea stage only, but I welcome collaborators and funders: https://github.com/epython-dev/epython. Here is a talk that describes a bit more the vision: https://morioh.com/p/6db365736476
Interesting, I assume you are familiar with Terra, Titan and Pallene research languages?
I love the idea of typed base language to implement a higher level more flexible language while still being able to drop down for correctness and speed. Gradually dynamically typed, ;)
Another thing to look at is https://chocopy.org/ a typed subset of Python for teaching compilers courses. Might be worthwhile pinging Chocopy students and enticing them towards epython.
What is the semantic union and intersection between EPython and Chocopy?
I think the approach where a typed subset of Python is used to compile a fast extension module is the way forward for Python. This would leave us with a slow but dynamic high-level-variant (CPython) and typed lower-level-variant (EPython, mypyc & co) to compile performant extension modules, which you can easily import into your CPython code.
The most prominent of such projects I know of is mypyc [0], which is already used to improve performance for mypy itself and the black [1] code formatter. I think it would be interesting to see how EPython compares to mypyc.
I didn’t read the entire thread of previous discussion. The referenced article is consistent with the work of Thomas Metzinger who wrote a very accessible book called “The Ego Tunnel” as a follow on to his more detailed and scholarly treatise “Being No One”
He introduced me to the ideas in this paper that he induced from his own observations of his “mystical” experiences.
It is fascinating to realize these self models exist in a wide variety of animals and the modeling of others is what makes some animals different.
Yuval Harari argues that Homo sapiens took over all other Homo species because of the development of “myth” which may be related to the Hyperactive attribution of consciousness referenced in the article. Humans cooperate at scale much better than any other species (but also fight at scale more aggressively) because we can communicate about abstractions.
This is about creating a standard for array computing in Python which has been around for more than 20 years. NumPy (which has been a de facto standard) has been around for 14 years and was based on Numeric which was around for 10 years before that. Pandas has been around almost 10 years now. The parts of the standard that are clear and will emerge are the parts that have been around and used by sufficient numbers for at least a decade.
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.