Author of Swift Language Chris Lattner is Leaving Apple; We're Interviewing Him (Ask a Question!) (swift.org)

Software developer Chris Lattner, who is the main author of LLVM as well as Apple's Swift programming language, is leaving Apple, he said today. From a post: When we made Swift open source and launched Swift.org we put a lot of effort into defining a strong community structure. This structure has enabled Apple and the amazingly vibrant Swift community to work together to evolve Swift into a powerful, mature language powering software used by hundreds of millions of people. I'm happy to announce that Ted Kremenek will be taking over for me as "Project Lead" for the Swift project, managing the administrative and leadership responsibility for Swift.org. This recognizes the incredible effort he has already been putting into the project, and reflects a decision I've made to leave Apple later this month to pursue an opportunity in another space. We're delighted to share that we are interviewing Lattner, who says he's a "long-time reader/fan of Slashdot." Please leave your question in the comments section. Lattner says he'll talk about "open source (llvm/clang/swift/etc) or personal topics," but has requested that we do not ask him about Apple, which is understandable.

Update: Lattner is joining Tesla.

Comments

C#

[Anonymous Coward]

What do you think about Microsoft and C# versus the merits of Swift?

Why are strings passed by value?

[Anonymous Coward]

Strings are immutable pass-by-reference objects in most modern languages. Why did you make this decision?

How much of Swift is Based on Groovy?

[Anonymous Coward]

Its been commented on that Swift tutorials look IDENTICAL to Groovy tutorials to the point that you even use the same variable names in examples (http://glaforge.appspot.com/article/apple-s-swift-programming-language-inspired-by-groovy). When created a Python to Swift converter, I responded 'wouldn't it have been easier to do a 'Swift to Groovy' converter??? To which developers replied, well naturally.

So how much of Swift was inspired by Groovy? Both come from more high-end language and look and act almost identical.

What hardware is used for workstations at apple?

[Joe_Dragon]

What hardware is used for workstations at apple?

Mac pro's?

Mac pro's with non apple cpu upgrades?

Imac's?

Laptops?

Exception Handling

[andywest]

Why did Swift NOT have exception handling in the first couple of versions?

as a language designer

[superwiz]

Since you have been involved with 2 lauded languages, you are in a good position to answer the following question: "are modern languages forced to rely on language run-time to compensate for the facilities lacking in modern operating systems?" In other words, have the languages tried to compensate for the fact that there are no new OS-level light-weight paradigms to take advantage of multi-core processors?

Future of LLVM?

[mveloso]

Where do you see LLVM going?

Does this mean Xamarin won?

[xxxJonBoyxxx]

Does this mean the Visual Studio based "write once run anywhere" encapsulated in microsoft xamarin won?

What are Rust's prospects like?

[Anonymous Coward]

C# is well-established, and Microsoft has shown that it's very willing to adapt C# as necessary to support new techniques. I wouldn't be surprised at all if C# inherited good ideas from Swift.

I'm more interested in what Chris has to say about Rust, another much-newer language that's much closer in age to Swift, but also different from established languages like C#, C++ and Java.

Chris, what are your general thoughts about Rust as a programming language?

Seeing as it fits somewhere between languages like C++ and Swift/Go/C#/Java, some programmers find it to be impractical and ill-positioned. While it did get a huge amount of hype at various programming discussion forums in the recent past, a lot of this has died off, perhaps because of people becoming disillusioned with it.

What do you think its prospects for the future are like?

While a language like Swift has the backing of Apple, and Go has the backing of Google, and C# has the backing of Microsoft, do you think that Rust being backed by a much smaller and perhaps less-resilient organization (Mozilla) is a liability that should discourage the use of Rust for serious, long-term software projects?

Also, while Swift has a very reasonable code of conduct, what are your thoughts about Rust's community, including its rather extreme focus on its code of conduct? Some people, even those who support strict codes of conduct, see Rust's as being tyrannical. Within the Rust community, it's almost like social causes are considered more important than programming or software development. What are your thoughts about the unusual control that the Rust project tries to exert over its community?

Thank you for your time, Chris, and thank you so much for the awesome contributions you've made to LLVM, Clang and Swift!

Parallelism

[bill_mcgonigle]

Say, about fifteen years ago, there was huge buzz about how languages and compilers were going to take care of the "Moore's Law Problem" by automating the parallelism of every task that could be broken up. With single-static assignment trees and the like the programmer was going to be freed from manually doing the parallelism.

With manufacturers starting to turn out 32- and 64-core chips, I'm wondering how well did we did on that front. I don't see a ton of software automatically not pegging a core on my CPU's. The ones that aren't quite as bad are mostly just doing a fork() in 2017. Did we get anywhere? Are we almost there? Is software just not compiled right now? Did it turn out to be harder than expected? Were languages not up to the task? Is hardware (e.g. memory access architectures) insufficient? Was the possibility oversold in the first place?

Re:Parallelism

[johannesg]

I did some work on parallelizing FORTRAN in the nineties. It never went very far; our parallelizing compiler ran out of swap space when you fed it anything larger than a twenty-line program. Not that swap space was all that big in those days, but it was clearly not useful in a real-world context. There were some good ideas, but also a great many realities that tended to break those good ideas.

Today I'd say, but this is after not looking at it very almost two decades, that the granularity at which the compiler is able to work is too fine; parallelism works better when you have larger chunks of work to deal with, which is still very much a programmer job. And at those fine granularities, dependencies (not to mention Amdahl's law) kill your efforts at parallelization.

