[HN Gopher] Swift System Is Now Open Source
___________________________________________________________________
Swift System Is Now Open Source
Author : NobodyNada
Score : 283 points
Date : 2020-09-25 19:00 UTC (3 hours ago)
(HTM) web link (swift.org)
(TXT) w3m dump (swift.org)
| usmannk wrote:
| To me Swift is one of the most interesting languages right now.
| It's killer for iOS development of course, but Swift for
| Tensorflow[0] is exciting and could become a refreshing
| alternative to python for machine learning. Here Swift System +
| Swift for Linux could make it a compelling alternative to Go or
| Rust in the future. Looking at Swift System, one interesting
| thing to note is that they are wrapping the library functions
| rather than calling into the kernel directly. The source for that
| is here: https://github.com/apple/swift-
| system/blob/main/Sources/Syst...
|
| [0] Yes, I'm aware of the staffing issues. No need to beat that
| dead horse again.
| marta_morena_29 wrote:
| Why would you mention Swift, Go and Rust in the same context? I
| mean Swift vs. Go kinda has some merit, although they have
| completely different intentions. At least Go doesn't aspire to
| be a systems programming language. Rust definitely has no place
| in this comparison. Rust serves a niche market of systems
| programming that is so security focused that C/C++ just won't
| do. It's not useful for anything else (at least not anymore
| than Haskell is useful for anything besides university
| projects, in the real world at least).
|
| Swift has many nice similarities with Rust and other current
| languages from a pure syntactical/language perspective, while
| aiming to be a GP language. It definitely serves a broader
| audience than Go, whose main target is server programming.
| Swift's main target is Apple UI programming, however, the
| language is capable of so much more.
|
| Which is why Open Source is good news. It may make it escape
| its Apple box.
| xondono wrote:
| I strongly disagree with your view of Rust.
|
| While it's true that Rust shows promise in security and
| embedded, some of the early adopters have been in the server
| side and microservices.
| ansible wrote:
| I'm exploring Rust in embedded (for fun-time projects), and
| there is a lot of activity across the programming spectrum.
| I think Rust has a good story for anyone doing multi-
| threaded programming and values correctness.
| oaiey wrote:
| Harsh words. I agree with the statement, but Rust is used not
| only for system programming and Haskell has its niche beyond
| university.
|
| I think Swift is where .NET was in its first decade. While
| capable of so much more, it is limited by its designers and
| primary purpose so it cannot go beyond. The tight coupling to
| UI products is a burden an ecosystem carries. Java won in the
| backend not with is UI, JavaScript with node/npm before
| Angular reset the frontend and C# just when .NET Core pushed
| it into spaces it has not been before (apis, lambdas, etc).
| jtsiskin wrote:
| What do you mean by "so security focused that C/C++ just
| won't do"?
|
| Anything on the internet should be cautious of memory
| unsafety issues. Something like an image processing library I
| won't consider 'security focused' yet I would trust one
| written in Rust over one written in C.
| nemothekid wrote:
| > _Rust serves a niche market of systems programming that is
| so security focused that C /C++ just won't do. It's not
| useful for anything else (at least not anymore than Haskell
| is useful for anything besides university projects, in the
| real world at least)._
|
| You could call Java is niche for the same reason. Some of us
| want to write native, low overhead code in a language that
| has a sane design (only disparaging C++ here). It's about
| time C++ had more alternatives.
| rkrzr wrote:
| Why the cheap swipe at Haskell? We use Haskell very
| productively in the real world. You can take a look at some
| of our blog posts here, if you want to learn more:
| https://tech.channable.com/
|
| Here is one post about writing an Aho-Corasick implementation
| in Haskell which is as fast as the fastest Rust
| implementation:
| https://tech.channable.com/posts/2019-03-13-how-we-made-
| hask...
| wwright wrote:
| I don't think Swift really competes with Rust or Go at all.
|
| - Go aims to be simple enough for many engineers to be
| productive with little investment.
|
| - Rust aims to be extremely reliable and efficient.
|
| Swift is _very_ complex, and makes many compromises away from
| reliability or efficiency in favor of application use cases.
|
| Swift may fill an interesting role for a "native C#" that is
| mostly reliable, mostly efficient, and somewhat productive, but
| on the other hand, C#, OCaml, Java, Kotlin, and so on already
| have various answers to that, and they're only becoming better
| at it.
|
| The only real advantage it has (as far as I can tell) is iOS
| (and TensorFlow almost as a knock-on of being the only serious
| language for iOS).
| wffurr wrote:
| Swift has almost seamless interoperability with existing C
| and C++ libraries and has much stronger safety guarantees
| than either of those languages. It's not on the same level as
| Rust, but ARC eliminates entire classes of memory safety
| issues.
|
| The Swift runtime is large-ish, but not outrageously so, and
| is generally statically compiled-in to the binaries, so
| there's no dependencies on dynamic libraries.
|
| It is, as you say, quite complex, but still an interesting
| choice IMO.
| dagmx wrote:
| Minor nitpick but it does not have seamless interfacing
| with anything other than Objective C.
|
| C can be exposed as Objective C, but C++ has to go through
| C (potential objective C++) first.
|
| This is really no different than most other languages.
|
| What it does do is provide good auto binding tools however
| to expose classes and objects bidirectionally to objective
| C.
| andrekandre wrote:
| obj-c is a direct superset of c, so that interop already
| requires plain c capabilities right out of the box
|
| and afair obj-c interrop is only available/supported on
| apple platforms
| ladon86 wrote:
| My understanding was that there is no need to involve
| Objective-C if you're directly interfacing with C. That
| interop is direct/seamless, and works on Linux etc. even
| without Objective-C or Darwin [0].
|
| But the C++ story is what you've described above.
|
| [0] https://developer.apple.com/documentation/swift/impor
| ted_c_a...
|
| and
|
| https://developer.apple.com/documentation/swift/imported_
| c_a...
| [deleted]
| mhh__ wrote:
| Swift can interface with C++? I've just done some googling
| but I cannot find any documentation at all relating to C++
| interop. I make no assumption that I'm right but all I can
| see is interop via a C API
|
| Seamless in my mind is what D has where name mangling,
| templates, and classes all work on Windows, Linux (possibly
| MacOS - I don't have one). Does swift have any of that?
| rvz wrote:
| > Swift can interface with C++? I've just done some
| googling but I cannot find any documentation at all
| relating to C++ interop.
|
| It is not there yet but it _is_ actually being
| implemented on a native level. A quick Google gave me
| this. [0] [1] [2]
|
| The approach is first-party than what you get with Rust's
| third-party crates and tools like bindgen, cxx, etc.
| Swift's C-interop approach is built-in and much more
| seamless and automated than bindgen's toggles and
| switches and creating them by hand in with cgo in Golang.
|
| [0] https://github.com/apple/swift/blob/master/docs/CppIn
| teroper...
|
| [1] https://github.com/apple/swift/pulls?q=label%3A%22C%2
| B%2B+In...
|
| [2] https://forums.swift.org/t/manifesto-
| interoperability-betwee...
| saagarjha wrote:
| It's being worked on, but it's nowhere near being usable
| in any sense. Very fundamental things still need to be
| tied down and decided, much less implemented.
| jhatemyjob wrote:
| On most platforms, if you can interface with C, you can
| also interface with C++. Usually you have to find the
| mangled symbol in the C++ binary using a tool like nm,
| and treat it like a C function with whatever ffi you're
| using.
|
| If you are targeting multiple platforms this can get
| tricky because the mangled C++ symbol will (probably) be
| different for each platform, which can be solved with a
| good build system
| mhh__ wrote:
| Eek. I've done it but not exactly seamless as implied
| above! (feels Like using a landmine as a baking scale)
| jhatemyjob wrote:
| What issues did you run into?
| mhh__ wrote:
| I've only ever done it out of curious laziness but it's
| one of those things where it's theoretically clean enough
| to do right but if you do it wrong you might be fixing it
| all day. If something changes downstream or you make a
| mistake at 9AM you can end up with subtle non-failing
| garbage everywhere.
|
| The only way I would do it and trust it, would be if the
| binding is generated and tested (separately)
| automatically, but at that stage why not just write one
| with a proper ABI.
| jarjoura wrote:
| C++ doesn't have a stable ABI, so if you target a C++
| symbol manually like this, as soon as the compiler revs,
| to say, C++20, the ABI will change and you'll get a
| linker error.
|
| Also, this may work for simple C++ methods, but once you
| cross over into vtable territory, you're going to be in a
| world of hurt.
|
| Also as far as interoperability, I just don't see a
| smooth path forward between Swift and C++.
| Philosophically, much of the C++ code you write ends up
| compiling away or building specialized generated code at
| compile time. Anything written in C++17 and newer will
| also have a lot of constexpr code that generates
| immutable results baked into the final output.
|
| I'd say, wrap your C++ in a simple C API and expose that
| to Swift (same would apply to Go/Rust or any other
| language honestly).
| moonchild wrote:
| Good luck instantiating and using classes if you do it
| that way. You pretty much have to reimplement the itanium
| abi in whatever language you're using (hint: if your
| language doesn't already support it, then even
| implementing it in assembly would be easier).
| plorkyeran wrote:
| Swift has great C interop for a language that is not a C
| superset, but C++ interop is at best a thing you can
| theoretically do. In practice c++ interop is usually done
| via a wrapper.
| usmannk wrote:
| > Rust aims to be extremely reliable and efficient.
|
| Fair point, Swift will never be as predictable or efficient
| as Rust (not a negative perse, just different goals). But I
| disagree on the complexity re: Go. What about Swift gives you
| the impression of extreme complexity? Go is definitely
| comparatively simpler but I do not think it is so much so as
| to put it in a different league.
| novok wrote:
| The type errors you start running into with generics with
| all of their weird limitations in swift can make things
| complicated fast. That and RxSwift.
|
| Also swift as a language doesn't scale well. There are a
| lot of bottlenecks in the build process that doesn't let
| you scale simply amongst many cores like you can with C++,
| Obj-C & C and probably many other languages too. You're
| also effectively limited to xcode & apple desktops, so you
| can't go rent out a 100 core build server on AWS for builds
| like you can for every other platform out there, not that
| is matters much yet with swift's build scaling issues.
|
| Also stuff like basic debugging often just... dies.
|
| The more I work with a badly scaling language the more I
| appreciate a design decision like go made with building
| fast. I hope with generics in go v2 the boilerplate should
| reduce a lot.
| jshier wrote:
| When was the last time you compiled Swift code? Xcode's
| new(er) build system has solved many of the scaling
| issues that affected the previous system, to the point
| where it scales linearly (on large enough projects) even
| on a 28/56 Mac Pro, and my 10/20 iMac. Additionally, with
| cmake's native Swift support in 3.18(?), the scaling
| should be more solved across platform as well. There's
| certainly nothing in the language itself that prevents
| scaling builds, only the compiler and build systems.
|
| The debugger is still rough, true, but improving. Apple
| just isn't spending the resources needed to bring lldb up
| to a great experience in a timely fashion.
| kitsunesoba wrote:
| I think one of Swift's advantages is its progressive
| disclosure. It can be written without using any of its more
| advanced features, making it approachable without limiting
| possibilities for more advanced users.
| rpastuszak wrote:
| All of this sounds great but it doesn't mean that the code
| written in it will maintain the same level of
| simplicity/approachability. Go has the advantage of
| enforcing it. Writing code is easier than reading it.
|
| Don't get me wrong, I love swift but I think that for what
| you're talking about constraints are necessary because we
| naturally shift towards more complex ways of expression.
| anoncareer0212 wrote:
| Exactly, I was in love @ Swift 2, but as the language
| evolved to cover corner cases and enable things like
| SwiftUI, it became nigh-unreadable, there's simply too
| many 'dialects'.
|
| Dart is the closest I've found to optimizing the surface
| area of a language while maintaining flexibility like
| ObjC.
| a1369209993 wrote:
| > It can be written without using any of its more advanced
| features
|
| If anything, that's bad, because it invites projects to
| adopt a impoverished subset of the language that avoids
| those features, in which case they might as well not exist
| because you aren't allowed to use them.
| rat9988 wrote:
| I'm not sure where is the problem here for the team that
| doesn't use it.
| saagarjha wrote:
| I have yet to encounter a project that does not allow
| contributions that use advanced features.
| cylon13 wrote:
| Can it be read without knowing about its more advanced
| features though? Production software is read much more
| often than it is written.
| nicoburns wrote:
| I've been able to dip into Swift codebases with zero
| previous experience without too much trouble. I do have
| Rust experience which helps. But never-the-less everyday
| Swift seemed pretty readable to me.
| saagarjha wrote:
| One of Swift's strengths is that most of its features
| really make sense if you read them, even if you aren't
| aware they existed. The entire language is optimized
| around readability. (No, I'm not counting the function
| builder fiasco.) For example, you may not know that
| Swift's loops support where clauses: for
| i in 1..<10 where i % 2 == 0 { print(i) }
|
| But you can immediately understand how it works, because
| it's consistent with the rest of the language and reads
| well.
| usmannk wrote:
| I agree. I referenced this (perhaps a bit too implicitly)
| in a sibling comment. Swift's complexity is there but only
| when you need it.
| youareostriches wrote:
| > _It can be written without using any of its more advanced
| features..._
|
| So can Perl.
| mhh__ wrote:
| Isn't that true of almost all programming languages? Or do
| you mean cleanly?
|
| I think D has to be this idea (or disease depending on who
| you ask i.e. Go is based on the idea of only keeping the
| simple bits) taken to the extreme - you can quite happily
| write Java in D but also implement _a_ Java in D all the
| way down to the metal (merrily metaprogramming all the way
| down)
| webmobdev wrote:
| Where do you think Ada - a mature and tested language - fit
| in between these 3 newbies?
| wwright wrote:
| I don't know Ada well personally, but from what I've read,
| it's a bit less advanced than Rust at static checks, a good
| bit simpler than Rust and Swift but more complex than Go,
| and a little bit old-fashioned in approach (verbose syntax
| and all that). But I'm not very educated.
|
| I _would_ say that Ada and Rust probably compete on some
| things, but given the history of Ada in industry, it 's
| probably only in fields that already use Ada (aerospace and
| what-not).
| StreamBright wrote:
| What is the unique value set that it brings to the table?
| amelius wrote:
| > but Swift for Tensorflow[0] is exciting and could become a
| refreshing alternative to python for machine learning
|
| I prefer the landscape for ML not to be fragmented based on
| non-essential qualities like the language that is used.
|
| How great is it that researchers publish code in the same
| language, and everybody can use that code immediately without
| having to learn language X and/or porting the implementation?
| dmitriid wrote:
| I will gather a lot of downvotes, but still: I find Swift a
| very haphazardly designed language with very little foresight
| and forethought. This is further compounded by its standard
| libraries which are directly lifted from MacOS with all of
| their idiosyncrasies and huge incompatible changes from version
| to version.
|
| For what it's worth, [1] [2] [3] [4]
|
| [1] A type system that can't cope with SwiftUI:
| https://tonsky.me/blog/swiftui/
|
| [2] More syntax to shake a stick at
| https://twitter.com/dmitriid/status/1276482336486576133
|
| [3] Even more syntax weirdness
| https://twitter.com/bradfitz/status/1285302091544576000
|
| [4] Standard library between versions:
| https://twitter.com/dmitriid/status/1201441652507844608 File
| manipulation functions on String, great design.
| valuearb wrote:
| So you ding the language because of a suboptimal choice made
| by one tool for it?
|
| The good and bad of Swift is the regular breaking updates.
| Sure it's a pain when things change, but it's also healthy
| when they improve, and almost every change has been an
| improvement.
|
| A language as simple as C can slowly grow without breaking
| existing source code. But it's also never been able to
| address its most significant flaws.
| dmitriid wrote:
| > So you ding the language because of a suboptimal choice
| made by one tool for it?
|
| I provided 4 different links showing multiple different
| features in the language I find suboptimal.
|
| > Sure it's a pain when things change, but it's also
| healthy when they improve, and almost every change has been
| an improvement.
|
| It's a very dubious statement at the very least.
|
| > But it's also never been able to address its most
| significant flaws.
|
| Can Swift address its flaws even with its breaking changes?
| So far its been piling on more and more syntax, and
| continuously breaking its standard library (whose design
| choices like writing to files from Strings are very
| dubious)?
| [deleted]
| untog wrote:
| IMO (as someone who has written plenty of Swift and Rust) Rust
| is in category of its own here. It's a fantastic language and I
| love working with it... but it has a mental overhead in dealing
| with ownership, borrow checking etc that other languages don't.
|
| It's amazing in situations where performance is critical, or
| where you have constrained resources. But I'd much rather use
| Swift in other situations.
| adamnemecek wrote:
| I used to be a bit of a Swift fan boy, but then I switched to
| Rust (I was a Rust fanboy for even longer but thought that
| Swift was better for my use case which is a native macos app).
| I have not looked back. The Swift ecosystem is mostly people
| wrapping Apple APIs.
|
| God help you if you want to have a swift package with some
| metal code in it. Rust cargo manages this without a hiccup.
|
| Swift is nice as long as daddy Apple had your use case in mind,
| God forbid you have to tweak something. Rust feels more
| "timeless".
|
| Swift for TF is dead.
| rhodysurf wrote:
| For a while I was looking aggressively at using swift
| everywhere, but then I tried rust and read this
| https://v4.chriskrycho.com/rust-and-swift.html and gained a
| new respect for Rust and have been using it whenever I can
| since.
| valuearb wrote:
| Boy that is really old. And oppressively detailed. And ends
| up sounding like a Coke vs Pepsi argument. Do I really care
| about the minutia of minor features when I can build the
| same things with both tools?
|
| For server side I'm probably going to use Rust, for MacOS
| or iOS I'm certainly using Swift, for Android I choose
| Kotlin, and for Windows I would choose suicide.
| rhodysurf wrote:
| It definitely is old, but a lot of the points still stand
| with respect to swift syntax.
|
| Anyway I was trying to use swift for things outside of
| iOS work to share code and it wasnt worth it, is what I'm
| really getting at. So agreed on your whole second
| sentence haha
| adamnemecek wrote:
| I'm using rust and metal on macos and it's pretty nice.
| I'll switch to wgpu eventually, it's similar enough to
| metal.
| rektide wrote:
| > In June, Apple introduced Swift System, a new library for Apple
| platforms that provides idiomatic interfaces to system calls and
| low-level currency types.
|
| "One of these things is not like the other, one of these things
| does not belong"
|
| I mean, it kind of fits, it works, but I did do a quintuple take
| trying process & make sure I was reading this first line
| correctly. Posting just to share. Read a little more to confirm,
| yeah, system calls & currency. Check & check.
|
| One other idle thought, it would be interesting for something
| like the web platform to try to expose it's api's in a polyglot
| fashion. For some reason, this exposure, of Swift trying to open
| up more of it's platform to other platforms (that makes sense in
| context i swear) makes me think, how can the web platform keep
| expanding to offer more?
|
| We're seeing really interesting neat early indicators with
| projects like Rust's web-sys, to wrap & expose the web platform
| in rust-webassembly. But what would it look like to try to expose
| & make useful JavaScript's new Temporal standard library, or
| Intl, or currenc... oh wait we don't have currency. ;)
| rektide wrote:
| why do i always get downvoted for having fun? i'm not sure if i
| want to be coached, but i wish dissenters had to offer
| something, other than minuses. did you all not also have fun at
| this mismatch? does the question of how to offer platforms up
| not entice you at all? is my tone off? so many downvotes on
| hacker news. i usually chalk it up to ya'll but i would like to
| know. -1! bah. who are you?! why?!
| microtherion wrote:
| I didn't downvote you, but initially I did not get your joke.
|
| It does stand to reason, I guess, that currency is as
| fundamental to Apple as system calls are to Linux.
| bartvk wrote:
| You're rambling a little, is my guess. Plus, humor seems
| appreciated here, but not as the single point of a post.
| wux wrote:
| The term "currency type" is used here to mean a type that is
| commonly used.
|
| For example, although there are a variety of range types in the
| Swift standard library ('Range', 'ClosedRange',
| 'PartialRangeFrom', 'PartialRangeUpTo', etc.), 'Range' is
| considered the currency type. Similarly, among string types,
| 'String' is considered the currency type, as opposed to
| 'Substring', 'StaticString', etc.
|
| Like currency (money), the idea is that APIs in different
| libraries across different domains of programming will
| generally take values of the currency type as input and produce
| values of the currency type as output unless there's a good
| reason to use a different type.
|
| For Swift System, the stated goal is to provide low-level
| currency types; if that goal is accomplished, other users of
| Swift can rely on these types instead of supporting multiple
| disparate third-party wrappers of system calls that may provide
| similar functionality just so that they can interoperate with
| other libraries.
| lilyball wrote:
| I've never before heard of the phrase "currency types". I
| even searched the web for "system currency types" and only
| got money-related results.
| wux wrote:
| It may just be jargon specific to the Swift community:
|
| https://www.google.com/search?q=swift+evolution+%22currency
| +...
| rubiquity wrote:
| This is great. I played around with Swift three years ago and
| tried to use the socket APIs. In the end, it felt like I was
| essentially writing C just with prettier syntax. Now that we have
| safer languages we need safer foundational pieces too.
|
| As a side note, the approach that Swift is taking here is exactly
| what I really like about the Zig programming language. The
| standard library nearly exclusively takes the approach of
| wrapping the system calls so you get nice Zig error types rather
| than the archaic return codes. These things go a long way in
| making correct usage of really essential but hard to use APIs
| possible.
| Copenjin wrote:
| Is this just a wrapper around a subset of system calls? Looking
| at the code it seems to be, not sure.
| NobodyNada wrote:
| It looks like it:
|
| > a new library for Apple platforms that provides idiomatic
| interfaces to system calls and low-level currency types
|
| In other words, it's a set of native, type-safe Swift APIs that
| wrap the usual C system calls.
|
| > System pervasively uses raw representable structs and option
| sets. These strong types help catch mistakes at compile time
| and are trivial to convert to and from the weaker C types.
|
| > Errors are thrown using the standard language mechanism and
| cannot be missed. Further, all system calls interruptible by a
| signal take a defaulted-true retryOnInterrupt argument, causing
| them to retry on failure. When combined, these two changes
| dramatically simplify error and signal handling.
|
| > FilePath is a managed, null-terminated bag-of-bytes that
| conforms to ExpressibleByStringLiteral -- far safer to work
| with than a UnsafePointer<CChar> [Swift's spelling of `char
| *`].
| layoutIfNeeded wrote:
| >causing them to retry on failure
|
| I hope they meant in case of failure with EINTR.
| usmannk wrote:
| Yes, it's a typed, safe wrapper around a subset of Darwin or
| Glibc (depending on platform) functions. See:
| https://github.com/apple/swift-system/blob/main/Sources/Syst...
| itiman wrote:
| Yes, this is a wrapper.
|
| [0] https://github.com/apple/swift-
| system/blob/main/Sources/Syst...
|
| [1] https://github.com/apple/swift-
| system/blob/main/Sources/Syst...
|
| [2] https://github.com/apple/swift-
| system/blob/main/Sources/Syst...
| ChrisMarshallNY wrote:
| Yes, and I'm glad for it. Not sure if it's "ready for prime
| time," yet (it sounds like it may still be too "nascent" for
| me), but I'll have to see if I can use it to tweak stuff like
| this[0]: var md5: String { // The
| reason we are declaring these here, is so we don't have to
| actally import the CC module. We will just grope around and
| find the entry point, ourselves. ///
| This is a cast for [the MD5 function](https://developer.apple.c
| om/library/archive/documentation/System/Conceptual/ManPages_iPh
| oneOS/man3/CC_MD5.3cc.html#//apple_ref/doc/man/3cc/CC_MD5).
| [The convention attribute](https://docs.swift.org/swift-
| book/ReferenceManual/Attributes.html#ID600) just says that it's
| a "raw" C function. typealias CC_MD5_TYPE =
| @convention(c) (UnsafeRawPointer, UInt32,
| UnsafeMutableRawPointer) -> UnsafeMutableRawPointer
| // This is a flag, telling the name lookup to happen in the
| global scope. No dlopen required. let RTLD_DEFAULT
| = UnsafeMutableRawPointer(bitPattern: -2)
| // This loads a function pointer with the CommonCrypto MD5
| function. // [dlsym](https://developer.apple.com/li
| brary/archive/documentation/System/Conceptual/ManPages_iPhoneOS
| /man3/dlsym.3.html) is a symbol lookup. It finds the symbol in
| our library, and returns a pointer to it. let
| CC_MD5 = unsafeBitCast(dlsym(RTLD_DEFAULT, "CC_MD5")!, to:
| CC_MD5_TYPE.self) // This is the
| length of the hash let CC_MD5_DIGEST_LENGTH = 16
| guard let strData = self.data(using: .utf8) else { return "" }
| /// Creates an array of unsigned 8 bit integers that contains
| 16 zeros var digest = [UInt8](repeating: 0, count:
| Int(CC_MD5_DIGEST_LENGTH)) /// CC_MD5 performs
| digest calculation and places the result in the caller-supplied
| buffer for digest (md) /// Calls the given closure
| with a pointer to the underlying unsafe bytes of the strData's
| contiguous storage. _ = strData.withUnsafeBytes {
| (inBytes) -> Int in // CommonCrypto
| // extern unsigned char *CC_MD5(const void *data, CC_LONG len,
| unsigned char *md) --| // OpenSSL
| | // unsigned char *MD5(const unsigned char *d,
| size_t n, unsigned char *md) <-| if let
| baseAddr = inBytes.baseAddress { _ =
| CC_MD5(baseAddr, UInt32(strData.count), &digest)
| } return 0 }
| // Convert the numerical response to an uppercase hex string.
| return digest.reduce("") { (current, new) -> String in
| String(format: "\(current)%02X", new) } }
|
| As a Swift programmer, the above hurts my heart (but it works
| very well).
|
| [0]
| https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool...
| djxfade wrote:
| import Foundation import CryptoKit
|
| extension String { var md5: String { let computed =
| Insecure.MD5.hash(data: self.data(using: .utf8)!) return
| computed.map { String(format: "%02hhx", $0) }.joined() } }
| alexchamberlain wrote:
| The article states that operating system "offer a C interface";
| that's not really true of Linux, at least. It provide a series of
| system calls on which a C API is built. It's a subtle difference,
| but am important one if you're going to provide a runtime system
| abstraction.
| moonchild wrote:
| If you're going to be so pedantic as to say that linux doesn't
| offer a C interface, then you also have to acknowledge that
| linux is not an operating system.
|
| If linux is not an operating system, what is? Gnu/linux is a
| very popular operating system offering a c interface, as is
| android linux. I do not know of any linuxoid operating systems
| not offering a c interface.
| samatman wrote:
| Can you elaborate on the difference you're pointing to here?
|
| I'm seeing a distinction without a difference, but clearly you
| aren't.
| msla wrote:
| It's a bit more complicated than some of the other posters
| are making it seem:
|
| https://utcc.utoronto.ca/~cks/space/blog/unix/UnixAPIAndCRun.
| ..
|
| > A few Unixes explicitly say that the standard C library is
| the stable API and point of interface with the system; one
| example is Solaris (and now Illumos). Although they don't
| casually change the low level system call implementation, as
| far as I know Illumos officially reserves the right to change
| all of their actual system calls around, breaking any user
| space code that isn't dynamically linked to libc. If your
| code breaks, it's your fault; Illumos told you that dynamic
| linking to libc is the official API.
|
| > Other Unixes simply do this tacitly and by accretion. For
| example, on any Unix using nsswitch.conf, it's very difficult
| to always get the same results for operations like
| getaddrinfo() without going through the standard C library,
| because these may use arbitrary and strange dynamically
| loaded modules that are accessed through libc and require
| various random libc APIs to work. This points out one of the
| problems here; once you start (indirectly) calling random
| bits of the libc API, they may quite reasonably make
| assumptions about the runtime environment that they're
| operating in. How to set up a limited standard C library
| runtime environment is generally not documented; instead the
| official view is generally 'let the standard C library
| runtime code start your main() function'.
|
| The kernel's API (which isn't C, but assembly language, as it
| relies on special opcodes) might be guaranteed stable, as it
| is in Linux, but even so there are or might be reasons you
| should call into libc anyway, and take advantage of the
| official functionality there.
| samatman wrote:
| Thank you, they were all good answers, but this one gets at
| why I was confused on the matter.
| wwright wrote:
| You can't write code that expects to call C functions to
| interop with the Linux system interface. You have to call the
| syscalls directly without a C-like ABI.
|
| There is _some_ functionality you can access from glibc at
| link time, but not all of it (as some are implemented as
| macros). Even then, that 's glibc providing the interface,
| not Linux.
|
| As the other commenter said, this is subtle (and probably
| non-consequential) for most people, but if you are writing an
| abstraction over the system interfaces, it becomes very
| significant to your codebase.
|
| As an example, you can lookup how Go does syscalls on Linux.
| It has some important consequences for their low-level design
| decisions: https://utcc.utoronto.ca/~cks/space/blog/programmi
| ng/GoSched...
| wahern wrote:
| OTOH, Linux's setuid and similar interfaces are per-thread,
| not per-process as required by POSIX and as what most
| people would expect--particularly in the context of
| software security. glibc and musl have to emulate the POSIX
| behavior, and doing it correctly is _extremely_ tricky. See
| https://ewontfix.com/17/
|
| Linux's various APIs used for container frameworks also
| tend to be per-thread, not per-process; that can be both
| useful and a giant headache, depending on context. It's
| somewhat ironic that Go was used for Docker as Go is pretty
| much the worst possible language you could choose in this
| regard. Go deliberately and thoroughly obscures native
| thread and process semantics. IIRC, Docker was already well
| along and established before Go even introduced an API for
| pinning a goroutine to a machine (kernel) thread. I once
| ran across a comment where the author of (I think) runc
| lamented his choice of Go. But I haven't been able to find
| it again, so it's entirely possible it's a misattribution
| on my part.
| snuxoll wrote:
| On many POSIX compliant systems the stable interface to the
| system is libc, with syscalls being unstable and changing
| between releases.
|
| Linux itself does not provide a libc or other similar system
| library implementation (even NT has ntdll as the stable
| syscall layer), and it's the syscall numbers and parameters
| themselves that are the stable interface.
| alexchamberlain wrote:
| I guess I just meant that you don't have to code against a C
| ABI to make system calls: it may be more efficient to do the
| grunt work around the system call in the "local" language and
| only make the system call at the end.
| jmull wrote:
| > It provide a series of system calls on which a C API is
| built.
|
| I can't see how that isn't offering a C interface.
| mhh__ wrote:
| One thing not mentioned by others so far is that not all
| system calls available on Linux are actually available in
| (say) glibc, for example if you want to access the perf_event
| subsystem you'll have to write your own C function to handle
| it (This is not true for eBPF IIRC).
| alexchamberlain wrote:
| As one of the cousin comments said, on Linux the syscall
| table is defined as stable and various POSIX(-like) C APIs
| (glibc for example) are built on top.
| jmull wrote:
| ... thus glibc is one of the C interfaces to which the
| article refers!
|
| I guess I should just stop since you're making a
| distinction I just am not getting. I realize glibc doesn't
| == syscalls, but I don't see how that's relevant to the
| article.
| alexchamberlain wrote:
| To be really pedantic, the pure Linux OS doesn't provide
| the C interface - a layer on top does.
| creata wrote:
| I think that's fair to say for Linux, since it aims for syscall
| compatibility, but I don't think that's true for Windows or
| macOS, where (unless I'm mistaken) your only options are to use
| libc (or an equivalent) or to constantly track breaking changes
| to the syscall interface.
| sedatk wrote:
| I don't recall any breaking changes on Windows syscall
| interface, can you give an example?
| JeanSebTr wrote:
| You don't do direct syscall on Windows, you make those
| through system DLLs.
| moonchild wrote:
| Windows syscall interface changes all the time. [1] has a
| table of windows syscall numbers. Just looking at the first
| syscall, NtAcceptConnectPort, you can see that all
| windowses up to and including 7 used 0x60; windows 8
| changed to 0x61; 8.1 changed it to 1; and then 10 changed
| it to 2.
|
| 1. https://j00ru.vexillium.org/syscalls/nt/64/
| trasz wrote:
| The C API for syscalls is mostly (almost entirely) just thin,
| 1:1 wrappers around the system calls themselves. In FreeBSD
| most of it is automatically generated from the same
| sys/kern/syscalls.master file that is used to generate the
| kernel syscall table.
| ohazi wrote:
| What's the advantage of Swift over Rust if I'm looking at
| ditching C++ on a project that has nothing to do with Apple's
| ecosystem?
|
| Currently the top two comments suggest that Swift looks
| compelling for this use case, but I don't really see it.
| potatochup wrote:
| If you don't need super-high performance it should in theory be
| easier to develop in swift as the automatic memory management
| is easier to deal with than rusts lifetimes/borrow checking. I
| tried them both out a few years ago, but gave up on swift
| because the cross-platform development story was poor. That's
| gotten better now it seems, but I'm already comfortable enough
| writing rust for everything I see no reason to switch.
| landemva wrote:
| I initially was excited that Swift https://www.swift.com/ had
| opened it's payment APIs.
| monoideism wrote:
| I knew there was no chance of that, so I parsed it correctly.
| diego_moita wrote:
| Your comment is funny, but I bet the majority of people here
| won't get your joke.
|
| Most people on this thread are the ones that care a lot about
| the Swift programming language. Most of the ones that would
| understand the joke are not reading this thread.
| didibus wrote:
| There's nothing about Swift that has me interested, curious or
| excited. That said, I haven't done much research into it. What is
| new and interesting about Swift?
|
| From looking through the swift official site, it just seems like
| a new C# or Java with ahead of time compilation.
|
| The only slightly unique bit I can find is that the syntax is a
| bit more JavaScript inspired.
|
| Am I missing something? Or that's it? It's just the C# of Apple?
|
| For example, Rust has borrow checking for zero cost memory
| safety.
|
| Go has concurrent sequential processes and its accompanying
| goroutines.
|
| Haskell is a fully pure language.
|
| Python has cool indent based syntax that looks like pseudocode.
|
| Ruby is objects all the way down and has this unique concept of
| blocks for passing code around to be yielded.
|
| Clojure has immutable persistent data-structures as default and
| software transactional memory, while also being a Lisp bringing
| macros and all to the JVM.
|
| Erlang has actor concurrency.
|
| Etc.
|
| So in a similar vein, what would be Swift's innovation or
| originality here?
| Someone wrote:
| Firstly, wants wrong with being "the C# of Apple"? I think they
| wanted a language that can coexist with objective-C libraries,
| and is reasonably memory-efficient (adding RAM to phones
| decreases battery life) that they could control, and created
| it.
|
| They certainly didn't just make run-of-the mill choices for all
| language features. Some non-standard design choices they made
| (for better or for worse):
|
| - Reference counting without any automated cycle-breaking
|
| - Collections are value types (implemented somewhat efficiently
| by having copy-on-write collections)
|
| - the Character type is closer to what 'normal' people think a
| character is
| (https://developer.apple.com/documentation/swift/character)
|
| - consequently, string length is closer to what users who don't
| know Unicode internals expect it to be.
|
| - Arrays are 'different' ('inherited' from NSArray. See
| https://ridiculousfish.com/blog/posts/array.html)
|
| - protocols are a bit like interfaces, but protocol conformance
| can retroactively be added to classes, even to ones you didn't
| write or don't have the source code of.
| cmckn wrote:
| > the Character type is closer to what 'normal' people think
| a character is
|
| I'm sure I'm missing some nuanced downside to this, but this
| sounds fantastic. I've never fully understood the difference
| between Unicode code points and code units[0], and would love
| to think less about this sort of thing in Java (for ex. when
| using String#toCharArray).
|
| [0] I'm just regurgitating language from the String javadoc,
| this sentence might not even make sense.
| didibus wrote:
| > wants wrong with being "the C# of Apple"?
|
| Oh nothing. It makes sense for Apple to want a more modern
| language to replace the now aging Objective C. In turn, that
| meant Swift was not on my list of languages to try, but
| instead on my, possibly a language I'll be forced to use one
| day list, just as Java, C#, JS, and all are, by simply being
| defacto languages for some platform which depending what you
| work on, you have no choice over.
|
| But then I started seeing people in the comments claiming
| things like: "Swift is one of the most interesting languages
| right now". So I was like... Hum okay, what did I overlook?
|
| Now, I'd be okay with people saying that it improves
| drastically on C# and Java. If people think Swift is a
| dramatic improvement because of the sum of its part, like
| just little details here and there that end up making it much
| better, and they think that in turn could lead Swift to
| replace both Java and C# if it gained support on other
| platforms. That could make it quite interesting as well. So
| I'd be up to listen to those arguments as well.
| jibolash wrote:
| You realize you are speaking of a 6 year old language right?
| For some reason, it sounds like you are referring to some newly
| launched shiny new language that nobody has ever done anything
| with.
| cblconfederate wrote:
| that doesnt answer the question
| djcapelis wrote:
| I think it's a good point actually. I think it's reasonable
| to say swift isn't intended as a language to experiment
| with a specific concept, it's a six year old production
| language designed for a general set of usecases where it's
| good at a bunch of things that the languages it is
| replacing weren't as good at. There's some interesting
| discussions to be had about tradeoffs it makes but a
| question like "what's the one thing swift does that other
| languages don't do" is not the right way to evaluate a
| production language. It might explain why some people don't
| find it _interesting_ but swift was built to be a better
| tool, not merely an interesting one.
|
| A lot of really good programming languages are
| "uninteresting" in this way, and that's probably a good
| sign, not a bad one.
| cblconfederate wrote:
| the question was in the context of swift open sourcing
| something. if it s an apple-ecosystem-specific language ,
| it s not much use to the general audience
| meragrin_ wrote:
| There was no point made other than the language is 6
| years old and "someone" uses it. That's nice. I'm sure I
| can find other languages 6 years or older which people
| use and are not worth using.
|
| How long has Swift been available outside of Apple
| platforms? And I don't mean experimentally available
| either. They only posted an announcement a few days ago
| where Swift is deemed ready for early adopters on
| Windows. That certainly does not sound production quality
| there.
| meragrin_ wrote:
| You do realize Swift has only been officially supported for
| early adopters on Windows less than a week now? Ubuntu was
| the only officially supported distribution of Linux until
| earlier this year. Were any of the Linux distributions
| creating their own Swift packages?
| lisper wrote:
| > Am I missing something?
|
| Yes: Swift is now (and has been for a while) the standard
| language for developing iOS and MacOS apps. That makes it
| important completely independent of any features it may or may
| not have.
| k__ wrote:
| While a huge boon for the poor ObjC devs, this doesn't seem
| like much of a thing for the rest of the world.
| biztos wrote:
| Also, through the various *Kit libraries and now (sooner or
| later) SwiftUI, Apple is staking out a rapid-development
| territory that will be hard for the other ecosystem(s?) to
| match.
|
| So, if you have to choose between making your app for iOS
| first, or Android first, then in addition to any
| consideration of markets which might or might not apply to
| your business model, you will have a very strong incentive to
| choose Apple for time to production.
|
| I would love to see more serious competition on that front.
| didibus wrote:
| That is my current impression. Practically speaking, this is
| huge off course, but it's nothing inherent to Swift. Apple
| could have embraced any language, no matter what it was like,
| good or bad, and it be on this privilege position that would
| undoubtedly make it successful.
|
| And up until now, I was thinking I'll try Swift the day I'm
| forced too, because I'm working to develop an app for Mac or
| iOS.
|
| But then I started seeing some comments like: "For me, Swift
| is currently the most interesting language". So I thought I
| might be overlooking something.
|
| The most innovative feature I can find is null safety, which
| is alright, but I guess I've had my fun with it with Kotlin
| already. Someone mentioned good ABI compatibility, that is
| interesting, and I'll need to read up on that. Others say,
| it's just a nice mix of modern features in a well maintained
| package. That's great as well, you could argue C# and Java
| being older have some less modern aspects lingering. But
| that's nothing that makes me want to jump in it and try to
| use it for my next project.
| frogblast wrote:
| The primary feature of Swift is that it a more safe language
| (via many of the same mechanisms in languages you referred to
| above), while being extremely compatible with the extremely
| large API surface area of iOS/macOS (which is both in C and
| Objective-C), and allowing incremental adoption without having
| to rewrite existing application/library code.
|
| To have adopted any of those other languages requires dramatic
| changes to a huge amount of platform APIs, along with on-going
| challenges of divergence. Put another way, any other language
| would have basically forked the entire platform.
|
| The Swift developers definitely have ambitions beyond being a
| compatible with Apple's existing SDKs, but that's the
| fundamental thing Swift does that no other language can do.
| nicoburns wrote:
| The best thing about swift is it's ML-style type system
| (incidentally this is _also_ one of the best things about Rust,
| and one of the reasons why Rust is competitive in "higher
| level" application development scenarios as well as "systems
| programming").
|
| For me Sum Types and pattern matching in particular are an
| absolutely massive improvement over languages that only have
| classes/structs. They make statically typed languages feel
| almost as expressive as dynamic ones.
| symlinkk wrote:
| TypeScript has this too
| NobodyNada wrote:
| In my personal experience, Swift occupies the sweet spot in
| between Rust and something like Python for application-level
| programming. It's a modern and well-designed language with a
| Rust-like strong and expressive type system, including useful
| generics, powerful enums, and safe error handling. It also has
| fairly straightforward memory management, really
| straightforward polymorphism, seamless C interop, and good
| performance -- though it's not quite as fast as Rust because it
| prioritizes ease of use over zero-cost abstractions.
|
| So no, it doesn't really have a whole lot of "innovation or
| originality" -- but it essentially takes some of the best ideas
| of modern language design and wraps them into one general-
| purpose language for application development, and as a result I
| find it to be a really useful and practical language.
| kitsunesoba wrote:
| In terms of syntax it's much closer to Kotlin than it is C#
| (though still different).
|
| It has seamless interop with Objective-C and C, and can be
| mixed with about any language LLVM/Clang can handle (as long as
| you have C headers), compiling it all down to a small, self-
| contained binary.
|
| For now it's mainly useful on Apple platforms, but there's
| interest and efforts in cross platform from both Apple and the
| Swift community, so there's a lot of potential for it to be a
| great language for the main body of application code, with
| individual bits of functionality written in languages that make
| the most sense without too many layers of adapters or wrappers.
| nsonha wrote:
| I think the person meant in terms of identifiable
| trait/philosophy/focus. Swift and c# and maybe even kotlin
| are languages that are just a big piles of feature and does
| not really have an principle behind its design like stupid
| simple of golang or lazyness of haskel
| oconnor663 wrote:
| Swift has done some very original things around ABI stability:
| https://gankra.github.io/blah/swift-abi/
| mrwnmonm wrote:
| Is this just the language? Will we be able to develop ios apps on
| windows?
| jtvjan wrote:
| The core language has been open source for a while. Windows
| support was added a few days ago. It will not allow you to
| develop iOS apps on Windows, as the tools to do that are part
| of Xcode, which is not open source and not cross-platform.
|
| This announcement concerns Swift System, which provides a
| wrapper over UNIX functions like `open'. Since those functions
| come from C, they do things like using integers to represent
| files (``file descriptors'') and setting errno to indicate
| failure. System wraps them to make them into proper Swift
| functions that throw exceptions and make full use of the type
| system. It has been open-sourced and Linux support has been
| added.
| zer0zzz wrote:
| You might want to check out https://github.com/compnerd/swift-
| win32 as well
| kennywinker wrote:
| Yes just the language. iOS apps are built using UIKit or
| SwiftUI gui frameworks, neither of which have been ported to
| platforms other than macos or ios.
|
| This, and Foundation, are frameworks that allow you to write
| non-gui linux apps in swift (e.g. swift on the server) - and
| these could potentially be ported to windows as well.
| mrwnmonm wrote:
| Got it, thanks. <3
| joeblau wrote:
| Not iOS apps, but windows applications[1].
|
| [1] - https://swift.org/blog/swift-on-windows/
| itiman wrote:
| This reminds me of Node.js fs module that enables interacting
| with the file system on standard POSIX functions. Probably in
| 2030 we will have GPT-400 wrapping all of this primitive
| functions again and we will be relieved that progress is being
| made once again.
| breakfastduck wrote:
| Except Swift is developed by apple with Systems integrating the
| *NIX functions within a BSD foundation.
|
| Very shrewd from Apple, with linux on ARM looking the next big
| leap for cloud computing (amazon etc) being able to program in
| swift natively on a mac running apple silicon and host in an
| ARM box on the cloud, having open sourced the systems api, is a
| very attractive offering.
| notacoward wrote:
| I looked at Swift a bit recently, for no reason I can remember,
| and was quite pleasantly surprised. A decent type system, mostly-
| sane memory management and error handling, easy ways to call out
| to C - System will make that even better - seems to do OK on
| performance and library support. It doesn't seem like any kind of
| breakthrough, but nothing wrong with having another solid choice
| on the menu.
| kwargs wrote:
| Can you create decent GUIs with Swift on GNU/Linux???
| liuliu wrote:
| Not really. But I did this: https://liuliu.me/eyes/write-cross-
| platform-gui-in-swift-lik...
|
| Unlike most comments here, I felt that Swift was a Python
| replacement to me.
| raphlinus wrote:
| In theory, yes. It's a Turing-complete language with quite nice
| C FFI, so you can call into Gtk just fine. In practice, uhm,
| no.
|
| Apple's branding of SwiftUI and Swift is a bit of a double-
| edged sword, I think. The former is a highly proprietary,
| undocumented (but beautifully engineered) walled garden that
| only works on Apple hardware, and only recent OS versions at
| that. The latter is open source and _purports_ to be a general-
| purpose, cross platform language, comparable in scope to C++,
| C#, Go, Rust, Kotlin, and other comparable contenders. They
| have only themselves to blame if some of the perception of the
| former rubs off when people think about the latter.
| FlyingSnake wrote:
| Swift is slowly evolving into a formidable competitor to C++, and
| Rust. SwiftNIO, Swift on Windows and now this multiplatform
| System library, Swift is truly on its way to become a mainstream
| systems language. Exciting Tim times indeed!
| pjmlp wrote:
| On Apple platforms yes, on the other ones still needs to learn
| to walk, before it can fight.
| sedatk wrote:
| OP said systems language, and what's Swift lacking there on
| other platforms?
| meragrin_ wrote:
| Well, it has only been available on Windows specifically
| for early adopters for a few days now. I imagine it has a
| long ways to go to prove itself there.
| zamalek wrote:
| Sane APIs (with exception of course, SwiftUI looked beyond
| Apple's ecosystem for inspiration).
|
| If you've been putting up with the [lack of] iOS API
| ergonomics for years, by all means, Swift will look like a
| substantial step forward. If you're used to thoughtful and
| quality APIs, the marriage between Swift and
| NSDrunkApiDesign is an incredibly unattractive proposition.
|
| I really just refuse to tolerate those APIs on platforms
| (.Net) and languages (Rust stdlib) where more sensible APIs
| are available. If there were an alternative stdlib for
| Swift that lacked/wrapped the iOS quirks, I'd probably be
| all for it.
| rektide wrote:
| Harsh take, but IMO you are irrelevant & asleep as a language
| unless you have something to offer on:
|
| https://github.com/quicwg/base-drafts/wiki/Implementations
|
| Phrased another way, your language should be participating in
| the future of HTTP, which is HTTP3 aka HTTP-over-QUIC. Swift's
| absence here indicates, to me, that Swift does not take itself
| seriously as a tool for delivering server side systems.
|
| IBM dropping swift was another pretty strong indicator to me.
| They really tried, they wanted to believe. But this seems like
| an insular, closed off world, however much they keep going
| through long lengths like this effort here to open themselves
| up & make themselves accessible to the rest of the world. Their
| attempts to build bridges haven't seemed to make people be very
| interested in transitting over to their parcel of land, the
| advantages aren't clear, choices of language just don't seem
| that relevant, there's some advantages but overall the day to
| day won't be radically different except that you'll be an
| outsider hanging out with a bunch of people mostly entirely
| doing iOS. I'd be happy to be wrong, seems decent enough, maybe
| there's some real differentiation that truly improves life, but
| it also seems like it's a C# type situation, where it exists &
| is developed only to keep the natives in spirits & from getting
| restless.
|
| I want to re-iterate that I think Swift seems pretty ok. More
| than not-bad. But languages just don't seem that relevant to me
| any more. Rust is being extra-strict, but otherwise, the
| feature-sets of languages doesn't seem very notable. There's
| some preferences & styles, some community favor that
| distinguishes languages, but by & large the work is not that
| different. I'm not sure what I would suggest to Swift to help
| themselves rise above, to underscore their own meaningfulness,
| in this kind of murky abyss-like scenario I've painted. I do
| think trying to win some AI champions makes sense; python seems
| to be unshakeable there, but that also means there's
| opportunity for better/different. Trying to get some web-
| developers web-platform folk on your side is usually a pretty
| big win, but not easy, & very factionalized already. It's weird
| days for languages.
| k__ wrote:
| _" Swift is slowly evolving into a formidable competitor to ...
| Rust"_
|
| _" Swift uses Automatic Reference Counting (ARC) to manage
| memory."_
| mhh__ wrote:
| What's the USP for swift? To my eye it looks too far away from
| C++ to catch on without a big selling point, but also doesn't
| have central thesis as it's core like Rust.
| FlyingSnake wrote:
| Swift can be a great alternative to C++, and it's learning
| curve is smaller than Rust. Of course it had a long way to
| go, but nevertheless it is a interesting language.
| FandangoRanger wrote:
| Isn't the core value of Swift in Apple's large set of libraries?
___________________________________________________________________
(page generated 2020-09-25 23:00 UTC)