Not necessarily. The compiler would become larger, but the VM would not. (I'm assuming that the VM can be decoupled from the compiler like Lua for restricted environments).
Statically-typed 'scripting' is a very interesting niche - e.g Lily. Not to underestimate the amount of thinking needed to devise a type system which is sufficiently powerful to be (a) correct (for some value of 'correct') and (b) as expressive as dynamic typing.
> The compiler would become larger, but the VM would not.
That's true in theory. But, in practice, if you ask your users to deal with the cognitive load of static types, they (reasonably) start expecting the performance of static types in return. At that point, you're doing a statically-typed VM, which is quite a bit more complex than a dynamically-typed one, I believe.
> (a) correct (for some value of 'correct') and (b) as expressive as dynamic typing.
Right. This is the big one, in my opinion. You can design a type system that's simple, sound, and expressive. But you only get to pick two of those adjectives. Today, because programmers are delightfully spoiled by a wealth of nice, expressive type systems, I think they won't settle for simple and sound.
Dart tried simple and expressive, but the lack of soundness made tooling much harder and really confused users who felt like they were being sufficiently penitent in their type annotations but still got punished for the sins of unsoundness anyway — type failures that were only caught at runtime.
So I think if you're designing a type system for a language today, you end up pushed pretty hard towards "sound + expressive", but now you're talking about a really complex beast.
> Today, because programmers are delightfully spoiled by a wealth of nice, expressive type systems, I think they won't settle for simple and sound.
To me that basically describes Go's type system. Very simple, allowing my brain to grok it, and part of what allows for Go's fast compile times. I'm not entirely sure what's meant by "sound", however. Safe? What kind of safe?
I find that type inference solves most of my woes of static types. At least, I've found myself reaching for Go to write quick scripts that I'd previously use Python or Node for before, especially when I need concurrency. Go doesn't have this, but for a scripting language, type inference (where possible) for function returns could be nice too.
Statically-typed 'scripting' is a very interesting niche - e.g Lily. Not to underestimate the amount of thinking needed to devise a type system which is sufficiently powerful to be (a) correct (for some value of 'correct') and (b) as expressive as dynamic typing.