[kstrauser]

I’ve never been a rock star, but I think Creed sucks.

I really don’t like your logic. I’m not a Michelin chef, but I’m qualified to say that a restaurant ruined my dessert. While I probably couldn’t make a crème brûlée any better than theirs, I can still tell that they screwed it up compared to their competitor next door.

For example, I love Python, but it’s going to be inherently slow in places because `sum(list)` has to check the type of every single item to see what __add__ function to call. Doesn’t matter if they’re all integers; there’s no way to prove to the interpreter that a string couldn’t have sneaked in there, so the interpreter has to check each and every time.

See? I’ve never written a language, let alone one as popular as Python, but I’m still qualified to point out its shortcomings compared to other languages.

[ModernMech]

> See? I’ve never written a language, let alone one as popular as Python, but I’m still qualified to point out its shortcomings compared to other languages.

You kind of undermine your argument here, because someone experienced in building languages wouldn't identify this as a shortcoming of Python compared to other languages, but rather a design choice that was made to support other features; designing a language is all about making these tradeoffs to achieve specific design goals. It's one thing to keep boxed values around and be slow because of it -- it's another to do so because you want to support a dynamic type system.

This might be what the other poster was getting at when they said they don't want to listen to non-experts here, because the criticisms are usually shallow and based on personal programming preferences rather than an actual critique of language design.

[kstrauser]

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.

[ModernMech]

> 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.