5 ms·

> We should have an official runtime, officially managed, and guided by the same thoughts that guide the rest of the language. If it goes into official runtime

by Ygg2 3y ago

> We should have an official runtime, officially managed, and guided by the same thoughts that guide the rest of the language. If it goes into official runtime, then backwards compatibility will kill it eventually. You'll have situation where in year 2078 someone will ask why are we still having tokio when everyone is using telepathy lib? > What we have now is a circus. After 4 years of async being in stable. It's caused by strong backwards compatibility guarantees and long RFC process + unexpected problems. Without strong backwards compatibility, no one would be using Rust. RFC exists to hash out unexpected problems but so far we can't peer in the future. Here is an example: Want to make Range from non-Copy to Copy. I.e. make a new type, rename old to new. That will be one year for RFC and two edition to stabilize circa Rust 2028. By that measure async fixes have been blazingly fast.

thesuperbigfrog 3y ago
>> If it goes into official runtime, then backwards compatibility will kill it eventually. You'll have situation where in year 2078 someone will ask why are we still having tokio when everyone is using telepathy lib? This kind of situation happens and leads to a second, newer official runtime getting adopted and the older, legacy runtime being supported as long as is needed. This happened with Java's official GUT toolkits which started off with the Abstract Windowing Toolkit (AWT) and then moved to Swing and almost moved to JavaFX. Having multiple officially supported core components is not necessarily bad--it can be a sign of good backward compatibility balanced against the need to improve core components. I think it is better than the alternative: multiple unofficial, de facto standard components that are incompatible. Who knows which direction each unofficial components will go and newcomers do not know which one to choose.
- Ygg2 3y ago
  That only happened in Java 9 after Oracle acquired Sun. I'd say Oracle was way more remove focused than Sun ever was.
  - thesuperbigfrog 3y ago
    Yes. Oracle's goal for Java is to monetize it by reducing maintenance by divesting components to the community and focusing on the components that big organizations use (so they will pay for them). JavaFX was one of the many components that was spun out to the community and now lives as OpenJFX (https://openjfx.io/ https://openjfx.io/). JavaFX would have replaced Swing had it not been for Oracle's change of direction.
    - cbm-vic-20 3y ago
      "OpenJFX is a project under the charter of the OpenJDK." Many committers are Oracle employees. https://github.com/openjdk/jfx https://github.com/openjdk/jfx
      - thesuperbigfrog 3y ago
        >> "OpenJFX is a project under the charter of the OpenJDK." Many committers are Oracle employees. Yes, but while Oracle employees may contribute to OpenJFX development, JavaFX is not an officially supported Oracle product (beyond legacy support of old JDK versions): "Do I need a separate support contract for JavaFX? No. JavaFX is part of the technologies covered under Oracle Java SE Subscription. As of JDK 7u6 JavaFX is included with the standard JDK and JRE bundles. Note that for JDK 11 and later JavaFX is no longer included the JDK but remains available as a third party library from other vendors." Source: https://www.oracle.com/java/technologies/faqs-jsp.html https://www.oracle.com/java/technologies/faqs-jsp.html
eviks 3y ago
In year 2078 you'll have a different language, so that's not an issue
wokwokwok 3y ago
Look... What if Arc and Rc weren't in the standard library, and you had to import them via a crate, and multiple different (incompatible) implementations existed such that you couldn't use them at the same time? Would that be ok? How about Option and Result? What if you could only use crates that used the same error library that you wanted to use? What about boxing and custom allocators? Can you imagine if different crates could opt into different allocators and you couldn't safely drop an object without passing it back to the crate it came from because 'who knows' what might happen if you try to deallocate it using your allocator? Should we not ship a default allocator and make that an optional thing too? ... That isn't a language I want to use. I'll take 'it comes with a default allocator' and that's good enough for me. If one day I get a stable 'you can pick, seamlessly at the top level, which allocator to use for your entire program', that's awesome! ...but it does not in any way mean, that I want a rust with no default allocator. The default allocator is great. It works perfectly for most things most people need, and it 'just works', out of the box, the first time you use rust. Async should work out of the box. It doesn't. That sucks.
- Ygg2 3y ago
  > How about Option and Result? This is somewhat of the case with many different Result/Error crates doing their own thing. So being in standard lib isn't a guarantee it won't fracture. > What if Arc and Rc weren't in the standard library, and you had to import them via a crate, and multiple different (incompatible) implementations existed such that you couldn't use them at the same time? First that's not currently what is happening in Rust. Second, I'd probably use the most popular and active one. Same as in JavaScript or Python. I think my criteria for what is in the standard lib is following: How often does the domain change? And should it come out of the box? E.g. are we inventing new ways to parse JSON? Yes ? Out of the standard lib you go. Is ARC/RC being reinvented? No? Go to standard lib.
pwdisswordfishc 3y ago
You mean https://telepathy.freedesktop.org/ https://telepathy.freedesktop.org/ ?
- Ygg2 3y ago
  I meant brain to brain API using tachyons. As in particles not frameworks.
  - thesuperbigfrog 3y ago
    >> I meant brain to brain API using tachyons. As in particles not frameworks. Just make sure you have a firewall. Fortunately there is Linux software for just this need: https://zapatopi.net/mindguard/ https://zapatopi.net/mindguard/ [JOKE]
    - cozzyd 3y ago
      that's what https://lessemf.com/product/brain-coat/ https://lessemf.com/product/brain-coat/ is for
