Is Swift getting too complicated?

Recorded June 18th 2020 – watch the full episode on YouTube.

Whenever a major Swift feature arrives, folks say "Swift is getting too complex now." What's your response to that?

Chris Lattner: I think that people that say that haven't spent much time with C++ first of all. I have a lot of respect for C++ but let's just say it ain't getting simpler. It's getting way more complicated very quickly which, given where we're starting from, is saying a lot. I think that there's real concerns there and I think that sometimes there's some missed concerns. So I think there is a real concern, right? We need to be careful about how much complexity we put in and we have to look at what does it do to the cognitive ability of Swift programmers to get their jobs done.

"One of the challenges that I see in the Swift Evolution community is that Swift evolution is populated by language geeks, and language geeks they like new things."

One of the challenges that I see in the Swift Evolution community is that it’s populated by language geeks, and language geeks like new things. They like new toys to play with. They like designing language and language-y things. Most users don't necessarily get the same value out of the feature that the designer might look for.

So I think that we have to be very cognizant of that and I think that's one of the things that the Swift core team tries to do in terms of provide long-term governance and long-term vision for the language and try to rein some of that kind of stuff in. So it's definitely not the case that any idea is a good idea. I think that there's an increasingly high bar for certain things.

On the other hand, I think that some of the features, you picked property wrappers, have the potential to simplify the language. So property wrappers, one of the nice things that they do is they make built-in compiler features like lazy accessible to the Swift programmer.

So if we can take hard-coded language features that otherwise are special cases and have to be taught independently and make them accessible and extensible, then you are absolutely making life more complicated but you're also making it more uniform. And so by doing this, you're turning lazy as a language feature into lazy as a library feature and the cost of library features in terms of complexity is just much lower.

I think that the more that we can do that, the more that we can introduce conceptual boulders into the world that then eat up a lot of the gravel that gets spread around. You can kind of consolidate a bunch of loosely held ideas into one thing that then can be explained and with that I think that you can actually get to a simpler language and those are the features that I personally really like to see. It comes back to the control flow statements should be expressions kind of a thing as well. So I think it really depends.

"A lot of the Evolution proposals are standard library enhancements. I think those are really low cost and that's definitely needed. We should have a stronger standard library."

Now, on the other hand, a lot of the Evolution proposals are standard library enhancements. I think those are really low cost and that's definitely needed. We should have a stronger standard library. I think that certain of the features recently are very particular nitpicky little things that don't add a lot of complexity but they clarify certain corners of language. There's this recent proposal about atomics that is talking about the memory consistency model of the programming language and how it interfaces with C code and blah blah blah, like this extremely narrow thing that people who care really care but people who don't don't have to even think about.

So I think that what I would look forward to is a few more of these boulders coming in, so things like concurrency support I think is a pretty big boulder. I think that the types of some enhancements to get move semantics and ownership types in so that we can get lower level programming. I think those are things that will be really important boulders that need to land and then they'll cause a lot of simplification around them.

"Starting over from scratch is great for purity, but it doesn't actually help Swift developers, at least not that much directly."

Paul Hudson: Certainly I remember reading, I think it was Joe Groff, someone asked him if Swift will ever become self-hosting, and his answer was to make the compiler written in Swift he'd want to see more language features added to Swift that would only be really good for compilers. He thought it wouldn't necessarily be a good fit to have that because it would clutter up Swift with compiler-y things. Speaking of language nerds wanting language stuff, well, there's also compiler nerds want compiler-y things in there and he didn't think it was necessarily a good idea. Not ruling it out but, as it stands, it would need things changing.

Chris Lattner: I don't know that I necessarily agree with him. I think that was a huge risk years ago. I think that's less of a risk now, but the concern there is if you have the language implementers and language designers, you're conflating their needs and you're saying, “well, think about how to make implementing the compiler simpler.” You'll get those compiler implementation features in a language that you otherwise wouldn't necessarily add.

So I think that that is more of a concern years ago than it is today perhaps. I think now it's really a question of engineering resources, the trade-off between "let's start over from scratch” versus “let's incrementally add a new thing.” Starting over from scratch is great for purity, but it doesn't actually help Swift developers, at least not that much directly. That's an interesting tension.

Sponsor Hacking with Swift and reach the world's largest Swift community!