3 ms·

You mean like how Rust had async from the beginning? Oh wait. I guess we'll have to wait till 2040 for these languages to be complete before we can have a relea

You mean like how Rust had async from the beginning? Oh wait. I guess we'll have to wait till 2040 for these languages to be complete before we can have a release then. The massive success Go has been suggest that their decision to start simple, without generics, was objectively a good one, even if unpopular to.somr. Heck, not even sure if it'll really be Go anymore when it ships...

pjmlp 5y ago
Good idea to bring Rust into the table, async is also not fully backed and there are several use cases that will only be taken care in years to come, if at all. With incompatible runtimes. So another good example of what happens when things aren't baked on 1.0 release. If Go did not had UNIX/Plan 9 key persons and Google money attached to it, or killer projects like Docker and Kubernetes, it would have fizzled away. As it is, even those that would rather not use it, must do so, specially when we use DevOps hats from time to time.
- tialaramex 5y ago
  But it seems like this type of "replacing stdlib features" discussion mostly evaporates for Rust. In Rust an edition changes the prelude and new code that looks the same now gets the desirable new behaviour, even though backwards compatibility is undiminished for old code. It feels like several of the Golang proposals are in the same spirit (I noticed one explicitly invoking Rust) but as hacks rather than a built-in language feature.
  - pjmlp 5y ago
    It only evaporates, because most people aren't language geeks that waste part of their life reading SIGPLAN and IEEE papers. :) Currently in Rust async/await generators discussion has been put on hold as being a hot topic, and as library writer one can't still be sure the library will properly work across all async runtimes. https://rust-lang.github.io/async-book/01_getting_started/03_state_of_async_rust.html https://rust-lang.github.io/async-book/01_getting_started/03... Same kind of 1.0 issues apply to Java, D, C#, C++,.... and they are specially bad in guest languages that take decisions on syntactic sugar for missing platform features, and when the platform adds those features, they usually end up with two ways of doing the same thing.
    - tialaramex 5y ago
      This seems once again to have returned to talking about async, for whatever reason, rather than the topic "How to Update APIs for Generics". > as library writer one can't still be sure the library will properly work across all async runtimes. If you have assumptions that the runtime can't deliver, your library won't be useful with that runtime. True. Most obviously if you require async to mean "It just magically happens on another thread", and that's not what this runtime offers, too bad, that's not what you get. It is conceivable that Rust will settle on Async always meaning Threads, and then this problem goes away, but I suspect it's far more likely (since Rust is adopted in embedded systems where nobody has any intention of "just" dropping in a complete threading system) that this persists, if you needed Threads then you'd better make sure you've actually got Threads, because duh, if there's only a single thread of execution then whenever you're not waiting for the async task to happen it isn't being worked on. Latency has a similar issue, if you need latency guarantees you need a runtime with actual latency guarantees, Rust's async does not do that work for you. But again, if down the road this is magically resolved (which I doubt) Rust can just ship a new edition with the new behaviour, which is the point you entirely ignored. The problem is how to move forward, and I believe Editions are a significant improvement over the status quo for most languages in that regard. You can't expect to get everything correct in 1.0, and so you should already be planning for how to improve.
- arghwhat 5y ago
  Those key persons are exactly the ones that decided Go should not have generics. Heck, they're pretty much just succumbing to peer pressure.

pjmlp 5y ago

Good idea to bring Rust into the table, async is also not fully backed and there are several use cases that will only be taken care in years to come, if at all. With incompatible runtimes. So another good example of what happens when things aren't baked on 1.0 release. If Go did not had UNIX/Plan 9 key persons and Google money attached to it, or killer projects like Docker and Kubernetes, it would have fizzled away. As it is, even those that would rather not use it, must do so, specially when we use DevOps hats from time to time.

tialaramex 5y ago
But it seems like this type of "replacing stdlib features" discussion mostly evaporates for Rust. In Rust an edition changes the prelude and new code that looks the same now gets the desirable new behaviour, even though backwards compatibility is undiminished for old code. It feels like several of the Golang proposals are in the same spirit (I noticed one explicitly invoking Rust) but as hacks rather than a built-in language feature.
- pjmlp 5y ago
  It only evaporates, because most people aren't language geeks that waste part of their life reading SIGPLAN and IEEE papers. :) Currently in Rust async/await generators discussion has been put on hold as being a hot topic, and as library writer one can't still be sure the library will properly work across all async runtimes. https://rust-lang.github.io/async-book/01_getting_started/03_state_of_async_rust.html https://rust-lang.github.io/async-book/01_getting_started/03... Same kind of 1.0 issues apply to Java, D, C#, C++,.... and they are specially bad in guest languages that take decisions on syntactic sugar for missing platform features, and when the platform adds those features, they usually end up with two ways of doing the same thing.
  - tialaramex 5y ago
    This seems once again to have returned to talking about async, for whatever reason, rather than the topic "How to Update APIs for Generics". > as library writer one can't still be sure the library will properly work across all async runtimes. If you have assumptions that the runtime can't deliver, your library won't be useful with that runtime. True. Most obviously if you require async to mean "It just magically happens on another thread", and that's not what this runtime offers, too bad, that's not what you get. It is conceivable that Rust will settle on Async always meaning Threads, and then this problem goes away, but I suspect it's far more likely (since Rust is adopted in embedded systems where nobody has any intention of "just" dropping in a complete threading system) that this persists, if you needed Threads then you'd better make sure you've actually got Threads, because duh, if there's only a single thread of execution then whenever you're not waiting for the async task to happen it isn't being worked on. Latency has a similar issue, if you need latency guarantees you need a runtime with actual latency guarantees, Rust's async does not do that work for you. But again, if down the road this is magically resolved (which I doubt) Rust can just ship a new edition with the new behaviour, which is the point you entirely ignored. The problem is how to move forward, and I believe Editions are a significant improvement over the status quo for most languages in that regard. You can't expect to get everything correct in 1.0, and so you should already be planning for how to improve.
arghwhat 5y ago
Those key persons are exactly the ones that decided Go should not have generics. Heck, they're pretty much just succumbing to peer pressure.