For the sake of completeness, might as well mention Nuitka [1] (another Python -> C compiler), Cython (Python-like language that compiles to C), and Numba (LLVM-based JIT compiler for a limited subset of Python).
Not OP, but a big Nim fan. I think Nim has made a mistake by marketing itself as Python inspired. I know why it does so; Python is a very successful language and as a niche language, Nim wants to associate itself with an established one. But in my experience, Nim has a very small overlap with Python. It is whitespace significant, prefers short words to symbols for operators, and has a robust stdlib. But if you look at the actual language semantics, or even the keywords, Nim is not really related to Python. I'd go as far as saying Nim is more similar to a Lisp than it is Pythonic (which works fine for me, as I prefer Lisp to Python).
All of this to say, the OPs language seems much more Pythonic. The key words, the built in functions, the class system, all seems designed to match Python as closely as possible.
It took me a couple of weeks to realize Nim’s semantics are really different. Despite that Nim feels like an alternate reality of Python 2 -> 3 that went more lispy and a bit Pascal-ish. It gives me the old Python 2.7 vibe. Though I’d still prefer ‘def’ to ‘proc’ but that’s pretty minor to me.
It’s interesting to see how well the typed Python syntax maps to a static implementation of Python. The speed should probably be a lot faster than CPythin too for many cases.
The really nice thing about proc is that emphasizes that they are in fact procedures, rather than mathematical functions - a distinction that becomes more relevant as FP gains mindshare.
It's a wide question, and I don't have a good answer. One obvious difference is the syntax. I prefer Python's syntax over Nim's, but at the same time I find Python slow sometimes and hard to use in embedded systems. I'm aiming to create something similar to Nim's toolchain to address that.
P.S. Since you’re using C++ shared pointers, you might want a cycle detection. But like Nim’s new ARC you can let the programmer beware and ensure their programs don’t produce cycles. It seems handy to allow pure RC’ing for embedded devices.
It might make sense to try to support the same subset of Python in both projects. On the other hand, this might make experimentation harder... And there seem to be many differences, for instance I am trying to move towards async/await... But there might also be areas that could be easy to get consistent, e.g. how local variables are declared...
p.s. And I wasn't aware of Cocopy either. Having a list of similarities and differences of all three might be useful...
I like the idea. If our languages are similar it could even make sense to stop developing one of them and focus on the other, but that's probably far fetched. I'll have a look at yours to get a better understanding of what it looks like and where it shines. Maybe we meet again =)
Do you have any objections against using google drive for an initial list of similarities / differences? I think the comment function could be useful....
Cython is a great tool for this. It’s a superset of Python with full static compilation support for native CPython or for pure C or C++ extension modules.
I have nothing else to say except that I want this to happen.
Python is an amazing language which is missing two things - static types and speed. I starred your repo and am looking forward to seeing it progress.
This looks cool. Is there anything specific you're trying to do with Mys that another language didn't do? Nim comes to mind as being in a similar space.
Small nitpick about the title: Python is strongly typed.
Well, probably not. Nim is similar, but I prefer Mys' Python-like syntax. Mys' toolchain will probably be similar to Nim. That is, generating C/C++ code.
Sorry about the confusion. Mys is statically typed. I changed the HN post from strongly to statically to make it clear.
You would be wrong. Try adding a string and number together. That's a type error. Unlike in JS or C, where a lot of these conversions are implicit and only warn if anything.
Python determines the types at runtime, but it is very clear about what few operations you're allowed to do on any given set of types.
What that article calls "dynamically typed" is commonly referred to as "untyped" in PL research.
The program '1 + "2"' is a perfectly valid python program with well defined behavior (it signals a TypeError). This demonstrates that you can in fact add integers to strings in python. Of course whether or not you can add integers to strings is completely orthogonal to whether or not a language is typed. Both typed and untyped languages may overload the addition operator.
I wouldn't call C untyped because implicit conversions happen all the times. It's just that it assumes that since you declare your variables with a type, when you assign them, you know what is going to happen.
Isn't Dotty basically statically typed Python? They added whitespace syntax recently and thanks to Scala native it should be possible to have a LLVM backend somewhere down the line.
Might depend on what "win" is supposed to mean in this context. If it's intended to mean "languages with type inference are more productive", then sure, evidence would be nice. If it's intended to mean "type inference helps cut down on the need for explicit type annotations", I don't think evidence is really necessary.
Before making Yet Another Language, I'd like to see a good analysis of the options and trade-offs they offer: what does each design choice make easier and harder. There is probably no free lunch, but maybe we can find a better lunch by balancing things carefully.
For me it's pretty simple. I love Python. I like speed. I like embedded. This is an attempt to take advantage of Python's type hints to create fast and hopefully small binaries that can be executed on embedded devices limited amount of resources (both CPU and RAM).
There are probably other languages that would serve the same purpose, but oh well, I can't resist creating another. =)
Its a compiler that support subset of python and mypy's team including Guido work on it. It would be great if this kind of efforts have been done on more realistic project.
It compiles statically typed Python modules to CPython C extension modules. I do not know the details, but it sounds like that's a major difference to Mys.