Ask HN: Who regrets choosing Elixir?

Soft real-time != hard real-time.

Erlang is great at soft real-time but does not work at all for hard real-time, there simply are no guarantees, just very good average latency.

If you want hard real time (such as for in-flight control of a drone) then you should look elsewhere.

> > the average person doesn't understand that types exist in dynamically-typed languages

> Again, this is needlessly uncharitable as to what people mean when they talk about type systems, which is obviously about the capabilities of defining new types for program analysis, not that the runtime has an internal conception of types.

There is nothing "internal" about the example I gave. That's valid Python code that creates a type.

My definition (which happens to be the actual definition of the word) charitably assumes that people know dynamic type systems exist, so I don't think you can really accuse me of being uncharitable. If anything I'm being too charitable, as evidenced by this conversation.

> Sure! Looking at this, I have no idea what the size of side_length is, whether it's possible for it to be negative, or whether it's possible it to be null.

> Of course, unless you're writing purely square based software, most domains are more complex than this. But I still think it's pretty helpful to know the properties of the parameters being passed to build your square are!

Do you really not know whether side_length can be negative or null? Or are you just saying that to be argumentative? If we're pretending we don't know obvious things, why not just go all the way and pretend we don't know that side_length is a number?

As for not knowing the size: why would you want to have to know the size? The fact that this square will work with any numeric type is a feature, not a bug.

Now, consider this (disclaimer: my C++ is rusty, and I didn't syntax check this):

    class Square: Rectangle {
      private:
        double sideLength;
      public:
        Square(double sideLength) {
          this.sideLength = sideLength;
        }
    }

Let's evaluate this based on your complaints about the Python example:

1. The size of sideLength. Well, yes, this example does tell you what size it is. Which is rather annoying, since now you have to cast if you want to pass in an integer, and you might overflow your bounds. This is an annoyance, not a feature.[1]

2. We know that sideLength can't be negative because we know what squares are. The type doesn't enforce that. You could enforce that by using unsigned int, but then you can't handle decimals. And in either case, you can't use very very large numbers. I haven't worked in a static typed codebase which has an unsigned BigDecimal type, have you?[1]

3. We know that sideLength can't be null because we know what squares are. The type system technically also tells us that, but the type system telling us what we already know isn't particularly useful.

[1] Haskell's numeric type can actually handle this much more cleanly than C++, as I mentioned upthread. But in typical Haskell, you'd probably just let the types be implicit in a lot of cases.

Analogies are a great way to explain things, but not so much a great way to prove things.

If you're writing software that's life and death critical like wearing a seatbelt, you should absolutely be using a strong, statically typed language, because catching errors at runtime is completely unacceptable. But incidentally, none of the proponents of static types on this thread have talked about any languages that I would actually use for this situation. Java or C-family languages certainly aren't strongly typed enough. Type systems aren't a magic bullet.

But in the vast majority of modern software, it mostly just matters that you catch and fix bugs quickly--whether you catch those bugs at compile time or runtime is usually not as critical.

> i've used various Python libraries for runtime type-checking (based on `typing` annotations) like `typeguard`.

Let's just stop right there, since it's immediately clear you aren't answering the question I asked. You're talking about type checking, not descriptive and expressive power.

The topic is whether dynamic types are suitable for domain modeling, not whether dynamic types provide static type checking. We all agree that dynamic types don't provide static type checking.

As hwayne said, most of the time Python won't do implicit type coercion. What this means is, if you try to do something that doesn't make sense based on the types, it will throw an error rather than go on. For example:

    ~/$ python
    Python 3.7.4 (default, Oct 12 2019, 18:55:28) 
    [Clang 11.0.0 (clang-1100.0.33.8)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> hello = 'Hello, world'
    >>> one = 1
    >>> hello + 1
    Traceback (most recent call last):
      File "", line 1, in 
    TypeError: can only concatenate str (not "int") to str

To put this in context, type systems can be roughly divided into 4 categories along the strong/weak and static/dynamic axes:

1. Strong static types (makes a lot of assertions about type, checks these assertions at compile time; Haskell, ML, OCaml, Rust, C# are reasonable examples--Haskell folks would probably laugh at me including C# here, but it's the only example in widespread non-academic use). Example (C#):

    var hello = "Hello, world";
    var one = 1;
    var result = hello + one // Doesn't compile

2. Strong dynamic types (makes a lot of assertions about type, checks these assertions at run time; Python is the best example I have, but to be honest, it's not a great example--I think the type system could be a lot stronger). See the Python code above for an example.

3. Weak static types (makes few assertions about type, checks these assertions at compile time; C, C++ are good examples, although it's arguable that C actually does more checking at run time than at compile time). Example (C):

    char* hello = "Hello, world";
    int one = 1;
    char* result = hello + one; // Happily compiles

4. Weak dynamic types (makes few assertions about type, checks these assertions at run time; JavaScript is a great example of this). Example (JavaScript):

    >>> var hello = "Hello, world"
    undefined
    >>> var one = 1
    undefined
    >>> hello + 1
    "Hello, world1"

In general, I have a slight preference for static types over dynamic types, but I think that difference is overrated. I care a lot more about my preference for strong types over weak types.