geodel 3y ago
> You'll have situation where in year 2078 someone will ask why are we still having tokio when everyone is using telepathy lib? Agree. This is why I refuse to use solar panels on roof. Science clearly tells sun is gonna burn down all its fuel and implode and at that point my solar roof will be useless deadweight.

by Ygg2 3y ago

thesuperbigfrog 3y ago

>> If it goes into official runtime, then backwards compatibility will kill it eventually. You'll have situation where in year 2078 someone will ask why are we still having tokio when everyone is using telepathy lib? This kind of situation happens and leads to a second, newer official runtime getting adopted and the older, legacy runtime being supported as long as is needed. This happened with Java's official GUT toolkits which started off with the Abstract Windowing Toolkit (AWT) and then moved to Swing and almost moved to JavaFX. Having multiple officially supported core components is not necessarily bad--it can be a sign of good backward compatibility balanced against the need to improve core components. I think it is better than the alternative: multiple unofficial, de facto standard components that are incompatible. Who knows which direction each unofficial components will go and newcomers do not know which one to choose.

Ygg2 3y ago
That only happened in Java 9 after Oracle acquired Sun. I'd say Oracle was way more remove focused than Sun ever was.
- thesuperbigfrog 3y ago
  Yes. Oracle's goal for Java is to monetize it by reducing maintenance by divesting components to the community and focusing on the components that big organizations use (so they will pay for them). JavaFX was one of the many components that was spun out to the community and now lives as OpenJFX (https://openjfx.io/ https://openjfx.io/). JavaFX would have replaced Swing had it not been for Oracle's change of direction.
  - cbm-vic-20 3y ago
    "OpenJFX is a project under the charter of the OpenJDK." Many committers are Oracle employees. https://github.com/openjdk/jfx https://github.com/openjdk/jfx
    - thesuperbigfrog 3y ago
      >> "OpenJFX is a project under the charter of the OpenJDK." Many committers are Oracle employees. Yes, but while Oracle employees may contribute to OpenJFX development, JavaFX is not an officially supported Oracle product (beyond legacy support of old JDK versions): "Do I need a separate support contract for JavaFX? No. JavaFX is part of the technologies covered under Oracle Java SE Subscription. As of JDK 7u6 JavaFX is included with the standard JDK and JRE bundles. Note that for JDK 11 and later JavaFX is no longer included the JDK but remains available as a third party library from other vendors." Source: https://www.oracle.com/java/technologies/faqs-jsp.html https://www.oracle.com/java/technologies/faqs-jsp.html

eviks 3y ago

In year 2078 you'll have a different language, so that's not an issue

wokwokwok 3y ago

Look... What if Arc and Rc weren't in the standard library, and you had to import them via a crate, and multiple different (incompatible) implementations existed such that you couldn't use them at the same time? Would that be ok? How about Option and Result? What if you could only use crates that used the same error library that you wanted to use? What about boxing and custom allocators? Can you imagine if different crates could opt into different allocators and you couldn't safely drop an object without passing it back to the crate it came from because 'who knows' what might happen if you try to deallocate it using your allocator? Should we not ship a default allocator and make that an optional thing too? ... That isn't a language I want to use. I'll take 'it comes with a default allocator' and that's good enough for me. If one day I get a stable 'you can pick, seamlessly at the top level, which allocator to use for your entire program', that's awesome! ...but it does not in any way mean, that I want a rust with no default allocator. The default allocator is great. It works perfectly for most things most people need, and it 'just works', out of the box, the first time you use rust. Async should work out of the box. It doesn't. That sucks.

Ygg2 3y ago
> How about Option and Result? This is somewhat of the case with many different Result/Error crates doing their own thing. So being in standard lib isn't a guarantee it won't fracture. > What if Arc and Rc weren't in the standard library, and you had to import them via a crate, and multiple different (incompatible) implementations existed such that you couldn't use them at the same time? First that's not currently what is happening in Rust. Second, I'd probably use the most popular and active one. Same as in JavaScript or Python. I think my criteria for what is in the standard lib is following: How often does the domain change? And should it come out of the box? E.g. are we inventing new ways to parse JSON? Yes ? Out of the standard lib you go. Is ARC/RC being reinvented? No? Go to standard lib.

pwdisswordfishc 3y ago

You mean https://telepathy.freedesktop.org/ https://telepathy.freedesktop.org/ ?

Ygg2 3y ago
I meant brain to brain API using tachyons. As in particles not frameworks.
- thesuperbigfrog 3y ago
  >> I meant brain to brain API using tachyons. As in particles not frameworks. Just make sure you have a firewall. Fortunately there is Linux software for just this need: https://zapatopi.net/mindguard/ https://zapatopi.net/mindguard/ [JOKE]
  - cozzyd 3y ago
    that's what https://lessemf.com/product/brain-coat/ https://lessemf.com/product/brain-coat/ is for

geodel 3y ago

> You'll have situation where in year 2078 someone will ask why are we still having tokio when everyone is using telepathy lib? Agree. This is why I refuse to use solar panels on roof. Science clearly tells sun is gonna burn down all its fuel and implode and at that point my solar roof will be useless deadweight.