If you read that though, it is not something that's a high priority for the team. Basically, 90% of devs won't need or want some of these features. Unless Apple decides to have a focused effort around recoding the core of OS X into Swift which would require these changes, it's hard to see when the language would gain these options.

Don't get me wrong, Swift is an awesome language, but I see Rust as maintaining a position as a systems language equivalent to C. Where Swift will possibly start supplanting Java/Go/C++/Python use cases.

Historically, languages that have tried to move from automatic memory management to opt-in manual memory management haven't had a lot of success in doing so. Java direct buffers don't let you do anything more than simple flat heap allocations, and you can't really get away from GC. D hasn't been able to shed a practical dependency on the GC, despite years and years of work. There was some early work to try to use Go in places where GC isn't acceptable, but in practice you can't really avoid it. And so on.

Interestingly, the reverse is also true. C++ does not make very good managed language: despite the occasional claim to the contrary, the lack of memory safety and the library ecosystem mean you can't just use shared_ptr "for everything" and forget about memory management in practice. Rust is also in a similar situation: borrowing is front and center, and the language doesn't really try to make managed programming palatable: you have to explicitly clone reference counted pointers, and you need Cell/RefCell if you want to mutate their contents.

A lot of this has to do with the library ecosystem. Even if the language supports manual memory management, if the package ecosystem doesn't you can't really program with it in practice. I don't know of any language (with one possible exception below) that has effectively subdivided its package landscape into managed and unmanaged ecosystems.

Objective-C is probably one of the few exceptions where you can really mix and match the two worlds. That's because there are effectively two library ecosystems: the C/C++ ecosystem on one hand, and the native Objective-C system on the other. It's a special case because Objective-C/Objective-C++ basically mashes two popular languages together while maintaining full compatibility with the existing C/C++ library landscape. I don't know if you can replicate this without source-level C and C++ compatibility (which Swift drops).

The upshot of this, in my mind, is that assuming history repeats itself, multiple languages are probably going to thrive. There won't be one language to rule them all, and large software stacks will mostly continue to consist of components written in multiple languages. Which is, of course, great for us compiler developers, and programming language innovation in general. :)

I get your points, and they're totally valid criticisms of Rust, but I see them as learning curve issues as opposed to oppressive things that are incompatible with certain development practices.

In C it's easy to pick up the language, but to manage memory properly is very hard, if not complely unclear in certain cases, C++ is similar.

Rust does have direct support for exposing FFI from C quickly in both directions. Objective-C while it could easily incorporate C, it is not easy to go the other direction because of the runtime requirements. The safety of Rust requires learning some patterns to develop properly, but is quite honestly amazing in terms of the guarantees you get.

I'm not criticizing Rust. I'm on the Rust core team and I think it's the best choice out there if you want or need the performance that low-level systems programming offers. In particular, I think it's pretty much an unmitigated improvement over C++. ;)

I just happen to like dynamic languages too, as well as managed languages like Swift.

Then I guess we're in total agreement ;)

As someone that would like to see C replaced by something better and has always been a fan for Wirth influenced languages, Swift has actually a better position to achieve that than Rust.

The reason being that Apple, like it happened to OS vendors that adopted C and later C++, can allow themselves to push the language into the developers regardless of what they think they should use.

All the systems languages that have survived in the mainstream, have done so by being adopted by an OS vendor.

Apple isn't going to stop supporting C and C++ on their platforms, so it can't "push" Swift at the systems level the same way it can push Swift at the application level on iOS.

I also disagree with your repeated claims that systems languages can only survive when they are pushed by an OS vendor. C and C++ dominate for a host of historical reasons (which I'm sure you're well acquainted with). Meanwhile, Rust, at a low level, is such a transparent skin over C and C++'s low-level semantics that it can almost be considered an alternate syntax for those languages (albeit an alternate syntax with extreme static analyzability).

The takeaway should not be "systems languages only succeed when pushed by an OS vendor", it should be "programming languages tend to succeed when backed by a large corporate vendor and when they are used to write widely-used software that people come to rely on". Swift is guaranteed a bright future by dint of being the application programming language of choice for iOS. Rust's long-term fate likely hinges on Servo, but it's too soon to say whether that's the only large project that has a chance of entrenching Rust (give it six more months at least to see what nascent Rust projects are gathering in the post-1.0 calm).

> I also disagree with your repeated claims that systems languages can only survive when they are pushed by an OS vendor.

I was there when Assembly was the only viable choice for targeting home computers, so excuse me if my life experience has made be a bit biased.

So when I see Apple going with Swift, Google and Microsoft pimping up C++ and contributing to the C++ Core Guidelines, I get a deja-vu feeling.

I hope that Rust does get adoption, that killer feature project that blows wind into its sails.

  > excuse me if my life experience has made be a bit biased.

I appreciate the breadth of your experience, but I think that you're overlooking the context of modern systems languages. :) The systems languages of old were wedded to their intended operating systems (indeed, the motivating product was usually the OS itself, with the language being but a necessary feature (Unix/C is no exception here)). As history ran its course and those OSes fell by the wayside, those languages were naturally marginalized (did there even exist usable Mesa/Modula-2/etc. compilers for Unix?).

Rust is different because it is not beholden to the fate of any single operating system. Not only is it cross-platform by intent, it has hitched its cart to a world-class retargetable backend for the dominant systems languages of today, meaning that platform availability will never be a problem.

There are still plenty of reasons why Rust could fail, of course. But Rust does not require the OS vendors' permission to exist on their platforms (well, except for on non-jailbroken iOS, anyway), and the Rust devs are not especially concerned with those platforms integrating Rust into their kernels (though I'm sure they wouldn't mind).

