
Show HN: Mys – an attempt to create a statically typed Python-like language - eerimoq
https://github.com/eerimoq/mys
======
BerislavLopac
I was once toying with the idea to create a statically-typed Python-like
language, and I had the perfect name for it: Typhoon... ;)

~~~
HhE3334R7hf1lLF
Alternate idea: a language called Typon in which the compiler paves over typos
of keywords and symbol names.

~~~
alanbernstein
Like a whole language built on the fuckit principle.

~~~
BerislavLopac
I thought that was Perl... ;P

------
sitkack
Given that the OP is the github project owner, are you aware of
[https://chocopy.org/](https://chocopy.org/) ?

You might want to also look at Shedskin,
[https://github.com/shedskin/shedskin](https://github.com/shedskin/shedskin)
which converts implicitly typed Python programs to C++

~~~
viraptor
And at mypyc
[https://github.com/python/mypy/tree/master/mypyc](https://github.com/python/mypy/tree/master/mypyc)

~~~
eerimoq
This looks promising indeed. Thanks for sharing.

------
nicoburns
Question for the OP seeing as this is a Show HN: how does this compare to Nim
([https://nim-lang.org/](https://nim-lang.org/))?

~~~
nepeckman
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.

~~~
elcritch
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.

~~~
sullyj3
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.

------
toxik
> We don’t need a GC because RC
    
    
        L = []
        L.append(L)

------
dukoid
I am working on something similar, although with a different focus (mobile
coding):
[https://github.com/stefanhaustein/tantilla](https://github.com/stefanhaustein/tantilla)

P.S.: Might make sense to try to get to a common type-safe language spec?

~~~
eerimoq
Nice job.

I don't understand the question. Can you rephrase it? =)

~~~
dukoid
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...

~~~
eerimoq
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 =)

~~~
dukoid
Do you have any objections against using google drive for an initial list of
similarities / differences? I think the comment function could be useful....

~~~
eerimoq
Please do, but I won't promise I will contribute a lot, so don't be
disappointed. =)

------
mlthoughts2018
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.

[https://cython.org/](https://cython.org/)

------
anentropic
There is also [http://strlen.com/lobster/](http://strlen.com/lobster/)

Rust-like borrow checking with a Python-ish syntax, compiles to C++ or Wasm

------
hpvic03
Similar and relevant:

Crystal: [https://crystal-lang.org/](https://crystal-lang.org/)

Sorbet: [https://sorbet.org/](https://sorbet.org/)

------
scottrogowski
I love this.

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.

------
dec0dedab0de
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.

~~~
aidenn0
I would call Python untyped

~~~
striking
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.

~~~
aidenn0
I can import this with no errors, so Python is untyped:

    
    
        def foo():
          return 1 + "2"
    

Another example showing Python is untyped:

    
    
        x = 1
        x = "2"
    

x clearly has no type. No variables in python have types.

~~~
striking

      >>> 1 + "2"
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
      TypeError: unsupported operand type(s) for +: 'int' and 'str'
    

[https://dev.to/jiangh/type-systems-dynamic-versus-static-
str...](https://dev.to/jiangh/type-systems-dynamic-versus-static-strong-
versus-weak-b6c)

~~~
aidenn0
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.

~~~
SloopJon
For those downvoting aidenn0's comments, I was surprised to find that
"untyped" is indeed a common term that includes what many people (myself
included) call dynamically typed. See the three top-voted answers to this
Stack Overflow question, one of which includes a citation from TaPL, a
standard text (emphasis added):

"A type system is a tractable _syntactic_ method ... Terms like 'dynamically
typed' are arguably misnomers."

[https://stackoverflow.com/questions/9154388/does-untyped-
als...](https://stackoverflow.com/questions/9154388/does-untyped-also-mean-
dynamically-typed-in-the-academic-cs-world)

I still prefer the term dynamically typed, because there are useful
distinctions about value types to be made among such languages, such as those
described in striking's link.

------
dpc_pw
> Data races will occur when multiple threads uses a variable at the same
> time, which will likely make the program crash.

... or let the attacker execute arbitrary code.

------
trumpeta
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.

------
Nasreddin_Hodja
Why not to just use Cython?

------
pmoriarty
Strongly typed? You mean statically typed?

See _" What to know before debating type systems"_:

[http://blogs.perl.org/users/ovid/2010/08/what-to-know-
before...](http://blogs.perl.org/users/ovid/2010/08/what-to-know-before-
debating-type-systems.html)

~~~
azhenley
> _Type inference is generally a big win._

I see this claimed a lot, but haven’t seen any evidence.

~~~
aw1621107
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.

------
tabtab
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.

~~~
eerimoq
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. =)

~~~
h8hawk
Have you look at mypyc?

[https://github.com/python/mypy](https://github.com/python/mypy)

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.

~~~
eerimoq
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.

