swift-evolution
foundationdb
Our great sponsors
swift-evolution | foundationdb | |
---|---|---|
124 | 21 | |
14,939 | 13,898 | |
0.8% | 2.0% | |
9.7 | 9.8 | |
7 days ago | 2 days ago | |
Markdown | C++ | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
swift-evolution
-
Byte-Sized Swift: Building Tiny Games for the Playdate
[A Vision for Embedded Swift](https://github.com/apple/swift-evolution/blob/main/visions/e...) has the details on this new build mode and is quite interesting.
> Effectively, there will be two bottom layers of Swift, and the lower one, “non-allocating” Embedded Swift, will necessarily be a more restricted compilation mode (e.g. classes will be disallowed as they fundamentally require heap allocations) and likely to be used only in very specialized use cases. “Allocating” Embedded Swift should allow classes and other language facilities that rely on the heap (e.g. indirect enums).
Also, this seems to maybe hint at the Swift runtime eventually being reimplemented in non-allocating Embedded Swift rather than the C++ (?) that it uses now:
> The Swift runtime APIs will be provided as an implementation that’s optimized for small codesize and will be available as a static library in the toolchain for common CPU architectures. Interestingly, it’s possible to write that implementation in “non-allocating” Baremetal Swift.
-
Borrow Checking Without Lifetimes
I may be out of my depth here as I've only casually used Rust, but this seems similar to Swift's proposed lifetime dependencies[1]. They're not in the type system formally so maybe they're closer to poloneius work
[1]: https://github.com/apple/swift-evolution/blob/3055becc53a3c3...
-
Functional Ownership Through Fractional Uniqueness
Swift recently adopted a region-based approach for safe concurrency that builds on Milano et al’s ideas: https://github.com/apple/swift-evolution/blob/main/proposals...
-
Crafting Self-Evident Code with D
No, it's not. Refcounting CAN be a garbage collection algorithm, but in Swift it's deterministic and done at compile time. Not to mention recently added support for non-copyable types that enforces unique ownership: https://github.com/apple/swift-evolution/blob/main/proposals...
-
Swift Ownership Manifesto
> It's super easy to cause its type check to timeout, which is something I haven't seen when using Rust.
Yeah, the operator overloading design makes it too easy to construct an exponential search space.
> For instance, Swift doesn't have the orphan rule, so it's possible that 2 packages implement the same protocol for the same type, and when this happens currently there are no solutions;
There's now a warning about this: https://github.com/apple/swift-evolution/blob/main/proposals.... What other solutions can there be other than making it a hard error? It seems like an inherent drawback of typeclasses over first-class modules.
> there is this strange design decision that classes and structs should be different things and each have their own set of random limitations
structs in Swift are the same as structs in Rust, and a class is a heap-allocated reference counted box, like an Arc>.
> and there is SwiftUI, which hacks on the syntax itself, making statements no longer mean what they are supposed to mean
Result builders are a language feature and not part of SwiftUI: https://github.com/apple/swift-evolution/blob/main/proposals...
Just last week owning and borrowing parameters got accepted as well. https://github.com/apple/swift-evolution/blob/main/proposals...
It’s been the focus for a while especially after the concurrency work. It’s probably the final major feature before Swift 6
Swift 5.9 dropped at WWDC, and with it came with noncopyable value types:
https://github.com/apple/swift-evolution/blob/main/proposals...
as well as a way to explicitly move types:
https://github.com/apple/swift-evolution/blob/main/proposals...
I haven’t read either in-depth, though!
-
SwiftData
They actually can figure that out, though [0]. I hope this can solve some of it because their deployment model is the dumbest fucking thing. I'm glad they figured out how to backport async/await, it's just impossible to use in a serious library otherwise.
[0] https://github.com/apple/swift-evolution/blob/main/proposals...
-
Is there a web site I can go to if I want to find the SwiftUI roadmap?
https://www.swift.org/swift-evolution/ is where the discussion and planning of the evolution of Swift takes place.
- Experienced developers, would you recommend learning backend rather than doing side projects in iOS?
foundationdb
-
Figma's Databases team lived to tell the scale
Actually, Apple does this for iCloud! They use FoundationDB[1] to store billions of databases, one for each user (plus shared or global databases).
See: https://read.engineerscodex.com/p/how-apple-built-icloud-to-...
Discussed on HN at the time: https://news.ycombinator.com/item?id=39028672
[1]: https://github.com/apple/foundationdb https://en.wikipedia.org/wiki/FoundationDB
-
WASM by Example
> I wondered if perhaps this WASM use case for a cross-language library was already just as possible and ergonomic using language bindings and maybe thats why this use case doesnt seem like a big deal to people.
Yeah that’s the reason. You don’t notice it a lot of the time, but FFIs are everywhere already. The most common foreign function interface is basically the ability to call C code, or have functions made available to C code. C is used because everyone knows it and it’s simple. And most languages either compile to native code (eg rust) - which makes linking to C code easy. Or the runtime is implemented in C or C++ (eg V8, Ruby). In languages like that, the standard library is already basically implemented via a FFI to C/C++ code.
I’ve got an iOS app I’m working on that’s half rust and half swift, with a touch of C in the middle. The bindings work great - the whole thing links together into one binary, even with link time optimizations. But the glue code is gross, and when I want to fiddle with the rust to Swift API I need to change my code in about 4 different places.
Most FFIs are a one to many relationship in that if you write a clean C API, you can probably write bindings in every language. But you don’t actually want to call naked C code from Ruby or Javascript. Good bindings will make you forget everything is done via ffi. Eg numpy. I haven’t looked at the wasm component model proposal - I assume it’s trying to make this process cleaner, which sounds lovely.
I maintain the nodejs bindings for foundationdb. Foundationdb bindings are all done via ffi linking to their C code. And the API is complex, using promises and things. I find it really interesting browsing their official bindings to go, Java, Python and Ruby. Same bindings. Same wrapped api. Same team of authors. Just different languages. And that’s enough to make the wrapper wildly different in every language. From memory the Java ffi wrapper is 4x as much code as it is in Ruby.
-
JDK 21 Release Notes
Isn’t apple server on C/C++?
They have their own db in that
-
How FoundationDB works and why it works
> Any meaningful technology is open source.
Clearly untrue, however FoundationDB is open source, with a permissive license.
https://github.com/apple/foundationdb
So is much of the operational tooling for it:
-
FoundationDB: A Distributed Key-Value Store
I don't recall any of those details but the test involved injecting a bogus block device that always returns garbage, and noting that this results in garbage records returned from client queries. And I don't think those kinds of issues have been eradicated, browsing through their github issues there are people trying to recover corrupted clusters. https://github.com/apple/foundationdb/issues/2480
Those tests are not the implementations of the tests, just specifying the test case. But I found the implementations. I am not sure if this is all of them, but it seems to cover the major tests.
https://github.com/apple/foundationdb/tree/main/fdbserver/wo...
-
Install FoundationDB in Gentoo
For my current job, I have to install FoundationDB (they have a github repo) as a dependency for the project's code.
-
Anna: Key-Value Store for Any Scale
To clarify, FoundationDB has some documented multi-region features, but it's not at all clear that anybody who runs it at scale relies on those multi-region features [1]. Even if they do, it's not obvious they run this Fearless DR mode at any appreciable latency.
Geo-replication is an area where Anna really shines, and foundation pays severe costs. All of the concurrency control problems have contention footprints on the order of round-trips. Fully optimistic concurrency control needs to expose backoffs quite a few round-trips to be live. Even pessimistic concurrency control requires some number of round trips, probably at least 1.5 optimally, but in practice in most tuned systems, probably 3. A heck of a lot of use cases make sense at 0 global RTTs and don't at 1+. The ability to tell the database how to manage concurrency, and then providing causal is ultimately the best you can do. That's awesome.
At the end of the day, I have to believe that there's a whole big mess of applications we'll build this, on systems in the portion of the design space Anna is choosing, one day. This is only recently not cutting edge research, but it's definitely still research. We don't know how to model these concepts at a high-level and in a composable way where the masses of software developers can engage with them.
It's interesting to think about how long ago we were graced with BAYOU [2], that thing was ahead of its time. I suspect it's going to take a little while longer before these sorts of techniques make their way into data storage primitives we think of as part of the standard vernacular, but I believe we'll get there eventually.
Databases are fun!
[1] https://github.com/apple/foundationdb/wiki/Multi-Region-Repl...
-
FoundationDB: A Distributed Unbundled Transactional Key Value Store
(Disclaimer: affiliated)
Redwood isn't "completed", but it's not unavailable. Evaluating it via `fdbcli> configure ssd-redwood-1-experimental ` is encouraged, but it hasn't seen sufficiently deep evaluation and verification that it's been set as the default ssd storage engine yet.
Not all releases got blog posts. Which ones did honestly had far more to do with the people involved in the releases at the time than any technical merits. This is the first feedback that I've seen where the blog posts were used as a signal of worthiness or stability, so we'll see if we can try to be a bit more responsible about making release posts.
Releases that are posted to the downloads page are all equally considered "ready to go". They appear a bit slower than what gets tagged on github, as the production environments in the core set of companies supporting FDB development are used as the last stage of QA before an official release. (Though this distinction might be less clear as the downloads page was recently redirected to the github release artifacts page.)
You can find the 7.0 release notes at https://github.com/apple/foundationdb/blob/main/documentatio..., which will appear in the documentation once the public site is updated to 7.0 (which happens once the first official, public release is blessed).
All that said, the regular release cadence so far has been about every 6 months, which I think still does qualify as "glacial".
What are some alternatives?
compose-multiplatform - Compose Multiplatform, a modern UI framework for Kotlin that makes building performant and beautiful user interfaces easy and enjoyable.
kotlinx-datetime - KotlinX multiplatform date/time library
okio - A modern I/O library for Android, Java, and Kotlin Multiplatform.
PeopleInSpace - Kotlin Multiplatform project with SwiftUI, Jetpack Compose, Compose for Wear, Compose for Desktop, Compose for Web and Kotlin/JS + React clients along with Ktor backend.
kotlin-wrappers - Kotlin wrappers for popular JavaScript libraries
swift-algorithms - Commonly used sequence and collection algorithms for Swift
swift - The Swift Programming Language
FASTER - Fast persistent recoverable log and key-value store + cache, in C# and C++.
kotlindl - High-level Deep Learning Framework written in Kotlin and inspired by Keras
kotlinx.serialization - Kotlin multiplatform / multi-format serialization
async-await-WWDC21-blog-post
KEEP - Kotlin Evolution and Enhancement Process