Having distinct Darwin or Glibc imports seems a little crazy for these examples. When you code in c, libc is just there. It has minor variations from platform to platform, but you always think of it as libc. (Even if Darwin calls it libsystem etc. Or if Microsoft's is mscvrt and it kind of sucks.) It would be more reasonable to call it libc. (If I run on BSD do I still call it "glibc" with no actual GNU present? And if the arc4random APIs present in libc there look a lot like Darwin's because they actually share code? Maybe they have not considered porting to non-linux?)

Basically they set a portability boundary in the wrong place.

But for context, the previous sentence on that page is: “You can also import any available system modules, such as Darwin on macOS and Glibc on Linux”

The random number examples aren’t saying that’s the right way to generate random numbers in a platform-independent way, it is specifically demonstrating how to import system libraries on your local platform.

Swift 4.2 (2018) introduced a cross platform random number API.

    (0..<10).randomElement()

Yet they didn't bother to update the example on the introduction to Swift.

There are plenty of other examples I can look for, like file handling.

File handling can be done using Foundation, which I believe has API parity between Darwin and Linux at least.

I think the point of the example was to demonstrate importing platform-specific modules, not random number generation per se. But you're right, it should probably be updated to do something else.

>Yet they didn't bother to update the example on the introduction to Swift.

There are widely popular FOSS languages with much much less documentation...

Such as?

Golang has terser and worse documentation than Swift, for one...

Dude you’re literally illustrating Swifts strength here. The whole point is to have a safe easy to use language that reuses existing system libraries.

Any mainstream programming language can do that.

Not many use an actual c/c++ compiler (clang) to generate language native calling convention wrappers for calling into C/ObjC code (not sure how well c++ interop works these days).

Few as elegant, as safe, or as performant combined...

Delphi, D, .NET, Eiffel, Ada, Rust, Nim.

And lets not put Swift and performance on the same sentence, they still need to catch up a bit.

https://github.com/ixy-languages/ixy-languages

What is this, a cabinet of curiosities?

Aside from .NET and Rust, all the others are not players in 2020.

Ah, that might be the reason why NVidia is adopting Ada for their firmware, ebay and Netflix decided to use D for some of their projects, the Turkish government decided to invest into Delphi for their education system,...

By the way, it is a list of languages with compilers that currently outperform Swift.

>Ah, that might be the reason why NVidia is adopting Ada for their firmware, ebay

A, the "some part of some huge player with 2000 divisions uses some otherwise niche language, surely said language is making a comeback" argument.

You can find all kinds of niche/sidestepped languages if you look hard enough on any organization that has 200 products, 1000 inside projects, and tons of engineers. Doesn't mean said languages are making a comeback anytime soon.

For languages that actually thrive nobody needs to enumerate major and minor projects where they're used, because they're too many to mention. But when the main news for "Planet language X" is "big corp decided to use X for something among the 100s things they do", well, they need all the straws they can grasp.

Same way Latin remains a dead language whether some Oxford professor recently published a book of new poems he wrote in it or not...