4 ms·
I think they actually make a fair point because in this case "hard to do" probably equates to "makes the compiler a lot slower". Go is very easy to switch to f
by breakingcups 6y ago
I think they actually make a fair point because in this case "hard to do" probably equates to "makes the compiler a lot slower".
Go is very easy to switch to from most other languages so I don't think making it harder to switch is a design goal from the team.
When Go came on the scene, I actually really appreciated the fact that they truly explored what a new language could do differently, especially because it was coupled with a strong philosophy.
Now, since 1.0 there have been plenty of decisions made which I dislike. Still, I think the glasses through which you choose look at the Go teams motive aren't fair. Why wouldn't designers of a programming language like Go think it through very carefully, weigh every angle and decide to settle on a lesser used but possible equally valid solution compared to 80% of the languages out there?
- centril 6y ago> I think they actually make a fair point because in this case "hard to do" probably equates to "makes the compiler a lot slower". They are wrong in this case. When considering whether to allow `foo<T>();` in Rust, we measured the performance impact that infinite look-ahead / backtracking would have in that case. The result was negligible. Why? Because the amount you have to look-ahead, before you can say "definitely wrong; let's turn back", in realistic code is bounded to maybe max 30 for some very complex generics. It's however much more likely that no back-tracking occurs at all because the parse will be correct. When engineering your compiler, you can always make choices about which path is statistically more likely, as back-tracking in a well designed language is usually pathological. The theoretical O(..) complexity is largely irrelevant. (Source: I was the main maintainer of rustc's parser and refactored large parts of it.)