See https://apocalisp.wordpress.com/2010/06/16/type-level-progra... for one take on this.
Unfortunately, I don't think many Scala users were around at that time or in that community, so lessons of the past might be learned the hard way again.
There are many encouraging signs too, though, toward better and simpler practices. We'll see which way things go.
func bar() [10]foo
with
var a [8]foo = bar
giving an error like
cannot use bar() (type [10]foo) as type [8]foo in assignment
Is it necessary to use Peano arithmetic to specify a simple type in a general purpose programming language?
But if you want you can also encode the sizes in binary or decimal numbers: http://apocalisp.wordpress.com/2010/06/24/type-level-program... http://www.ict.kth.se/forsyde/files/tutorial/apas03.html
It is not about what can be expressed, but about how you express things. You do not need function literals in Scala, but it is sure is more concise and cleaner than anonymous classes in Java. You do not need traits in Scala, but it avoids code duplication or the overhead of wrapper classes or proxies in Java. You do not need case classes and algebraic pattern matching in Scala, but it is far more concise and less error prone than having to write the obscene amounts of boilerplate you would write in Java.
And so on.