It's a shame because it is just as effective as pissing in the wind.
Of course, by your reasoning this also means you yourself have designed a language.
I'll leave out repeating your colorful language if you haven't done any of these things.
Actually I think that's a reasonable argument. I've not designed a language myself (other than toy experiments) so I'm hesitant to denigrate other people's design choices because even with my limited experience I'm aware that there are always compromises.
Similarly, I'm not impressed by literary critics whose own writing is unimpressive.
No, I stick by my position. I may not be able to do any better, but I can tell when something’s not good.
(I have no opinion on Go. I’ve barely used it. This is only on the general principle of being able to judge something you couldn’t do yourself. I mean, the Olympics have gymnastic judges who are not gold medalists.)
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.
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.
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.
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.