1. 26
  1. 14

    What an unfortunate logo.

    1. 19

      I think it’s nice.

    2. 4

      What does python compatible mean? The code samples don’t like valid python at all. Am I missing something?

      1. 5

        I couldn’t find anything concrete to confirm this after a short search, but I assume that python compatible means that Erg generates python bytecode. The readme mentions that a Python3 interpreter is required to run the language.

        1. 4

          It targets CPython VM.

          1. 3

            The CPython VM is a moving target, Dogelang died that way…

            1. 2

              https://github.com/rocky/python-xasm might be of some use here

        2. 3

          Erg can be recommended to a person that:

          • uses Python, but want Rust-like robustness and comfortable compiler support.
          • and yet, doesn’t need the verbose type specifications & memory management model like Rust.

          Kind of like Nim! ;-) Only Nim compiles to native code, not Cython bytecode.

          I do like some of the features shown in the Readme, like the optional mutability annotations.

          1. 2

            I was gonna say, if you don’t want the borrow checker or the verbosity, wouldn’t you choose another systems programming language rather one that targets Python and therefore inherits all of its problems (performance, concurrency)?

          2. 2

            There is a lot of interesting stuff going on in the docs. There are a lot of ideas in the type system documentation.

            The ! is the side effect operator, which seems to strongly push you to make side effects super explicit. I think it’s unfortunate that this follows the Haskell “every side effect just goes into one category” problem. More developped effects systems would let you split out the side effects into categories (thinking of Purescript in particular).

            1. 1

              What’s up with the exclamation marks? For me they interrupt the flow of reading the code.

              1. 6

                They denote that the function has side effects. I actually think it’s quite interesting as an approach to make it clear at a glance if a function is pure!

                1. 3

                  I assume they got the idea from Ruby, but in Ruby the “!” suffix on a mutating function is just a naming convention, not part of the language.

              2. 1

                Not having kept up with Python lately, does this rely on optional Python type definitions for any libraries that are used? So if I install some untyped or incorrectly-typed Python library it’s not going to work?

                And, related: what is the state of type definitions in Python at the moment? Are most popular packages shipping with correct types? Does Python itself?