So, in my opinion, it was oversold in the first place, and it turned out to be much harder than expected. But it sure sold those research grants...

Any insight into language design choices?

[EMB Numbers]

I am a 25+ year Objective-C programmer and among other topics, I teach "Mobile App Development" and "Comparative Languages" at a university.

I confess to being perplexed by some Swift language design decisions. For example,

- Why does Swift have both a "var" keyword and a "let" keyword? One should be sufficient with the other being a default behavior. If a symbol is not declared "var" then just assume it is constant or visa versa. Furthermore, it may not be necessary to have either of the key words because (I think) in every case, the need for variability and mutation should be determinable by the compiler. Type is already being inferred by the compiler, and mutability could reasonably be considered an aspect of type.

- Why are Swift collection types like Data always mutable? What happened to the concept of immutable containers from Cocoa. [Yes, I know the "bridged" CF types are always mutable, but that was another bad decision IMHO.]

- Swift is intended to be a "Systems Programming Language", is it not? Yet, there is no support for "volatile" variables needed to support fundamental "system" features like direct memory access from peripheral hardware.

- Having experienced frustration trying to port high performance graphics code from C/C++/Objective C to Swift, what's up with that? IMHO, Apple's sample code for using OpenGL/GLKit/Metal from Swift leaves the impression that Swift is unsuited to the style of "low level" programming needed/used by OpenGL/GLKit/Metal.

- Why not support "dynamic runtime features" like the ones provided by the Objective-C language and runtime? It's partly a trick question because Swift is remarkably "dynamic" through use of closures and other features, but why not go "all the way?"

- Finally, a trivial aesthetic critique: Why "var foo : typename" like Ada and Pascal (IIRC) instead of "var typename foo" like every language that inherited C style syntax? Is there an advantage to the Swift approach that I haven't seen, or was it just an aesthetic choice? Did the choice not produce some IMHO "silly" syntax for method declarations with named parameters?

Questions, and my best wishes.

[Volanin]

Since you're the creator of LLVM, I'd like to know, in your opinion what's the greatest advantage of LLVM/Clang over the tradicional and established GNU GCC compiler. Also, what's the greatest advantage of GNU GCC (or if you'd prefer, any other compiler) over LLVM/Clang, something that you'd like to "port" someday?

Also, since I work mostly with Linux development, what do you see as the greatest advantages of the Apple developer stack (libraries, xcode, etc) that are sorely lacking in the Linux developing scene, that we should strive to copy/implement?

By the way, and unrelated, congratulations on the Walnut Dining Table you made. It's amazing!
https://twitter.com/clattner_l...

How much of Swift is based on Groovy?

[Foofoobar]

Its been commented on that Swift tutorials look IDENTICAL to Groovy tutorials to the point that you even use the same variable names in examples (http://glaforge.appspot.com/article/apple-s-swift-programming-language-inspired-by-groovy). When created a Python to Swift converter, I responded 'wouldn't it have been easier to do a 'Swift to Groovy' converter??? To which developers replied, well naturally. So how much of Swift was inspired by Groovy? Both come from more high-end language and look and act almost identical.

The Mythical Compiler -VLIW

[Anonymous Coward]

Is there any hope for VLIW architectures? The general consensus seems to be that Itanium tanked because the compiler technology wasn't able to make the leap needed. Linus complained about the Itanium ISA exposing the pipelines to assembly developers. What are the challenges from a compiler writers perspective with VLIW?

Re:Swift libraries

[dgatwood]

Flaws in shared libraries can't enable privilege escalation in any operating system that I'm aware of except possibly some of those really old, pre-MMU mainframe operating systems. In modern OSes, shared library code runs in the same environment privilege-wise as the rest of the code in the app.

In fact, quite the opposite. Copying libraries introduces one of Windows's key security flaws: Any exploitable bug in a shared library is only truly fixed after every single app that provides a copy of that library gets updated to include a new version of that library. From a security perspective, providing multiple copies of a framework or library is generally seen as very, very bad.

Of course, the reason for it in this case was that the library was evolving quickly, and apps would get built against different versions. By including it in the app, you can run apps compiled against newer versions of the Swift library on older versions of the OS that lacked that version (or any version) of the library. IMO, what's really needed is a systemwide mechanism for downloading updated versions of these shared libraries in such a way that they get automatically kept up-to-date, but that's a much more complex solution than just including a copy of the framework in each app. Alternatively, I'd settle for block-level deduplication in iOS, but again....

Perhaps now that things have settled down a bit, they can move it into /S/L/Frameworks.