Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Erg: a statically typed language that is Python compatible

github.com

Post reply on HN
Print view View original

101–110 of 194 posts

Re: Erg: a statically typed language that is Python compatible

#101

Post by mdaniel »

joshuamorton wrote: post #47
toomanydoubts wrote: post #44

Earlier quoted context omitted.

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

> 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…

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

that must require some advanced usage of mypy then, because my experience was that even the most simple example got the finger from mypy that would have very obviously worked in Java

    mkdir alpha
    echo 'beta = True' > alpha/models.py
    echo 'from .models import beta' > alpha/__init__.py
    echo 'import alpha; print(alpha.beta)' > doit.py
    mypy --strict doit.py
    # doit.py:1: error: Module has no attribute "beta"
And look, I'm with you that I wish any codebase with an `__init__.py` anywhere in it (thus, what I think of as a project versus some ad-hoc python scripting whatever) would type-hint the absolute hell out of things, but claiming mypy or any such linting system is as strict as a strongly typed language always boils my blood

Re: Erg: a statically typed language that is Python compatible

#102

Post by fezfight »

pjmlp wrote: post #99
fezfight wrote: post #96

Earlier quoted context omitted.

I mean, you can say 'nah' all you'd like, but there's a whole section in that link on their hostility to Java. Including choice anti-competitive gates quotes! Can't say I'd blame any language dev who saw that, and said 'no thanks'.

That did not change the fact that Java worked perfectly alright on Windows, the same cannot be said for many FOSS languages that insist all OSes are UNIX clones.

Quality chefs don't work for McDonald's, either. :D

Re: Erg: a statically typed language that is Python compatible

#103

Post by bobbylarrybobby »

elcritch wrote: post #92
codedokode wrote: post #18

Earlier quoted context omitted.

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, wi…

Wow, I thought Rust's integers would let you handle integer overflows.. Apparently thats not the case and overflows are only checked in debug builds and then they just panic. Huh. After programming in Nim (and Python back in the day), I've become used to being able to detect integer overflows as a normal exception. At least for signed ints, since not all CPU support efficient overflow detection on unsigned ints. Its…

Rust has a variety of checked methods -- `checked_add` etc -- that allow for fallible int operations. And there are corresponding `wrapping_` versions that indicate wrapping is the correct behavior (and shouldn't panic in debug builds).

Re: Erg: a statically typed language that is Python compatible

#105

Post by raydev »

joshuamorton wrote: post #47
toomanydoubts wrote: post #44

Earlier quoted context omitted.

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

> 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…

> This is literally what mypy does.

Kinda silly that this is optional tooling that came from the community to solve a problem in the original implementation.

Sure, having a community and general inertia, because Python is simply good enough and no alternative has a killer feature, is certainly something you can rely on. It's okay to ask for more, though.

Re: Erg: a statically typed language that is Python compatible

#106

Post by bb88 »

elcritch wrote: post #91
gregwebs wrote: post #88

Nim is a statically typed language that is syntactically close to Python and there are some attempts at integrating the two.

Erg looks fun for small programs. Though Erg's syntax choices seem less Pythonic than I'd expected. Interesting though, some of the idioms seem handy. Though Nim definitely can be described as a statically typed Python-compatible language! I haven't used them but https://github.com/Pebaz/nimporter https://github.com/yglukhov/nimpy both seem great. Nimporter in particular looks fantastic for writing fast python librar…

> I really want to try making a native KiCad autorouter. But I don't want to figure out the C++ plugin setup and since KiCad 6 the Python APIs seem better documented and supported anyways.

So I find this to be super interesting, particularly when it comes to parts with lots of pads that one has to route.

Python would let you iterate the algorithm quickly. It's far easier to optimize the big O notation of your autorouter than in C++, say. Once you're happy with the algorithm, then you can try to optimize the slow bits in C/C++. But even things like dicts in python are still going to be super fast.

As far as speed up goes, there's PyPy, Nuitka, and Cython, which are all interesting. There's also a restricted version of python called RPython which PyPy uses to compile everything to C.

If it's me in 2022, I'd probably go with Cython. A lot of packages uses it. It's well known, and it's (mostly) python -- mostly because it would be easier to go back and forth in python rather than switching mental contexts between Nim and C and Python.

See here for the examples.

https://cython.readthedocs.io/en/latest/src/tutorial/cython_...

Good luck with the project!

Re: Erg: a statically typed language that is Python compatible

#107

Post by GlennS »

likeabbas wrote: post #16
metadat wrote: post #4

Earlier quoted context omitted.

Why so averse to direct Python?

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.

Honestly I guess it's just a difference in taste/demenour.

My background was originally in C# then Java (plus JavaScript on the side, since most of us have to do that), and when I first came to Python I found it to be a lovely language and a breath of fresh air.

I guess I would say to me it feels neat and tidy, thoughful about interface design, and gives me a sense of quality. I get a similar feeling from Clojure (perhaps even more so).

I don't find static typing as valuable as you do, and additionally I find the cost in verbosity and in time wasted solving type-checking puzzles quite painful. Perhaps if I'd spent more time with one of the more sophisticated type systems I'd feel differently (Java and C# are quite limited here), but not convinced enough to try.

Re: Erg: a statically typed language that is Python compatible

#108

Post by kevin_thibedeau »

codedokode wrote: post #18
likeabbas wrote: post #16

Earlier quoted context omitted.

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.

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, wi…

Overflowing integers is not a bug. It's literally how an adder circuit operates on fixed precision. Ignoring them by default is worth criticizing but there are plenty of times where silent overflow is correct and desirable behavior.

Re: Erg: a statically typed language that is Python compatible

#109

Post by tomp »

kevin_thibedeau wrote: post #108
codedokode wrote: post #18

Earlier quoted context omitted.

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, wi…

Overflowing integers is not a bug. It's literally how an adder circuit operates on fixed precision. Ignoring them by default is worth criticizing but there are plenty of times where silent overflow is correct and desirable behavior.

It's technically not a "bug" in Rust or C++, it's undefined behaviour, which is much worse than a bug! (and it's never correct behaviour)

Re: Erg: a statically typed language that is Python compatible

#110

Post by still_grokking »

mdaniel wrote: post #101
joshuamorton wrote: post #47

Earlier quoted context omitted.

> 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…

> 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). that must require some advanced usage of mypy then, because my experience was that even the most simple example got the finger from mypy that would have very obviously worked in Java mkdir alpha echo 'beta = True' > alpha/models.py echo 'from .m…

It's imho especially ridiculous to say some linter, that needs "hints" and annotations everywhere, is comparable to a static type system when looking at modern static languages, which have usually very strong type inference.

The point of a sound static type system is that you get a guaranty that your program is type-safe even in case not everything is "hinted properly".

With the linter approach on the other hands side it won't get better than what a dynamic language offers anyway: To be (more or less) sure everything is like intended all you can do is to run your program and pray… You can't upfront rule out for sure all kinds of errors like when using a proper static language.

Post reply on HN