Out of interest, in what way do you consider Swift a Wirth-influenced language?

Go seems a closer cousin to Wirth's languages. Its strict type coercion, value copying semantics, package system, lack of OO, use of ":=", type declarations with "type", "var", GC, colons, etc. are all reminiscent of Wirth's languages, especially Oberon. (Robert Griesemer worked with Oberon under Wirth at ETH Zürick, so there's a clear relationship.)

Another highly wirthian language is Nim, though its influence comes via Delphi/ObjectPascal.

> Out of interest, in what way do you consider Swift a Wirth-influenced language?

In the context that system programming languages shouldn't sacrifice safety, except when needed and be explicit about it with constructs like unsafe/SYSTEM and so on.

Swift is very explicit when doing C style tricks, e.g. UnsafePointer<>.

There is more to Wirth school of languages than just syntax.

The only "safe" Wirth language I know about is Oberon-2, which has bounds-checking of arrays, sentinels and runtime-checking of pointers — though no compile-time checking. Is this what you're referring to?

I like Wirth, but his type systems were always super simple, and as far as I know, he never innovated at compile time safety in the way that, say, Rust or Haskell do. Again, Go seems a better analogue; anything that needs to deal with unsafe pointers needs to use the "unsafe" package.

Not sure what you mean with runtime-compile time checking of pointers.

Wirth type systems weren't always super simple, not when compared with C style ones.

Wirth has designed Pascal, Modula-2, Oberon, Oberon-2, Active Oberon and Oberon-07

He has contributed to Extended Pascal, Object Pascal, Component Pascal.

Also worked on Algol compilers and some of its dialects, Mesa and Cedar while at Xerox PARC.

His work had an influence in Ada, Modula-2+ and Modula-3.

Some of the type safe things that Modula-2 in 1978 already offered, that C still doesn't do today:

- Type safe enumerations

- Bounded checked arrays

- Arrays indexed by enumerations

- Type safe sets

- Range typed integers

- No implicit conversions

- reference parameters instead of pointers for function/procedure calls

- tagged records

- low level coding/assembly intrisics require use of the SYSTEM package

The only thing lacking was automatic memory management, which we later introduced in the Oberon family.

However as you can see from the list there are a whole class of errors that aren't possible.

If you like to research old stuff, have a look at B5000 system, which used Algol as their system programming language in 1961.

Common to his languages and Xerox PARC ones, was the idea that you can do systems programming in higher level languages, provided the language provided some unsafe path that needs to be explicitly mentioned.

But type safety should precede "performance at any cost" mantra.

Something also mentioned by Hoare on his ACM Award speech in relation to Algol in 1980.

"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interest of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law. "

The problem is that younger devs never learned any of this and probably the only thing they know about Wirth languages is some braindead Pascal compiler.

Oberon-2 had runtime-checking of pointers: It could check the validity of a pointer and immediately panic rather than return garbage or crash with a page fault. Similarly with arrays.

Wirth did some nice things with type safety, of course (I've always liked his type-safe set/range types), but he never was much into type systems. For example, his set and range types were hardwired into the language; you couldn't build a set-like type yourself, or build something that acted as a range, or overload any of the standard function such as inc() or min(), or indeed any type coercion. With the exception of Oberon-2's (limited and highly Go-like) notion of abstract classes, nothing was polymorphic, every type was only "itself" and their purpose was always entirely about holding data. This is what I mean by his type systems always being "simple". He was attacking practical engineering problems, not type-theory problems.

Go is exactly the same. Swift isn't; it has generics and sum types and protocols and OO and pattern matching and lambdas and a bunch of other stuff that Wirth would probably find too complex (his last few languages tended towards mercilessly removing features).

I don't disagree that Wirth's languages are more advanced than C, though!

> Oberon-2 had runtime-checking of pointers: It could check the validity of a pointer and immediately panic rather than return garbage or crash with a page fault. Similarly with arrays.

Ah, but this was a property of any sane systems programming language with automatic memory management.

> With the exception of Oberon-2's ....

How well do you know Active Oberon, Zonnon and Component Pascal?

They extend Oberon(-2) with abstract classes, generics, tasks (active objects), type extensions, method definition signatures.

Also many consider his work as influence in Ada and Modula-2 successors, whose type systems are not very far from C++ ones.

Incidentally he became disillusioned with these language variants and went with a minimalist view (Oberon-07) that makes even Go look like a complex type system.

Sure, Active Oberon is pretty advanced, and Modula-3 had all sorts of things, including generics — but to my knowledge Wirth was not directly in those languages (or with Zonnon or Component Pascal), and he was unhappy with their complexity. (He apparently prefers the entire language's grammar to fit on a single screen.)

> in what way do you consider Swift a Wirth-influenced language?

It looks to me you misunderstood the post.

How so? He wrote: "As someone that [...] has always been a fan for Wirth influenced languages, Swift [is in a better position]." Why is the sentence premised on Wirth, if it's unrelated to Swift?

Because Wirth designed/influenced languages for system programming that I consider better than C.

Algol, Mesa, Object Pascal, Modula-2, Modula-3, Oberon, Oberon-2, Active Oberon, Oberon-07, Ada

All of them were used to write full operating systems for a few years.

However, except for Ada, all of them suffered from not being adopted by OS vendors that were able to deliver mainstream OS, as mainstream OS vendors adopted C to replace Assembly (Object Pascal on Apple's case) and eventually C++.