8 ms·
Show HN: Mys – an attempt to create a statically typed Python-like language
- BerislavLopac 6y agoI was once toying with the idea to create a statically-typed Python-like language, and I had the perfect name for it: Typhoon... ;)
- HhE3334R7hf1lLF 6y agoAlternate idea: a language called Typon in which the compiler paves over typos of keywords and symbol names.
- alanbernstein 6y agoLike a whole language built on the fuckit principle.
- BerislavLopac 6y agoI thought that was Perl... ;P
- nicoburns 6y agoQuestion for the OP seeing as this is a Show HN: how does this compare to Nim (https://nim-lang.org/ https://nim-lang.org/)?
- eerimoq 6y agoIt'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.
- nepeckman 6y agoNot 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 6y agoIt 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 6y agoThe 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.
- dukoid 6y agoI 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 6y agoNice job. I don't understand the question. Can you rephrase it? =)
- dukoid 6y agoIt 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 6y agoI 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 =)
- dec0dedab0de 6y agoThis 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 6y agoI would call Python untyped
- striking 6y agoYou 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.
- lgeorget 6y agoI 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.
- aidenn0 6y agoI 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.
- sitkack 6y agoGiven 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++
- sitkack 6y agoPrevious discussion of ChocoPy is here, https://news.ycombinator.com/item?id=20957420 https://news.ycombinator.com/item?id=20957420
- eerimoq 6y agoNo, I am not aware of ChocoPy. Thanks for letting me know. Shedskin uses the Python interpreter if I remember correctly. I aim not to.
- sitkack 6y agoIt can make both standalone executables as well as extension modules that can be loaded into cpython2.7
- viraptor 6y agoAnd at mypyc https://github.com/python/mypy/tree/master/mypyc https://github.com/python/mypy/tree/master/mypyc
- eerimoq 6y agoThis looks promising indeed. Thanks for sharing.
- nerdponx 6y agoFor 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). [1]: http://nuitka.net/ http://nuitka.net/ [2]: https://cython.org/ https://cython.org/ [3]: https://numba.pydata.org/ https://numba.pydata.org/
- pmoriarty 6y agoStrongly 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-debating-type-systems.html http://blogs.perl.org/users/ovid/2010/08/what-to-know-before...
- eerimoq 6y agoUpdated the GitHub repo and the HN post. Thanks.
- azhenley 6y ago> Type inference is generally a big win. I see this claimed a lot, but haven’t seen any evidence.
- aw1621107 6y agoMight 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.
- ajkjk 6y agoI think the claims might be the evidence you're looking for.
- lioeters 6y agoNot sure if this qualifies as evidence, but a quick search shows there are papers exploring the topic of whether type inference is a "big win" or not. Benefits of Type Inference for an Object-Oriented Real-Time Language https://www.researchgate.net/publication/220391749_Benefits_of_type_inference_for_an_object-oriented_real-time_language https://www.researchgate.net/publication/220391749_Benefits_... EDIT: Granted, this particular paper may be more claims without solid evidence.
- dpc_pw 6y ago> 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.
- tabtab 6y agoBefore 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 6y agoFor 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 6y agoHave 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 6y agoIt 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.
- mlthoughts2018 6y agoCython 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/
- scottrogowski 6y agoI 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.
- Nasreddin_Hodja 6y agoWhy not to just use Cython?
- toxik 6y ago> We don’t need a GC because RC L = [] L.append(L)
- trumpeta 6y agoIsn'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.
- hpvic03 6y agoSimilar and relevant: Crystal: https://crystal-lang.org/ https://crystal-lang.org/ Sorbet: https://sorbet.org/ https://sorbet.org/
- anentropic 6y agoThere is also http://strlen.com/lobster/ http://strlen.com/lobster/ Rust-like borrow checking with a Python-ish syntax, compiles to C++ or Wasm