Comment by kstrauser
8 hours ago
Anyone would identify that as a shortcoming, albeit one deemed worthwhile giving the flexibility it brings to the table. It’s certainly not an advantage of the language to have to do that slow check on every operation. It’s just a downside to all the dynamism we enjoy.
Also, I said I didn’t write a language. I never said that I didn’t maintain my own local fork so I could play with the VM and add opcodes to it and see what happens if I try experiments like “assume that all(type(_) is type(list[0])) for _ in list[i..])”, which I’ve done just for fun to see how it’d explode when that assumption fails.
But no, I haven’t written a language of my own, I apparently I’m not qualified to have an opinion.
> Anyone would identify that as a shortcoming
I don't identify that as a shortcoming, because it enables the dynamism. A "worthwhile shortcoming" is just another way of saying "tradeoff".
You might as well say C++'s performance is a shortcoming because it's a result of static typing, which is hard to write compared to dynamic languages. Or Rust's safety is a shortcoming because it has worse compile times compared to Go. Or Java's JVM is a shortcoming because it doesn't compile to machine code like C.
Just because a language doesn't have the same features as another doesn't mean it suffers a shortcoming. A shortcoming only exists in the context of your own use case, which is different from everyone else's. What you label a "shortcoming" is the feature others are looking for in their language.
> But no, I haven’t written a language of my own, I apparently I’m not qualified to have an opinion.
Your opinion is fine, the OP was just saying that they would like to hear a qualified opinion because they are left wondering how a language designer might change Go for the better.
But you should try designing and implementing your own language, it's a lot of fun and a worthy exercise for any dev.