Here!
2 Likes
Firstly, huge congratulations to the new core team members. I'm sad to see Dave stepping down, but I hope he'll continue to be active with the language.
One domain that I think is worth keeping an eye on is scripting. Scripts are interesting, because lots of programs start out as scripts. At the same time, Swift is a great language for scripting, because (especially on Darwin systems) lots of system functionality is exposed via Swift. If I have to resize a bunch of images - sure, I could download imagemagick, learn it's complicated command-line interface and fumble around with shell scripts; or, if I'm on a Mac generating images for the AppStore, I could use Swift and the much more pleasant CoreGraphics interface.
It's incredibly common to want to have scripts that perform some action or generate other images based an image's contents. It's really hard to do this without a language like Swift, and it's great because all your code is also written in Swift.
Also - scripts really favour brevity. Not so much in the names of functions and parameters, but in how much boilerplate you need to just get something done. Things like parsing command-line arguments should be way easier than they currently are. Which brings me on to Foundation.
I don't think Foundation has really worked to make Swift a pleasant language to use. Part of that is structural - it has a closed evolution process and is entirely controlled by Apple. The other part is technical - it tries to be a platform-abstraction library over things like sockets and files, but really it's a system library, because it's part of the OS on Darwin platforms. That means Darwin platforms get the worst compatibility story, with @available and fallbacks everywhere, and the inability to take advantage of new API (e.g. let's say we added a new command-line parsing API - it would be unsupported on all current versions of macOS). I think there is room for a library above Foundation, with a more radically-swifty API and independent versioning.
The original goal was, I think, that Apple platforms would have an optimised version of Foundation because they build Swift in to the OS. That can still be true, and it's great that Apple provides Swift-native generic types and protocols in their OS libraries, but I think the smarter option is to access those fast Foundation APIs via an intermediate library that can float and add new features. Something more like what ToolsSupportCore provides.
I'm very happy to hear that low-level systems haven't been forgotten about 
14 Likes
For Swift scripting you might find swift-sh and related utilities (command line parsing, dealing with paths, etc) by @Max_Howell1 to be useful. I've used them some with good results. Max is open to contributions that improve them or fix issues you run into.
1 Like
@technicated Great stuff!
I've seen it - it's a very cool project! That's definitely something I'd like to see in the official compiler for Swift 6. You could see this as a natural extension of our existing support for swift run --repl.
WASM support is more difficult than other targets due to WASM itself not being sufficiently mature to support Swift. In particular, they do not have support for threading nor do they provide stubs for the necessary compatibility. Getting proper support for WASM in ICU would actually unblock the path to enabling the use of Swift on WASM IMO.
4 Likes
Well, the progress with the Sourcekit-LSP was significant. I’m using Swift from VSCode on Ubuntu 18.04 quite a lot without issues. And most of the issues is resolved by building package. Also, LLDB plugin on VSCode works great with Swift. I‘ve made it working in vim but I’m no big vim user. You can follow for example this guide: Swift Development with Visual Studio Code — On Linux! | by Peter Zignego | Medium
2 Likes
ICU is a big challenge. Rust doesn't have this problem because it includes its own ICU data which is at least enough for the minimal things they support (case mappings, some character properties like is_whitespace, etc). I believe we want to do the same, but we use much more data for full internationalisation, normalisation, etc.
3 Likes
Yes, this is something which has come up a couple of times before. @Michael_Ilseman has thoughts on how to accomplish this. I think that a rather useful investment in this area (perhaps @Michael_Ilseman is willing to do this or perhaps help to accomplish this) would be to write up an approach and break down the path to achieving independence from ICU. This would not only reduce the complexity of our builds but also the build size and distribution size while making it easier to port Swift to embedded environments.
There are a limited number (though greater than perhaps strictly necessary) where we fall to ICU in the standard library, and explicitly enumerating them and providing some guidance on what possible approaches for them could possibly speed up our ability to cleave that dependency.
7 Likes
There have also been a number of "embedded Swift" efforts, which often don't need any sort of higher-level Unicode support at all. Another approach we might take would be to work on establishing a subset of the standard library that can made available on more limited targets.
8 Likes
My concerns with such an approach is fragmentation of the language. The standard library in swift is far more crucial than in most other languages due to fundamental types getting in the standard library rather than defined by the compiler. Building that as a subset of the existing library in tree would be something that would be preferable to maintain across all platforms. In order to ensure future work does not break the model and features are properly supported would mean that ideally the library should also be split in Darwin which I feel would be unlikely to happen.
5 Likes
Personally I don't think that's necessary. Even with less-minimalist additions like CollectionDifference and the proposed RangeSet and DiscontiguousSlice APIs, the standard library is still just fundamental types and generic algorithms/data structures. The system requirements are still very barebones (you need dynamic memory allocation... and that's about it?).
Embedded platforms (and WASI right now) are usually statically linked, so anything you don't need in the standard library/runtime should get stripped anyway. There was a talk at the recent LLVM conference that suggested we might be flagging too many things with LLVM_USED and preventing DCE. I've inspected some built WASM files (which, again, are all statically linked) and they are full of runtime code I would expect to have been stripped, so there may be something to that - a simple print("hello, world") results in a >9MB binary.
If we can rely on DCE to remove things we don't use, and things in the standard library remain as platform-agnostic as they are, I don't see a need to introduce a "minimal" subset of it.
5 Likes
Right—in an ideal world, a reduction in @llvm.used by the Swift compiler would make it easier to avoid pulling in all the Unicode dependencies if you don't explicitly reference them. But even once that is resolved, I think that may be a bit optimistic when it comes to strings, since Unicode functionality is woven so intricately through their internal implementation and their APIs in their current state.
For example, many embedded users—or even regular Linux users not doing significant text processing—may not want the overhead of supporting anything other than ASCII strings. To avoid that overhead with just DCE, they'd need to make sure that nothing that they do ever touches a code path that might involve grapheme breaking, or normalization, or any other property queries—so that means using the Character type and related APIs are out, and also string comparisons, to name a couple very basic ones.
I'm sure that String could be refactored to better isolate ASCII-only behaviors, and a combination of that and user caution could achieve the desired goal—but I have no idea what the amount of effort involved in that would be.
1 Like
Yeah, getting rid of Unicode via DCE would be super impressive (FWIW, I'm not 100% sure we have any issues with DCE right now - I haven't had a chance to debug it).
Unicode is probably the only thing in the standard library that anybody might object to, though. If you can compile the language, and you can allocate memory, AFAIK you can support everything. So we could offer some kind of "alternative String" for those use-cases rather than split the standard library in to core/non-core components.
1 Like
as a mobile developer for more than 10 years, i can attest that lack of support for cross platform development is becoming the elephant in the room regarding swift.
in addition to javascript, and C# ( with unity) you can add Dart, kotlin, Typescript and even Go ( with gomobile) to the list of language that truely supports both android and ios.
this is becoming embarassing...
5 Likes
Not officially part of the swift project, but dnf install swift-lang
Dart is really only used for Flutter, Go's usage outside the server is negligible, Kotlin is used mainly for Android, and TypeScript is a JS compiler. Popularity hinges mostly on the use case, not how many platforms it can run on. Even if it was 100% usable on Windows/Android, there isn't yet a compelling use case.
Swift for TensorFlow and Server-side Swift mean it's already more relevant cross-platform than Objective-C. Given it's age, that's a good start for Swift. AFAIK kotlin is the only other language I'm aware of with a comparable adoption curve.
7 Likes
Writing and maintaining common code once instead of twice or more is compelling if you are doing more than creating simple thin clients for cloud services.
1 Like
But writing and maintaining what? There's no standard UI Libraries for Swift outside of Apple's platforms and Linux is the primary OS for servers. If you're building basic low-level utilities for Windows/Android, things that C/C++ is currently used for, until Swift has comparable performance it can't replace many of those uses.
The small amount of work left to support most other platforms pales in comparison to the work necessary to build out the king of application platforms needed to make using Swift a viable option on those platforms.
4 Likes
I'm sorry, i kind of miss your point. The fact is that most new languages allows for ios / android cross compilation in some way (either up to the UI components for things like react-native and dart, or just for business logic for go) and last time i checked building just a simple hello world on android using swift was a nightmare. I think i've even stumbled on project that had to fork swift to start working on android.
The embarassing thing is that swift doesn't have any real marketshare beside mobile development at the moment, and i don't see how that marketshare can grow if it can't compete in any way with any other cross-platform solution.
1 Like