18 ms·

Swift System Is Now Open Source

500 points by NobodyNada 6y ago

Copenjin 6y ago
Is this just a wrapper around a subset of system calls? Looking at the code it seems to be, not sure.
- NobodyNada 6y ago
  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 6y ago
    >causing them to retry on failure I hope they meant in case of failure with EINTR.
- usmannk 6y ago
  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/SystemInternals/Exports.swift https://github.com/apple/swift-system/blob/main/Sources/Syst...
- itiman 6y ago
  Yes, this is a wrapper. [0] https://github.com/apple/swift-system/blob/main/Sources/System/FileOperations.swift#L29 https://github.com/apple/swift-system/blob/main/Sources/Syst... [1] https://github.com/apple/swift-system/blob/main/Sources/System/FileOperations.swift#L80 https://github.com/apple/swift-system/blob/main/Sources/Syst... [2] https://github.com/apple/swift-system/blob/main/Sources/SystemInternals/Exports.swift#L38 https://github.com/apple/swift-system/blob/main/Sources/Syst...
- ChrisMarshallNY 6y ago
  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.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/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/library/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_Toolbox/blob/fe771c3b577724563852b186b1acf202a89109f8/Sources/RVS_Generic_Swift_Toolbox/Extensions/RVS_String_Extensions.swift#L104 https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool...
FlyingSnake 6y ago
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 6y ago
  On Apple platforms yes, on the other ones still needs to learn to walk, before it can fight.
  - sedatk 6y ago
    OP said systems language, and what’s Swift lacking there on other platforms?
    - zamalek 6y ago
      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.
      - saagarjha 6y ago
        Swift ships with an extremely polished, well designed standard library out-of-the-box. You can use it with a simple "import Swift"…wait, you don't even need to do that, because it's available by default.
        zamalek 6y ago
        Why do I then see NSGarbage all over the place in Swift code? Swift is a language facade over Objective C.
FandangoRanger 6y ago
Isn't the core value of Swift in Apple's large set of libraries?
usmannk 6y ago
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/SystemInternals/Exports.swift 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.
- wwright 6y ago
  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).
  - usmannk 6y ago
    > 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 6y ago
      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.
rektide 6y ago
> 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 6y ago
  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 6y ago
    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 6y ago
    You're rambling a little, is my guess. Plus, humor seems appreciated here, but not as the single point of a post.
  - chrismsimpson 6y ago
    The trolls need constant feeding. Wear your negative karma as a badge of honour.
alexchamberlain 6y ago
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.
- samatman 6y ago
  Can you elaborate on the difference you're pointing to here? I'm seeing a distinction without a difference, but clearly you aren't.
  - wwright 6y ago
    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/programming/GoSchedulerAndSyscalls https://utcc.utoronto.ca/~cks/space/blog/programming/GoSched...
    - wahern 6y ago
      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/ 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.
landemva 6y ago
I initially was excited that Swift https://www.swift.com/ https://www.swift.com/ had opened it's payment APIs.
- diego_moita 6y ago
  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.
- monoideism 6y ago
  I knew there was no chance of that, so I parsed it correctly.
- abalaji 6y ago
  For those that don’t know Swift is: > DescriptionThe Society for Worldwide Interbank Financial Telecommunication, legally S.W.I.F.T. SCRL, provides a network that enables financial institutions worldwide to send and receive information about financial transactions in a secure, standardized and reliable environment. https://en.wikipedia.org/wiki/Society_for_Worldwide_Interbank_Financial_Telecommunication https://en.wikipedia.org/wiki/Society_for_Worldwide_Interban...
mrwnmonm 6y ago
Is this just the language? Will we be able to develop ios apps on windows?
- kennywinker 6y ago
  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 6y ago
    Got it, thanks. <3
- jtvjan 6y ago
  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.
- joeblau 6y ago
  Not iOS apps, but windows applications[1]. [1] - https://swift.org/blog/swift-on-windows/ https://swift.org/blog/swift-on-windows/
- zer0zzz 6y ago
  You might want to check out https://github.com/compnerd/swift-win32 https://github.com/compnerd/swift-win32 as well
itiman 6y ago
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 6y ago
  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.
ohazi 6y ago
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 6y ago
  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.
