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

161–170 of 194 posts

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

#161

Post by mdaniel »

Too wrote: post #115
nielsbot wrote: post #104

Earlier quoted context omitted.

Mypy is basically that. https://github.com/python/mypy

Also note that while this repo might look like a third party bolton (it started that way), the type hinting syntax is nowadays actually integrated in the language. The only thing you need to do is add appropriate type hints at function definitions and then run mypy in your build and CI and you got something that checks basically as strict as Java. For those saying it’s optional so can’t be trusted, consider that comp…

> The only thing you need to do is add appropriate type hints at function definitions and then run mypy in your build and CI and you got something that checks basically as strict as Java.

There's another comment making this claim elsewhere and I wonder if perhaps those assertions are coming from someone who doesn't write Java, or if my experience with mypy is just especially bad

I'll also point out that easily 90% of my heartburn with trying to typehint python in legacy projects is that python seems to encourage so much introspection and namespace trickery. It feels to me like the mypy audience is saying "well, there's a staticly typed language hiding in python so just don't use unsafe parts of the language and you'll be fine"

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

#162

Post by davidatbu »

LtWorf wrote: post #146
davidatbu wrote: post #142

Earlier quoted context omitted.

I read more about your repo, and it looks like typedload only does Python lists/dicts -> typed python objects(like named tuples, data classes, attrs classes, etc). Ie, the benchmarks don't include the time required to parse the JSON. So I modified the benchmarking code to include loading JSON[0], and your library still came out on top! But, it turns out I was wrong about pydantic using serde under the hood. Pydantic…

But you could use whatever module to load json and then use typedload. Having them integrated could be advantageous to save memory and avoid loading the full json first. Like loading the objects directly to their final destination as the json gets parsed. But that would be kinda complicated. I have absolutely no idea why mine isn't so used, but my model of GPL license + pay me to get LGPL license probably doesn't hel…

Ahh. It would be the license if I were to make the decision. Only because, if I were to use Python, performance must not be a big concern, so I would go for an alternative (albeit slower) library (which there isn't a shortage of) instead of paying for the non GPL license.

I think something else that might help is if you make it more prominent (if it's visible right now at all, since I can't find it) the message that tells people, at least, "contact me to arrange a different license", or at best, a pricing model.

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

#163

Post by reil_convnet »

Cool concept.

This panics for me after install. Any suggestions to make it work ? {I have Python in my path, so writing python would not return "not found" }

Starting the REPL server... thread 'main' panicked at 'cannot execute python: Os { code: 3, kind: NotFound, message: "The system cannot find the path specified." }',

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

#164

Post by smt88 »

still_grokking wrote: post #118
wawjgreen wrote: post #113

Earlier quoted context omitted.

fully agree with you. the downvotes must be by Python fanboys seething in their indented whitespaces.

I'm not a Python fan at all but still see much value in clean, DRY syntax. Significant whitespace is a huge success even in languages that switched to it late! Almost nobody in the F# or Scala¹ community would consider to switch back to that unnecessary line noise which are explicit block markers. Code should be indented for readability anyway (and almost nobody would dispute that)! So there is just no real value in…

> unnecessary line noise

It's not noise, though. It protects me from common whitespace issues like careless copying/pasting, style differences between me and other developers, and IDE/OS settings.

It's also just easier to scan. Imagine if we did the same thing with math:

    a * b / (c - d)
Look at that noise! We can get rid of some of those symbols, right? Let's replace parentheses with whitespace instead.

   a*b/ c - d
So now it's denser and I typed fewer characters, but it's harder to scan because my eyes don't register " " as quickly and easily as they register "{".

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

#165

Post by theblazehen »

still_grokking wrote: post #131
echelon wrote: post #122

Earlier quoted context omitted.

I feel this comment in my bones. I went from loving Python to hating it with a seething rage. Python package managers are all so bad that the only reasonable solution is Docker containers or vendoring everything (not easy). And even so, I've had untouched Docker builds still die because dependencies mysteriously get yanked or changed. God, I hate Python so much now.

If you like the look & feel of Python, but not the ecosystem: https://docs.scala-lang.org/scala3/book/scala-for-python-dev... Sorry for that quite random comment, but SCNR.

Thanks for that! I've heard about scala before, never investigated it. I'm really looking the like of it now

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

#166

Post by reil_convnet »

reil_convnet wrote: post #163

Cool concept. This panics for me after install. Any suggestions to make it work ? {I have Python in my path, so writing python would not return "not found" } Starting the REPL server... thread 'main' panicked at 'cannot execute python: Os { code: 3, kind: NotFound, message: "The system cannot find the path specified." }',

For someone stuck at this issue. This was fixed in latest version : https://github.com/erg-lang/erg/issues/8

Dont do cargo install erg , but rather build from source and this works.

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

#167

Post by bmitc »

HdS84 wrote: post #147
gilch wrote: post #75

Earlier quoted context omitted.

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

I really wish for a functional language which prioritzes readability. I am fluent in like 10 languages but most functional languages are just noise for me. I really like the concepts but the amount of one symbol functions, useless abbreviations (seq instead of sequence) and weird syntax just turns me off. I would like for some language which kicks the mathematicians love for noise out and embraces readability first p…

Have you tried F#?

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

#168

Post by joshuamorton »

FridgeSeal wrote: post #90
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…

Sorry, but MyPy and friends can barely hold a candle to what actual static-typing systems do - Rust, Haskell, OCaml, Typescript, even .Net (C#/F#) offer more safety and guarantees. Type hints in python are _just that_, they're hints. The whole "typed" python ecosystem relies on packages and the language using them, using them correctly, and using them consistently. In my experience so far, I've seen little widespread…

> Sorry, but MyPy and friends can barely hold a candle to what actual static-typing systems do - Rust, Haskell, OCaml, Typescript, even .Net (C#/F#) offer more safety and guarantees.

Note that you don't include the most common static languages there (cpp, java, golang), you include languages known *specifically " for their extremely powerful type systems, one of which , just like mypy, uses gradual typing!

This supports my argument!

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

#169

Post by joshuamorton »

still_grokking wrote: post #110
mdaniel wrote: post #101

Earlier quoted context omitted.

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

What is the difference between a "linter" and a "static type system"? Be specific? Pytype, an alternative python "linter" provides type inference. So it's not that. The best I can come up with is toolchain integration, which is exactly what I said.

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

#170

Post by LtWorf »

davidatbu wrote: post #162
LtWorf wrote: post #146

Earlier quoted context omitted.

But you could use whatever module to load json and then use typedload. Having them integrated could be advantageous to save memory and avoid loading the full json first. Like loading the objects directly to their final destination as the json gets parsed. But that would be kinda complicated. I have absolutely no idea why mine isn't so used, but my model of GPL license + pay me to get LGPL license probably doesn't hel…

Ahh. It would be the license if I were to make the decision. Only because, if I were to use Python, performance must not be a big concern, so I would go for an alternative (albeit slower) library (which there isn't a shortage of) instead of paying for the non GPL license. I think something else that might help is if you make it more prominent (if it's visible right now at all, since I can't find it) the message that…

> I would go for an alternative (albeit slower) library

Well now in 2022… in 2018 there was nothing else. It was (and still is) the only option on python 3.5 AFAIK.

Thanks for the advice, I guess I can put something about that.

Post reply on HN