Elixir – Why the dot when calling anonymous functions?

Compile-to-JS languages add a big impedance mismatch when you inevitably need to use JS libs. Typescript's JS + types philosophy helps with this issue (it still sucks though).

I think if you really want implicit conversions, then you want to do what Perl does (never thought I'd say that): different operators for different types.

This is kinda insane. People can give reasons X is better than Y on grounds of various theoretical virtues of X -- that has nothing to do with a preference for any language.

Here's an example virute:

Behaviour should be consistent unless specialised. When specialised it should be obvious which specialisation is chosen.

(Violation: basically all of js' operators).

It's really easy to forget a closure in an event driven function and to produce difficult to debug, error prone code.

A classic example I just screwed up:

    export function getSFTPConnection(options) {
        let key = readFileSync(options.keyfile_path, 'utf8');
        let ssh = new ssh2.Client();
        return new Promise(
            (resolve, reject) => {
                ssh.on('error', reject);
                ssh.on('ready', () => {
                    ssh.sftp((err, sftp) => {
                        resolve(sftp);
                    });
                });
                ssh.on('close', (err) => {
                    reject(new Error('SSH connection closed: ' + err));
                })
                ssh.connect(
                    {
                        host: options.host,
                        username: options.username,
                        privateKey: key,
                    }
                );
            }
        )
    }

The bug is that there's not a closure around the ssh instance, so if you call this function multiple times it'll actually return the same connection instance.

The extra fun part of this bug is that the code worked - but because I was using the same instance, when I'd download multiple files in parallel, it would interleave the data, corrupting the files.

And the thing is, I know better. I've been doing js for decades.

I love js, but stuff like this is pretty frustrating, and can be a nightmare for new devs.

- Lacks structural pattern-matching.

- Lacks first-class sum-types (although they can be clumsily encoded as objects with "kind" properties).

- Static type-checking not directly (or at all) contributing to the execution performance of the code. This is particularly egregious with e.g. CPython.

Presence of the first three are the sort of things that people appreciate in Good static languages (as opposed to the status quo static languages you alluded to that Python/Ruby/JS/etc were rebelling against in the 2000s).

The last is the dead giveaway of not utopia but rather a bizarre compromised situation.

The existence of `any`; worse yet, the use of `any` in the standard library.

Mutable arrays are treated as covariant: the classic `cats : Cat[] ; animals: Animal[] = cats; animals.push(dog);` problem.

Methods are both co- and contravariant in their arguments by default, which is comically wrong. Member variables which are functions, meanwhile, are handled correctly.

`readonly` is a lie:

    const test: {readonly a: number } = {a: 0}
    const test2: {a: number} = test
    test2.a = 5

`{...object1, ...object2}` is typed as the intersection `typeof object1 & typeof object2`, which is not correct.

    const a: {a: 5} = {a: 5}
    const b: {a: 4} = {a: 4}

    const spread = <L, R>(l: L, r: R): L & R => ({...l, ...r})
    const impossible: never = spread(a, b)

You can constrain generics as `<T extends string>foo(t: T) => ...` but not `<string extends T>foo(t: T) => ...`, which makes many functions (e.g. Array.includes) much too strict about what they accept.

    Enum.map(list, fn do _ -> :ok end)

Honestly I do appreciate not having to type two characters, but I'm currently onboarding a bunch of n00bs and they're very puzzled by this one inconsistency

    fn do
      true -> "true"
      false -> "false"
      _ -> "uh..."
    end

Not to say you shouldn't like barewords! It is nice that Elixir enables that possibility for those who want it!

Remember the context. The thread started with Elang VM making it impossible to make code faster, due to the need to accommodate Erlang's dynamic typing features and do runtime checks for that. Top comment said that dynamic typing per se can't be the obstacle for programs being faster, and gave x86 as an example of a presumably dynamic VM which does not limit the speed of the programs.

So "dynamically typed" from the article here meant that there's some runtime checks you can't unsubscribe from, and due to them there's a cap on how much faster you can make your code. It applies to some extent to x86, there's also checks there like segfault for example, and maybe you could save some space on silicon if you removed them and required the machine code to be verified to never cause segfaults. But I argue that this is too much of a stretch. Runtime checks that x86 performs are negligibly simple, and x86 is not a valid counter-example for the article's point. In my view the article's point is valid.

> 1/ there is no static checker

"return 0" is the static checker for x86 machine code.

But seriously: this is not a necessary condition for something to be statically typed, it can't be.

> 2/ if there was, the interpreter would run the failing code anyway

Failing code does not exist. All code is valid.

Haskell is undoubtedly statically typed. But division by zero will still cause a runtime error.

> 3/ memory can be integers, floats, machine instructions all at the same time

Ok. Disregard what I said about machine words. The only datatype in x86 is byte. Some operations use 2 bytes, some use 4. They may interpret them differently (some may see an int, some float), but it changes nothing, since both int and float operations are operations on bytes.