- pornel 6y ago
  Swift is designed for making nice, concise, clever APIs. It favors convenient abstractions over raw performance. It's very well-suited for GUI applications (that's the #1 task it's been created for). That may extend to application back-ends that have lots of business logic, but don't need to process large amounts of data. This is in contrast to Rust, where more explicit memory management makes GUI frameworks a bit tedious. Rust is more explicit and gives lower-level of control, but borrow checking favors simple code over abstract interfaces. To me Swift is more like native TypeScript, and a more practical alternative to JavaScript and Python for app development. Rust is a more direct replacement for C++, because it offers similar level of performance and control over every byte in the program. Rust's compiler doesn't dare to insert any implicit allocations or non-trivial code itself, and will make programmer make every choice intentionally. Swift's compiler does whatever it takes to implement whatever abstraction it presents.
kwargs 6y ago
Can you create decent GUIs with Swift on GNU/Linux???
- raphlinus 6y ago
  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.
  - raphlinus 6y ago
    I meant to say "underdocumented" here. Its internals are undocumented, which is potentially a problem because there's no source available, but there is basic documentation for using SwiftUI. It's still sparse but I'm sure will improve as it matures.
- liuliu 6y ago
  Not really. But I did this: https://liuliu.me/eyes/write-cross-platform-gui-in-swift-like-it-is-1998/ 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.
rubiquity 6y ago
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.
- pjmlp 6y ago
  We always had them. What we have now is the acknowledgement that after 60 years even 10x C developers don't write corruption free code.
didibus 6y ago
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?
- jibolash 6y ago
  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 6y ago
    that doesnt answer the question
    - djcapelis 6y ago
      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.
notacoward 6y ago
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.
monadic2 6y ago
They're trying hard, but the main draw of the language will always be their proprietary UI frameworks, same as objective-c.
rangoon626 6y ago
So the AppStore goes, so Swift goes.
OMGCable 6y ago
Swift for Android! The Swift Android Compiler allows the Standard Library to be compiled for Android armv7 targets. Consequently, you have the ability to execute the Swift code on mobile devices running Android. This is where the Low-Level Virtual Machine (LLVM) Architecture comes in, enabling targeting those with a backend LLVM compiler; something Google already does with Android Development from C/C++. Therefore, the LLVM provides a window into its’ compatibility with other systems/software/devices.
sulam 6y ago
Most everything has pros and cons but apparently Swift System has no cons! Amazing! “... provides idiomatic interfaces to system calls and low-level currency types.”
aliraza45895478 6y ago
What is this ?
mkj 6y ago
Is this built on top of libc or using Linux syscalls directly?

500 points by NobodyNada 6y ago

Copenjin 6y ago

Is this just a wrapper around a subset of system calls? Looking at the code it seems to be, not sure.

NobodyNada 6y ago
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 6y ago
  >causing them to retry on failure I hope they meant in case of failure with EINTR.
usmannk 6y ago
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/SystemInternals/Exports.swift https://github.com/apple/swift-system/blob/main/Sources/Syst...
itiman 6y ago
Yes, this is a wrapper. [0] https://github.com/apple/swift-system/blob/main/Sources/System/FileOperations.swift#L29 https://github.com/apple/swift-system/blob/main/Sources/Syst... [1] https://github.com/apple/swift-system/blob/main/Sources/System/FileOperations.swift#L80 https://github.com/apple/swift-system/blob/main/Sources/Syst... [2] https://github.com/apple/swift-system/blob/main/Sources/SystemInternals/Exports.swift#L38 https://github.com/apple/swift-system/blob/main/Sources/Syst...
ChrisMarshallNY 6y ago
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.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/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/library/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_Toolbox/blob/fe771c3b577724563852b186b1acf202a89109f8/Sources/RVS_Generic_Swift_Toolbox/Extensions/RVS_String_Extensions.swift#L104 https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool...

FlyingSnake 6y ago

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 6y ago
On Apple platforms yes, on the other ones still needs to learn to walk, before it can fight.
- sedatk 6y ago
  OP said systems language, and what’s Swift lacking there on other platforms?
  - zamalek 6y ago
    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.
    - saagarjha 6y ago
      Swift ships with an extremely polished, well designed standard library out-of-the-box. You can use it with a simple "import Swift"…wait, you don't even need to do that, because it's available by default.
      - zamalek 6y ago
        Why do I then see NSGarbage all over the place in Swift code? Swift is a language facade over Objective C.

FandangoRanger 6y ago

Isn't the core value of Swift in Apple's large set of libraries?

usmannk 6y ago

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/SystemInternals/Exports.swift 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.

wwright 6y ago
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).
- usmannk 6y ago
  > 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 6y ago
    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.

rektide 6y ago

