3 ms·

> Rust has rayon `input.par_iter()` rayon is a 3rd party library though, not part of the language itself, compared to the Java streams discussed here. With C#

> Rust has rayon `input.par_iter()` rayon is a 3rd party library though, not part of the language itself, compared to the Java streams discussed here. With C# I'm not sure if .NET can be called a library or not? All C# tooling ships with .NET by default or not?

EnergyAmy 3y ago
That's just the way Rust does things, like with the `rand` crate. Lean stdlib, easy dependency management. For the purposes of "does Rust do X", popular crates should be included in that consideration.
- capableweb 3y ago
  Ok, so then what is this discussion about? Java Streams have existed basically forever, as a 3rd party library, but that doesn't matter here in our conversation about Java language features, where 3rd party libraries somehow changes what the language is...
  - EnergyAmy 3y ago
    I guess it's nice for Java that they did this, but the OP's assertion that no other language handles this as nicely doesn't really stand. For example, this quote: > In other mature languages, streams are very rigid and feel non-composable I'd like to see some motivating examples that make me say to myself, "Yeah, Java's got a neat trick there".
- dackerlunghack 3y ago
  [dead]
neonsunset 3y ago
Whether it ships with it or not is, however, irrelevant. As long as the library is sufficiently popular and accepted by community, it can be seen as the advantage of a particular platform/language. In this regard, while it is nice that PLINQ and various `Parallel`-related APIs come out of box in C#, it is a marginal difference with Rust where building parallel loops is `cargo add rayon` away.
- samus 3y ago
  If it doesn't ship with the default distribution of the language, then there's the risk that multiple mutually incompatible libraries emerge or that the adoption by the ecosystem is spotty. Best example: the async runtime mess in the Rust ecosystem.
  - neonsunset 3y ago
    There is no async runtime mess. Tokio is the preferred one, and given Rust's goals it is difficult to do it better (pluggable async executors and the degree of flexibility such abstraction offers - running both on big servers and bare cooperative multi-tasking on microcontrollers). In addition, multiple versions of transitive dependencies can coexist in Rust without conflicting with each other, there is no such risk.
    - pjmlp 3y ago
      It is definitely a mess, given incompatible semantics making it an herculean effort to write runtime agnostic async libraries.
    - samus 3y ago
      Quite so. But I am under the impression that not every library supports Tokio as a runtime. And while it might be possible to run multiple runtimes in the same process, or use compatibility wrappers, it sounds like trouble.
- capableweb 3y ago
  > Whether it ships with it or not is, however, irrelevant When talking about projects in the wild, sure. But if we're specifically talking about language features, then "something being a part of the language" is wildly different than "installable 3rd party library".
  - neonsunset 3y ago
    This mentality is the exact cause behind both .NET and JVM worlds being worse at enjoying the OSS-first benefits of their ecosystems than Rust or, God forbid, Go where it is expected to import a widely known good packages for solving a particular task. Sometimes, it is a scar tissue from dealing with NIH syndrome too - at least you can use the OOB tools for combating with it, but the NIH itself it the actual source of people being resistant to adopting proven and good solutions developed by community.
pjmlp 3y ago
It certainly can, if you want to be technical, it is the Base Class Librarily, short BCL. .NET is the only language ecosystem that is comparable to Java, as they are a kind of yin/yang between themselves.

EnergyAmy 3y ago

That's just the way Rust does things, like with the `rand` crate. Lean stdlib, easy dependency management. For the purposes of "does Rust do X", popular crates should be included in that consideration.

capableweb 3y ago
Ok, so then what is this discussion about? Java Streams have existed basically forever, as a 3rd party library, but that doesn't matter here in our conversation about Java language features, where 3rd party libraries somehow changes what the language is...
- EnergyAmy 3y ago
  I guess it's nice for Java that they did this, but the OP's assertion that no other language handles this as nicely doesn't really stand. For example, this quote: > In other mature languages, streams are very rigid and feel non-composable I'd like to see some motivating examples that make me say to myself, "Yeah, Java's got a neat trick there".
dackerlunghack 3y ago
[dead]

neonsunset 3y ago

Whether it ships with it or not is, however, irrelevant. As long as the library is sufficiently popular and accepted by community, it can be seen as the advantage of a particular platform/language. In this regard, while it is nice that PLINQ and various `Parallel`-related APIs come out of box in C#, it is a marginal difference with Rust where building parallel loops is `cargo add rayon` away.

samus 3y ago
If it doesn't ship with the default distribution of the language, then there's the risk that multiple mutually incompatible libraries emerge or that the adoption by the ecosystem is spotty. Best example: the async runtime mess in the Rust ecosystem.
- neonsunset 3y ago
  There is no async runtime mess. Tokio is the preferred one, and given Rust's goals it is difficult to do it better (pluggable async executors and the degree of flexibility such abstraction offers - running both on big servers and bare cooperative multi-tasking on microcontrollers). In addition, multiple versions of transitive dependencies can coexist in Rust without conflicting with each other, there is no such risk.
  - pjmlp 3y ago
    It is definitely a mess, given incompatible semantics making it an herculean effort to write runtime agnostic async libraries.
  - samus 3y ago
    Quite so. But I am under the impression that not every library supports Tokio as a runtime. And while it might be possible to run multiple runtimes in the same process, or use compatibility wrappers, it sounds like trouble.
capableweb 3y ago
> Whether it ships with it or not is, however, irrelevant When talking about projects in the wild, sure. But if we're specifically talking about language features, then "something being a part of the language" is wildly different than "installable 3rd party library".
- neonsunset 3y ago
  This mentality is the exact cause behind both .NET and JVM worlds being worse at enjoying the OSS-first benefits of their ecosystems than Rust or, God forbid, Go where it is expected to import a widely known good packages for solving a particular task. Sometimes, it is a scar tissue from dealing with NIH syndrome too - at least you can use the OOB tools for combating with it, but the NIH itself it the actual source of people being resistant to adopting proven and good solutions developed by community.

pjmlp 3y ago

It certainly can, if you want to be technical, it is the Base Class Librarily, short BCL. .NET is the only language ecosystem that is comparable to Java, as they are a kind of yin/yang between themselves.