[HN Gopher] Erg: a statically typed language that is Python comp...
___________________________________________________________________
Erg: a statically typed language that is Python compatible
Author : ArdelleF
Score : 74 points
Date : 2022-08-13 17:45 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| kortex wrote:
| This is exactly the sort of thing I've been looking for. Not sure
| how production-grade it is* but definitely gonna use it for some
| scripts and data processing. I love python, most of all its
| ecosystem, and use types extensively, but it still misses some
| things I wish it had better support for. Namely: immutability,
| and explicit side effects, which are both prominent features of
| Erg. So this is super exciting.
|
| Does anyone know if Erg code can be (ergonomically) called from
| python? I think that'd be the real killer feature, being able to
| write erg modules and pull it into the greater python ecosystem
| as easily as native python.
|
| * looks like the project is nary a few weeks old? Can't really
| dig into the git history on mobile, it freezes my browser
| traverseda wrote:
| Not sure why I'd want to use this, presuming I was already happy
| with python. Especially now that python's type hinting is more
| mature. Looking through the feature set the main thing it seems
| to provide is a type system, but with a syntax I don't like as
| much as python's type hinting.
| davidatbu wrote:
| This is sort of speculation on my part: The fact that static
| typing PEPs can't easily introduce syntactic changes to the
| language (I don't think there has been a syntactic change
| introduced because of static typing ever since Python 3.5) will
| really hold back Python's static typing from being ergonomic at
| least, and "fully capable" at the worst.
|
| I think that limitation of statically typed Python alone is
| enough to give this new language a chance.
|
| It's also looks like the type _inference_ of erg will be better
| than the current Python checkers.
| frou_dh wrote:
| I was just playing around with Python 3.10 for the first time
| today. I made an algebraic/sum-type (dataclasses +
| typing.Union), then did some structural pattern matching on a
| value of that type (match statement), and Mypy could tell me
| statically when the pattern matching wasn't exhaustive!
|
| I think it's pretty damn amazing how well Python has been
| able to evolve into the realm of static typing. And no
| unofficial superset syntax required!
| davidatbu wrote:
| That's wonderful to hear! It's been > 1 year since I used
| daily-drove Python, so my comments do lag behind the
| progress by at least a year. Maybe an unofficial superset
| syntax is indeed not required!!
| svetb wrote:
| Mypy can work really well in many cases, but we seem to get
| bitten by bugs on a daily/weekly basis. There are >1,000
| currently open on Github [0], so it doesn't take much
| effort to hit one. And having the type-checker tell you
| that something's not valid when it actually is is a real
| turn-off...means that we end up with code that's riddled
| with "# type: ignore", which kind of defeats the point.
|
| Pylance (the VSCode built-in linter, based on Pyright I
| believe) tends to do a better job than Mypy, but not as
| easy to integrate into CI. It's a real shame that the
| Python ecosystem doesn't have anything nearly as robust as
| TypeScript.
|
| [0] https://github.com/python/mypy/issues?q=is%3Aopen+is%3A
| issue...
| gilch wrote:
| Mypy still couldn't handle recursive types, last I checked.
| Pyright can do it, but seems to have trouble with even
| basic type inference. The annotation syntax is working OK,
| although it tends a bit verbose, but the type checkers are
| still crippled IMHO.
| LtWorf wrote:
| The fact that it's written in js, probably not by python
| developers makes me distrust it.
|
| Anyway I tried it on a mypy clean codebase and it gave a
| gazillion false positives so I never bothered to
| integrate it more properly.
| davidatbu wrote:
| I absolutely feel comfortable vouching for Pyright!
|
| Last I used it, it was miles ahead of mypy in terms of
| speed, easy-of-use (it's an LSP!), correctness (simply
| has less bugs), and feature completeness (has implemented
| every new static typing feature that I've wanted to use
| months ahead of mypy).
|
| The maintainer was also super-responsive on Github:
| replied to my issues in hours/minutes, and often released
| minor versions with bugfixes one or two days after issues
| are reported.
| epgui wrote:
| As someone coming from FP and having to use Python at work, I
| have the opposite perspective: I am constantly frustrated at
| how bad the type hinting is, and how few "guardrails" there are
| generally. :(
|
| I don't know if this is what I'm looking for, but I think
| there's a ton of room for innovation and improvement in the
| python world. I welcome this language and I think it's quite
| interesting!
| [deleted]
| DreamFlasher wrote:
| Amazing, but... Why not done with Python syntax? And no, mypy is
| not a solution. Even with strictest mypy it is still possible to
| have errors that would have been caught with static typing.
| gilch wrote:
| Even with strict static typing, it's possible to have errors.
| Mypy is static typing.
| epgui wrote:
| Is there documentation in English? The japanese[1], however
| wonderful a language, would be a major barrier to entry for me.
|
| [1] http://mtshiba.me/TheErgBook/
| tyingq wrote:
| https://erg-lang.github.io/
| briandw wrote:
| I have so much trouble when trying to refactor projects bigger
| than a few hundred lines in python. If I could integrate this
| into Jupyter easily I'd be excited to try it out.
| gilch wrote:
| You do know you can statically type Python, right?
| kortex wrote:
| We have a 50kloc all-python backend, with very high (>90%) type
| integration (that last mile is hard). I've done pretty big
| (thousands of loc) refactors and it's pretty painless. Night
| and day compared to the pre-typed python days.
| aYsY4dDQ2NrcNzA wrote:
| Type hinting combined with PyCharm's refactor commands work
| well for me. I assume the other IDEs work just as well.
|
| Are you using an IDE?
| Arbortheus wrote:
| It would be nice if someone created a typescript for python.
| Something that allows us to wrangle control and sanity over reams
| of legacy untyped python madness.
| davidatbu wrote:
| I think both `erg` and statically typed Python are both
| attempts at doing exactly that.
|
| May be what you mean is a static typing solution for Python
| whose syntax is a superset of Python syntax (which I don't
| think `erg` is), but isn't identical to Python's syntax( ie, it
| is a _strict_ superset, which statically typed Python 's syntax
| isn't). Typescript is exactly that for JS.
|
| In that case, I agree with you that such an attempt would
| indeed be very interesting because it would allow for more
| aggressive exploration of ergonomic typing constructs while
| maintaining that any valid Python would be valid in that new
| language as well (just like TS).
| faizshah wrote:
| Related question, how does typescript's gradual typing system
| work? Are there any resources on how they implemented and
| architected it?
| tingletech wrote:
| why not use the built in typing?
| https://docs.python.org/3/library/typing.html
| Reubensson wrote:
| it doesnt enforce the types in any way
| isoprophlex wrote:
| You can run, for example, pre-commit checks such as mypy to
| enforce some semblance of sanity.
| joshuamorton wrote:
| Neither does typescript. All the types are removed at
| runtime, it's up to you to ensure that your build process
| and tooling correctly validates the types. The same is true
| for python, and the ecosystem has really great tools for
| doing this.
| kortex wrote:
| Use pydandic for serde/IO validation, and mypy --strict.
| And minimize cheating e.g. Any. I think you'll find it
| extremely stable and a totally different beast than usual
| python.
| LtWorf wrote:
| I wrote typedload before pydantic was a thing. It's
| faster and actually works well with mypy and python's
| type system.
|
| Pydantic requires inheritance and requires a modified
| mypy because it uses types its own way rather than the
| python way.
|
| Oh, typedload is faster than pydantic, despite being pure
| python instead of an .so file.
| davidatbu wrote:
| I would be very interested in seeing some benchmarks!
|
| I'm pretty sure that serde, the rust library that
| Pydantic uses, is faster than the JSON parser written in
| C in the python standard lib, so I'd be very surprised if
| your pure python validation library beat pydantic.
| LtWorf wrote:
| https://ltworf.github.io/typedload/performance.html
|
| At the bottom there are instructions on how to run the
| benchmark locally.
| boxed wrote:
| Mypy?
| nope96 wrote:
| But not really a pythonic syntax. Reminds me more of ruby? i.e.:
|
| > 2.times! do!:
| Zomatree wrote:
| This is what is putting me off the most of this, the syntax
| feels very unreadable for something that is meant for python,
| which has a very readable and open syntax, even typescript's
| sometimes messy typing is for the most part more readable than
| this
| mattbillenstein wrote:
| Same, this just seems soooo very ugly imho
| latenightcoding wrote:
| At this point I'm open to try anything that will give me access
| to the python ecosystem without having to code in Python. From
| the FAQ it looks like Erg code gets transpiled to python
| bytecode.
| adenozine wrote:
| Fable for F# is working on something like that.
|
| a link:
| https://fable.io/blog/2022/2022-06-06-Snake_Island_alpha.htm...
| IshKebab wrote:
| I don't see how it can though - at least it can't do it in a
| statically typed way because half of the Python ecosystem
| hasn't bothered with static types and the semantics of the type
| hints that do exist isn't defined.
|
| So you'll end up with everything you import being `any` which
| is not really any better than just using Python.
| adsharma wrote:
| If your problem is with the runtime cost of python, do consider
| transpilers such as py2many that generate rust code.
|
| In order for this to succeed, python libraries would have to be
| rewritten without the C API in the dialect/subset of python
| supported.
|
| I wonder if erg could strive to use a subset of python mostly
| and innovate narrowly in just a couple of places to make python
| more functional.
| div72 wrote:
| It'd not fully solve your issue, but have you ever seen
| https://github.com/py2many/py2many ?
| metadat wrote:
| Why so averse to direct Python?
| zamalek wrote:
| For me:
|
| * Download and just run doesn't work. (e.g. Node, dotnet,
| cargo do this well). Hell, I've generally had more success
| with C++ in this regard.
|
| * The syntax can be used in an extremely terse way, and that
| terseness seems to be idiomatic.
| likeabbas wrote:
| Slightly related question: why do people love Python so much?
| Or, any dynamically typed language? There's almost nothing
| that has frustrated me more in a professional setting than
| trying to figure out what some dynamically typed code is
| doing and ensuring I don't break anything by making changes.
| gilch wrote:
| Python is statically typed though. [1][2][3][4]
|
| These aren't just some third-party tools bolted on. The
| type annotation syntax is built into the language[5] and
| standard library[6][7].
|
| I personally find static typing to be more trouble than
| it's worth most of the time. Industry typing metalanguages
| are not expressive enough to deal with even fairly basic
| real-world programs and force you to write bad code to work
| around the type checker's stupidity. And, of course, you
| still have to write tests. Maybe someday they'll catch up
| to Idris. Python's static typing is no better, but at least
| it allows you to turn it off when it's not worth it.
|
| [1]: https://github.com/microsoft/pyright
|
| [2]: https://github.com/python/mypy
|
| [3]: https://github.com/google/pytype
|
| [4]: https://github.com/facebook/pyre-check
|
| [5]: https://peps.python.org/pep-3107/
|
| [6]: https://peps.python.org/pep-0484/
|
| [7]: https://docs.python.org/3/library/typing.html#module-
| typing
| codedokode wrote:
| Because you can do a lot with little typing and there are
| lots of great libraries. Python is probably the best choice
| when you need to get something done quick or calculate
| something when performance is not important. It is also not
| an exotic functional language without loops and filled with
| linked lists.
|
| Also, in Python integers do not overflow, unlike in Rust, C
| and other buggy languages.
|
| If you name a language, with high probability Python will
| be better in something unless it is about performance.
|
| What I don't like: no type hints in many libraries, some
| libraries are not type-hint friendly, lot of unnecessary
| dynmamic features (like being able to patch modules in
| runtime) and absolutely no caring about performance and
| being able to compile into machine code.
|
| > trying to figure out what some dynamically typed code is
| doing
|
| There should be type hints.
| toomanydoubts wrote:
| >There should be type hints.
|
| "Hey, this variable is probably of this type. Now go on,
| run the code and launch a debugger the same way you would
| if there was no hint just to make sure it's correct. Oh,
| and don't forget to check all the possible code paths
| that lead to this to make sure you've exhausted all
| possibilities."
|
| Don't get me wrong, type hints are cool but they're just
| a toy compared to proper static typing.
| joshuamorton wrote:
| > Oh, and don't forget to check all the possible code
| paths that lead to this to make sure you've exhausted all
| possibilities."
|
| This is literally what mypy does.
|
| There's no difference between a mypy-enabled codebase and
| a java codebase in terms of static typing (other than
| that mypy actually supports a generally richer type
| system).
|
| Like yes if you aren't validating the type hints you
| aren't getting the value, but if you are, _you don 't
| need to run the code_! I get most of my python errors at
| compile time, and you can too. I promise.
| toomanydoubts wrote:
| >no type hints in many libraries, some libraries are not
| type-hint friendly.
|
| >There should be type hints.
|
| So, is it one or the other?
| VectorLock wrote:
| >ensuring I don't break anything by making changes
|
| I think this is a problem in both static and dynamic
| languages and is pretty much solved in the same way: you
| test your code.
| toomanydoubts wrote:
| But is it the same problem, really? Static typing
| eliminates a whole class of issues that dynamic typed
| languages don't. Of course you can still have logical
| bugs, but it's definitely not the same thing. I don't
| know how to put it better, but you should try writing
| haskell sometime and you'll see what I mean.
| gilch wrote:
| And static languages introduce a whole class of issues
| that dynamic languages don't have to deal with. You have
| to learn a separate metalanguage just for the types that
| isn't expressive enough to do things that are easy in a
| dynamic language, and even if it were, you'd still have
| to write everything twice: once in the real language, and
| once again in the type language. And then you still have
| to test, don't pretend you don't. If tests are both
| necessary and sufficient, then why bother with the type
| language? The static typing is not worth the cost.
| toomanydoubts wrote:
| >you'd still have to write everything twice: once in the
| real language, and once again in the type language
|
| Hmm, no I don't? Actually, 99% percent of the time I'm
| writing haskell, I can just write it like it's a
| dynamically typed language and the compiler/lsp will just
| say "Hey, I can see this is an int/string/list/whatever,
| want me to annotate that for you"?
|
| Hindley-Milner type systems are way way too powerful and
| I can count on my fingers how many times the compiler was
| confused when inferring types and I had to manually
| annotate it.
|
| And yes, of course I have to test the logic of my code.
| What I don't have to test is that my code behaves when
| given wrong-type values and that all the code calls
| functions with values of the correct type, because the
| compiler is doing that for me.
| hsbauauvhabzb wrote:
| So why not static with the ability to ignore hinting or
| similar? C# does this.
|
| I think function definitions should be statically
| defined, but the actual body of a function could easily
| stay largely dynamic.
| gilch wrote:
| I do think that's helpful compared to the strict
| alternative, but much of the up-front cost is still
| there. You still write most things twice, and the static
| type checker still slows you down when prototyping. You'd
| still be tempted to write bad code to work around the
| insufficiently-expressive type language, rather than
| write it in the most natural way, and only give up when
| it's too hard.
|
| You can also approach this from the other direction: why
| not start with a dynamic language for the rapid
| prototyping and gradually introduce typing as the code
| stabilizes? Python and Typescript do this.
| analog31 wrote:
| I have a hunch that a lot of Python users didn't carefully
| evaluate the language on its merits, but rather, just
| started using it. In my own case, I was using Visual Basic
| 6 before Python, and mostly Turbo Pascal before that. A
| huge attraction of Python was the libraries -- scipy,
| matplotlib, etc. In fact when a lot of people say they're
| using "Python," they're actually referring to Python plus a
| large collection of libraries that came from somewhere.
|
| It's the community. Network effect looms large.
|
| While typing is dynamic, I rarely see this being used,
| perhaps with the exception of identifying empty variables
| with None. Most identifiers are born and die the same type.
| It would be interesting to see how much effect dynamic
| typing has on the rate of programming errors.
|
| Also, for me, Jupyter is huge.
| cpeterso wrote:
| I suspect the same. People adopt Python because its clean
| syntax and REPL make the language approachable and easy
| to get started and then the huge library ecosystem helps
| you glue together (in a good way) powerful systems. But
| how many Python users and libraries actually use the
| language's extremely dynamic runtime behavior? Something
| they're paying for with a big performance penalty and
| surprising bugs.
| gilch wrote:
| Numpy uses magic methods (Python's version of operator
| overloading). Django uses metaclasses. Pytest dynamically
| rewrites assert statements using AST. I'd say it's pretty
| common, at least in libraries. I certainly depend on
| Python's dynamism when fully leveraging the REPL.
| gilch wrote:
| Python's popularity has grown pretty steadily over
| decades. It retains users because of its merits and
| became popular in multiple niches more or less
| independently.
| qsort wrote:
| - Huge ecosystem.
|
| - Common stuff (opening files, dealing with databases,
| string processing, math, regexps) is very easy. Sane
| defaults.
|
| - Works well with the existing C ecosystem. It's not a
| "rewrite everything in X" language.
|
| - It's everywhere, most machines run Python just fine.
|
| - It doesn't treat Windows like a second-class citizen.
|
| - It doesn't force upon you a programming model that you
| might or might not care about. It's not a puzzle language
| where everything is a monad, or everything is a class, or
| everything is some weird widget. Write the damn code.
|
| - I'm personally not a fan of the language itself, but it's
| mostly a bog-standard algol if you don't poke it too much.
| It's relatively standard, people just get it even if Python
| isn't their main language.
|
| - Very personal point, but it's the only language I can
| edit with a plain text editor. Think nano, vi, Windows
| Notepad, that kind of thing. I don't know what to tell you,
| maybe it's my tiny monkey brain, but I can't do the same in
| Java or C++. Not that it's my preferred way to edit
| software, but I like having that option in a pinch.
|
| At least for what I do (developer, but with a data
| engineering/data science flavor) the overall architecture
| is usually the important thing, so admittedly some
| downsides might hit me less.
|
| I'd still rather write medium-to-large pieces of software
| (say 10,000+ LOC) in something else (Java, C#, C++,
| something boring like that), but it's pretty much
| unbeatable for small programs as far as I'm concerned.
| gilch wrote:
| Anecdote, but I like the Python community's emphasis on
| "readability counts". I did not get that from e.g. Ruby.
|
| Python's internals are also relatively accessible and easy
| to work with, so it's smooth sailing once you have that
| need. The language starts out easy, and grows with you. Of
| the languages I've tried (and there are many), only
| Smalltalk and the Lisp family were comparable in
| expressiveness.
|
| The language mostly gets out of my way and lets me do what
| I want. I don't feel like I have to fight the compiler (at
| least until I tried Mypy) or write a lot of tediously
| verbose boilerplate just to get out a "Hello, World!" like
| I did in Java.
|
| Unlike, say, JavaScript, Python is pretty strongly typed
| and fails fast. The stack traces almost always point you to
| the exact location of the problem (unlike the JS tendency
| to propagate `undefined` everywhere). There aren't a lot of
| surprises or gotchas. I can pretty much run it in my head
| just by reading the code and be right most of the time. I
| cannot say the same for C++ or JavaScript, which naturally
| tend to become inscrutable without discipline.
| sdeframond wrote:
| I believe dynamically typed languages are easier to use
| than old-style statically typed langages (Java, C, etc).
|
| More modern statically typed languages can be quite easy to
| use (I am thinking of Scala) but none provides an ecosystem
| as rich as python's.
|
| Plus, recent static languages (Scala, Rust, Haskell or even
| Elm) are more oriented toward "Software Engineers" or CS
| academics. Python appeals to a lot of "programmers" who's
| main job is actually data science, mechanical engineering,
| biologist...
| epgui wrote:
| I think the latter point hits the nail right on the head:
| the preference for python is probably more of a social
| issue than a technical one at this particular point in
| History.
|
| I think when FP languages and paradigms become the norm
| (you can quote me on this, I predict that it's only a
| matter of time), preferences will change. People tend to
| prefer what they know, and it will take some time for
| culture to change.
| gilch wrote:
| I found Scala horribly overwrought compared to either
| Java or Haskell. It's like it tried to mush together two
| different type systems and got the worst of both worlds.
| Languages do not need to be that complex. My next JVM
| language was Clojure, and I've never looked back. I'd try
| Kotlin before I'd go back to Scala.
| smitty1e wrote:
| I think in python very easily.
| agumonkey wrote:
| casual and fast prototyping
|
| now you can have succint code and fast repl (ala sml) but
| you don't get the libs
| gilch wrote:
| No shortage of options, e.g. Dg, Mochi, Coconut, and Hebigo
| (based on Hissp[1]).
|
| [1]: https://github.com/gilch/hissp
| vonwoodson wrote:
| Oh, man, have I got a treat for you: go checkout hylang.org -
| Hy is a lisp that (ab)uses the python AST to give you access to
| the entirety of python, but gives you a pretty lisp syntax.
| cyanydeez wrote:
| Why is the logo 69
| cpeterso wrote:
| The logo is (also) the letters _E r g_ smooshed together
| unwind wrote:
| Pretty sure it's trying to be an ambigram [1] i.e. readable
| upside down.
|
| 1: https://en.m.wikipedia.org/wiki/Ambigram
| formerly_proven wrote:
| Nice.
| steezeburger wrote:
| That icon tho
| phoe-krk wrote:
| https://github.com/erg-lang/erg/blob/726b7b80fcf06c6c4099b62...
|
| Using a 69 as your language's logo? I actually don't think it
| has been done in a serious-seeming project before.
| Kamq wrote:
| Seriousness is overrated. Have some fun with your projects
| tasty_freeze wrote:
| it is actually "Erg", not 69
| phoe-krk wrote:
| As much as I enjoy the tongue-in-cheek logotyping, "Erg" is
| certainly not the first thing that my mind reads when
| looking at it.
| travisgriggs wrote:
| I couldn't bring myself to use the phrase "tongue in
| cheek" here. I was going to, but couldn't.
| travisgriggs wrote:
| Lol. I guess I made the same mistake. /me wonders if
| there's some double entendres going on here.
___________________________________________________________________
(page generated 2022-08-13 23:00 UTC)