> 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 6y ago
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 6y ago
  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 6y ago
  You're rambling a little, is my guess. Plus, humor seems appreciated here, but not as the single point of a post.
- chrismsimpson 6y ago
  The trolls need constant feeding. Wear your negative karma as a badge of honour.

alexchamberlain 6y ago

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.

samatman 6y ago
Can you elaborate on the difference you're pointing to here? I'm seeing a distinction without a difference, but clearly you aren't.
- wwright 6y ago
  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/programming/GoSchedulerAndSyscalls https://utcc.utoronto.ca/~cks/space/blog/programming/GoSched...
  - wahern 6y ago
    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/ 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.

landemva 6y ago

I initially was excited that Swift https://www.swift.com/ https://www.swift.com/ had opened it's payment APIs.

diego_moita 6y ago
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.
monoideism 6y ago
I knew there was no chance of that, so I parsed it correctly.
abalaji 6y ago
For those that don’t know Swift is: > DescriptionThe Society for Worldwide Interbank Financial Telecommunication, legally S.W.I.F.T. SCRL, provides a network that enables financial institutions worldwide to send and receive information about financial transactions in a secure, standardized and reliable environment. https://en.wikipedia.org/wiki/Society_for_Worldwide_Interbank_Financial_Telecommunication https://en.wikipedia.org/wiki/Society_for_Worldwide_Interban...

mrwnmonm 6y ago

Is this just the language? Will we be able to develop ios apps on windows?

kennywinker 6y ago
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 6y ago
  Got it, thanks. <3
jtvjan 6y ago
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.
joeblau 6y ago
Not iOS apps, but windows applications[1]. [1] - https://swift.org/blog/swift-on-windows/ https://swift.org/blog/swift-on-windows/
zer0zzz 6y ago
You might want to check out https://github.com/compnerd/swift-win32 https://github.com/compnerd/swift-win32 as well

itiman 6y ago

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 6y ago
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.

ohazi 6y ago

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 6y ago
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.
pornel 6y ago
Swift is designed for making nice, concise, clever APIs. It favors convenient abstractions over raw performance. It's very well-suited for GUI applications (that's the #1 task it's been created for). That may extend to application back-ends that have lots of business logic, but don't need to process large amounts of data. This is in contrast to Rust, where more explicit memory management makes GUI frameworks a bit tedious. Rust is more explicit and gives lower-level of control, but borrow checking favors simple code over abstract interfaces. To me Swift is more like native TypeScript, and a more practical alternative to JavaScript and Python for app development. Rust is a more direct replacement for C++, because it offers similar level of performance and control over every byte in the program. Rust's compiler doesn't dare to insert any implicit allocations or non-trivial code itself, and will make programmer make every choice intentionally. Swift's compiler does whatever it takes to implement whatever abstraction it presents.

kwargs 6y ago

Can you create decent GUIs with Swift on GNU/Linux???

raphlinus 6y ago
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.
- raphlinus 6y ago
  I meant to say "underdocumented" here. Its internals are undocumented, which is potentially a problem because there's no source available, but there is basic documentation for using SwiftUI. It's still sparse but I'm sure will improve as it matures.
liuliu 6y ago
Not really. But I did this: https://liuliu.me/eyes/write-cross-platform-gui-in-swift-like-it-is-1998/ 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.

rubiquity 6y ago

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.

pjmlp 6y ago
We always had them. What we have now is the acknowledgement that after 60 years even 10x C developers don't write corruption free code.

didibus 6y ago

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?

jibolash 6y ago
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 6y ago
  that doesnt answer the question
  - djcapelis 6y ago
    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.

notacoward 6y ago

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.

monadic2 6y ago

They're trying hard, but the main draw of the language will always be their proprietary UI frameworks, same as objective-c.

rangoon626 6y ago

So the AppStore goes, so Swift goes.

OMGCable 6y ago

Swift for Android! The Swift Android Compiler allows the Standard Library to be compiled for Android armv7 targets. Consequently, you have the ability to execute the Swift code on mobile devices running Android. This is where the Low-Level Virtual Machine (LLVM) Architecture comes in, enabling targeting those with a backend LLVM compiler; something Google already does with Android Development from C/C++. Therefore, the LLVM provides a window into its’ compatibility with other systems/software/devices.

sulam 6y ago

Most everything has pros and cons but apparently Swift System has no cons! Amazing! “... provides idiomatic interfaces to system calls and low-level currency types.”

aliraza45895478 6y ago

What is this ?

mkj 6y ago

Is this built on top of libc or using Linux syscalls directly?