I'll go against the grain here. This interview was not exactly set up in a neutral way, but nonetheless Lars Bak did make a lot of excellent points about integers, dynamic checking, tree shaking, etc. He was respectful enough IMO. A heated debate is more interesting than one where everybody agrees. That Anders has done some great work does not mean that Lars is not allowed to give a counterpoint. A technical discussion should be about tech, not about status as perceived by a certain audience. Not to mention that Lars has also done amazing work!
Very interesting video. I do wonder about one thing: you do not say anything about what happens inside an actor, except that it is deterministic. Since interacting actors can be indeterministic and a single actor cannot be indeterministic, a single actor cannot be made out of other actors internally. This raises the question: with what granularity should you model your system with actors? You could do it very fine grained, where each individual number and data structure is an actor, but this leads to massive undesirable indeterminism. On the other hand, you don't want to model your entire system as one single actor, because that is not scalable. If you modeled your system with X amount of actors, but suddenly we get Y>X cores, then you need to redesign your system to take advantage of them, which is also not desirable. What we want is a way to get deterministic results but a variable amount of parallelism. It seems that the actor model does not really say anything about this, though perhaps something can be built on top of it?
Actually, you can have a List that is both covariant and contravariant by giving it two type parameters: List<out Read, in Write>. Then you use the right type for each method. For example Add(Write elem) and list.First has type Read. Now you can pass a List<string,string> to a method that reads objects from that list, and pass a List<object,object> to a method that writes strings to that list.
Very good work! I use Python Tools a lot and it is awesome
Any plans to infer generic types too? That way you'd have the example with the function foo that just returns its argument infer the string methods for foo("bar") and the integer methods for foo(42), even if you have both in the same file. Languages like F# already infer types that way, perhaps their algorithm could be adapted.