3 ms·

I think one could argue exactly the same thing for the same reasons about C# vs F# on .NET, which is my area of expertise - but honestly I'm not so sure it's tr

I think one could argue exactly the same thing for the same reasons about C# vs F# on .NET, which is my area of expertise - but honestly I'm not so sure it's true. C# has grown into an enormous language as it tries (consciously or not) to subsume F#, and F# is always going to remain so much cleaner just because you aren't having to ignore 90% of the language features when you code in it.

throw868788 5y ago
Agree with this. What's more interesting is on the feature level languages do borrow/converge on each other in order to try to secure a position in the market. I note that as an example Java is consdering a .NET like Span feature (https://openjdk.java.net/jeps/412 https://openjdk.java.net/jeps/412) as an example probably to close the gap w.r.t performance. There are others. What matters more in all honesty, and what's hard to change IMO is: - The base of the language (is it verbose, how the base features interact with each other) vs being "tacked on". A language with these features initially. e.g. you mention F# and I know it uses HM type inference, immutability by null, makes null hard to express by default, etc. - Anything that breaks backwards compatibility (e.g. Java's generic implementation) for example including existing API's. Adding Async afterwards takes time, and changing the underlying model of the language (e.g. Python's GIL, OcAML multithreading) takes time and needs a lot more consideration. Its code, anything can change, its just harder and maybe easier to take something that was designed for that case initially. Being a polygot isn't a bad thing per se I think if it can be justified tech wise.