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.
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.
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.
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!
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.
It looks to me you misunderstood the post.
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++.
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.