Hacker News Reader

Comment by skohan | Hacker News Reader

> It is obvious that Swift has outgrown my influence, and some of the design premises I care about (e.g. "simple things that compose")

As someone who was heavily invested in Swift, and an active member of the community from around 2015-2019, I'm a bit sad to see the direction the language is taking.

From the time I started experimenting with Swift, I absolutely loved the philosophy of the language. It seemed to really prioritize having a set of well-factored systems, each with their own very rationally designed interfaces, which could be composed to do really powerful things. It was an incredibly expressive language which allowed for writing code with an incredible level of clarity - when writing Swift code I always felt I was writing at the level of the problem domain, not writing syntax. At the same time it offered really nice features for ensuring safety and correctness, like ADT's and best-in-class nullability syntax.

It was a language which sometimes seemed to move at a glacial pace, but the implicit tradeoff was that when a feature landed, it was for the most part very well thought out, and would add to the language with minimal negative impact.

A few years ago that seemed to start to change. From my perspective, some of the features added to the language to support SwiftUI - specifically property wrappers and function builders - very much felt rushed and forced into the language based on external deadlines. And imo they have a largely negative impact on the language: it used to be the case that you could look at a piece of Swift code and roughly understand how it would compile to assembly pretty easily, but with these new features there's a ton of compiler magic going on behind the scenes.

View on HN

Languages not ruled by a BDFL are subject to every team member wanting to get their pet feature in, motivated by ego, fame, and career.

This happens with all corporate software, as people compete to (for instance) foist their new videoconference system into your calendar flow. That's sort of tolerable for end-user software, but horrible for programming languages where feature-feature interactions grow as N^2.

In the special case of Swift, with it being the language of choice for iOS development, I imagine a lot of people at Apple also want to have a word to say about the direction of development.

One notable remaining exception to this trend is Go. They are committed to the "simplicity" mantra and so far they have stuck to carefully weighing and discussing any feature added to the language. I know that some consider it too simple and the "glacial" pace of development not exciting enough, but I personally appreciate it...

Go has Rob Pike as a sort of BDFL within google, no?

Apple it seems does well w/ a Scott Forstal or a Bertrand Serlet running cover for their engineers. maybe not so much if there's a giant committtee....

The idea and most of the initial development was by Pike, Ken Thompson and Robert Griesemer, and their explanation for the simplicity of the language was that no feature was included unless all three of them could agree it was necessary. Thompson has since retired, others have joined the "core team", and Pike doesn't seem to be that active anymore in terms of actual commits - however he may still have an active role in guiding the development, I'm not following the development that closely, so I can't tell. But the way I understand it, it's more of a team effort than a BDFL situation...

"Benevolent junta," maybe.

>Apple it seems does well w/ a Scott Forstall or a Bertrand Serlet

And before that Avie Tevanian.

After that it was Craig Federighi. And I dont like the decisions and directions since then to say the very least.

Sometimes I still think about Bertrand Serlet leaving, the year that Steve passed away or 6 months after Steve took leave of absence. I wonder if he saw what was coming and simply decided it was time to leave.

Sometimes I wonder if Craig finds it harder to say "no" more and put his foot down. And his priorities, for better or for worse, seem to be on developing new features vs. fixing bugs/robustness. Granted, he's had to oversee the forking of OS X into 3 active branches now (iOS, iPad, Mac), a processor transition, etc etc.

And this is pure kremlinology at this point, but I feel like Apple Music, at least the client part, has to go back under Craig and not Eddy....

Rob Pike is retiring, or perhaps already retired.

I totally agree. That’s why I’m completely pro the BDFL model. Committees don’t produce good products.

The BDFL model has its own flaws, primarily with longevity and succession - the fl - plenty of examples where the lead got bored, retired or went on their own path. Let alone how they deal with criticism and review (constructive or otherwise).

Committees work when they have a shared vision, and a base strong enough to keep them on that path.

It’s clear from Lattner’s statement that Apple have moved that vision, have not brought the group along with that change and the result is wasted effort and a passive aggressive approach.

I would posit that rather than operate as a committee, instead that leadership is being exercised by a limited few and the structure is being retained as a fig-leaf :(

Isn't it the fate of all programming languages? they start on clean foundation, only to evolve in a bazaar of features.

Excuse Me Sir, Do You Have a Moment to Talk About O̶u̶r̶ ̶L̶o̶r̶d̶ ̶a̶n̶d̶ ̶S̶a̶v̶i̶o̶r̶ Lua?

In its 27th year of life, Lua introduced integers (in 5.3).

An interesting fact that could legitimately be used by both sides of this debate. :)

the language so 'clean' it doesn't include array.len()

C seems ok no?

YMMV, but to me, C is a great example of a language that absolutely could stand for a few more features.

I would almost never write C++ (in the context of low level and performance-relevant code; I write a lot of things for a lot of stuff) if the type system was a touch more rigorous (why can't I specify, and have the compiler yell at me if I don't properly handle, "this pointer may never be null"? TypeScript can do this kind of type narrowing in its sleep!) and if error handling/lifecycle cleanup wasn't hazardous (I'm not even saying exceptions and try-catch, just make it easier to guarantee that a cleanup clause gets called when leaving scope, like Ruby's def-ensure-end).

As it is, whenever I finally hit the breaking point with C++ (which I write mostly from inertia because I know it pretty well) it's probably Rust for me.

That's exactly why Zig is such an interesting language to me. The premise of trying to write a modern C replacement - essentially what C would be if it were designed with the learnings of the past 40 years in mind - is super exciting.

I am a fan of Rust, but I am not 100% sold on it. The safety features and ADT's are nice, but I find it quite clunky in practice, and it is just such a huge language full of so many features. It almost feels more like a test language to try the concept of static memory management than a properly designed language in some ways.

I feel it's missing the quality from C/C++ that they are a very thin abstraction over assembly.

I haven't looked at Zig much because I mostly noodle with lower-level languages with an eye towards game prototypes and the like, so I don't know much about it. Have anything you'd recommend reading about the language?

I like Zig because it feels like a refinement of C with all the knowledge of the years since C was created. Some of my favorite features are no global allocator, well-defined pointers (with optionals required for nullability), generics and partial evaluation at compile-time, and builtin features/functions for all sorts of operations that are only extensions in C/C++ like SIMD and packed structs.

Read [0] for a comparison among Zig, D, Rust, and C++, and read [1] for a deeper look at the language's goals. I personally really love Zig's type system [2], with a system for generics that is very simple and consistent.

[0]: https://ziglang.org/learn/why_zig_rust_d_cpp/

[1]: https://ziglang.org/learn/overview/

[2]: https://nathancraddock.com/blog/consistency-in-zigs-type-sys...

I'm going to give those a read. Thanks!

I've always understood that C was designed to fit a hardware budget.

We knew about many of these features then, when C was created - but it wasn't until the 2000's really where computing horsepower caught up to be able to use them in a universal way.

Hmm I've always thought of C in terms of "portable assembly". Not so much that features were omitted because they weren't performant enough, but because they strayed too far away from machine-primitive operations.

C itself is pretty far from the machine, too, except by accident.

Some of them would have been great even on 70s hardware. Proper array, slice and string types come to mind.

> a very thin abstraction over assembly.

I think this statement implies that it’s clear and obvious what assembly will be generated from a snippet of C/C++ code. But few people can understand everything that optimising compilers and modern processors do to normal looking code. An example of this lack of knowledge is seeing people disagree on if a snippet contains UB or not.

If C is so simple, why do people struggle to write it?

> But few people can understand everything that optimising compilers and modern processors do to normal looking code.

Well when I'm talking about an abstraction over assembly I'm not talking about optimizing compilers. That's another topic entirely. What I mean is, if you look at a block of C code, it's very easy to understand what the machine is doing.

> If C is so simple, why do people struggle to write it?

Do they? I think people struggle to write correct, bug-free code in C, but that's because it doesn't save you from yourself, and it's happy to let you do whatever the hardware will do. That's a much larger programmable space than the set of all safe correct programs.

But I don't think people in general have difficulty looking at a snippet of C code and understanding it.

> What I mean is, if you look at a block of C code, it's very easy to understand what the machine is doing.

So they simultaneously understand what the machine is doing but don’t know what assembly will be generated? Both can’t be true.

If everyone understood what the machine was doing, everyone would be able to look at a snippet and agree - “that’s UB, let’s not do that”. But they can’t agree. Because few people understand what the compiler and the processor will do.

The “thin layer of assembly” was true for the first generation of C compilers. But it hasn’t been true for a long time. It’s a complete black box now. Anyone who thinks that it’s straightforward isn’t being upfront with themselves.

> So they simultaneously understand what the machine is doing but don’t know what assembly will be generated? Both can’t be true.

I mean I can understand a reasonable mapping to what the un-optimized assembly would be. Compiler optimization is very complex, and is going to obscure the results in every language.

> If everyone understood what the machine was doing, everyone would be able to look at a snippet and agree - “that’s UB, let’s not do that”. But they can’t agree. Because few people understand what the compiler and the processor will do.

What? I think everyone can agree that UB is much harder to detect in assembly than in higher level languages than assembly, and assembly gives the most clear view of what the machine is doing. It's a very complex topic to create a system which detects and disallows UB automatically in the compiler - this requires a lot more complexity than a simple mapping of high level instructions to machine instructions.

> The “thin layer of assembly” was true for the first generation of C compilers. But it hasn’t been true for a long time. It’s a complete black box now. Anyone who thinks that it’s straightforward isn’t being upfront with themselves.

I don't know, seems pretty straightforward to me: https://godbolt.org

Let me rephrase. You say C is simple. I say Rust (for example) is simple. I can look at a Rust code base and say confidently - this code base has no UB in it, it has no memory safety issues in it.

Can you look at a non trivial C code base and make such an assertion? You can’t. Even simple looking C code could be translated into problematic assembly because such a transformation is technically valid. And it’s beyond the ability of anyone but an expert to guard against that.

C is a very useful language. Very important. Very fast. A great tool in the right hands. The world wouldn’t run without it. And it will remain useful and important and fast for decades to come, certainly. But it’s not simple and hasn’t been for a long time. Let’s acknowledge that.

I'm sorry I don't understand your argument at all. What does lack of UB and memory safety have to do with simplicity? Those are very complex features of Rust which require a very complex compiler in order to achieve. Also Rust is notorious for having a steep learning curve, and it takes time for even very experienced programmers to become accustomed to it.

> a thin abstraction over assembly

Do you agree that this statement implies 2 things

1. The compiler isn’t doing anything unusual or unexpected. It applies only basic, easily understandable transformations from C to assembly

2. An intermediate C programmer would be able to guess correctly most of the time what the generated assembly would look like. And thanks to this, such a programmer would be able to avoid most footguns.

But the compiler does unusual/unexpected things, and it’s hard to guess what assembly will be generated or what that assembly does, it’s not a “thin abstraction”. Would you agree?

I don't think this is the best way to understand this. C has been around for 50 years at this point, and there has been an enormous amount of investment and advancement in the realm of C compilers in that time, which has naturally resulted in complexity and esotericism in terms of how actual mainstream C compilers work. But that's not a metric of language complexity, it's an artifact of a half century of work on the topic.

I think a better metric is: an average CS grad with a little bit of background in compilers and assembly could reasonably be expected to be able to write a naive C compiler which covers say 80% of the footprint of the core language on their own in a matter of weeks.

What do you think is the size of the cohort of people who could write a naive Rust compiler, with borrow checking, ADT's, traits and non-lexical lifetimes? Even without some of the fancy bits like async you're already talking about grad level CS topics at the very least.

C and C++ are not a very thin abstraction over assembly language. The C virtual machine is very far from the actual hardware. And Rust is the same distance from the hardware as C and C++ are. Rust's core operations are, by and large, the same simple mapping to LLVM instructions.

I don't find the idea of a new non-memory-safe C replacement in 2022 very exciting. We should be moving away as an industry from non-memory-safe languages, for the obvious security and productivity reasons.

I don't see how you could argue that C is comparable in terms of level of abstraction to Rust and C++. For instance with Rust memory management is totally abstracted away from you as the programmer, which is a core part of what a computer is doing.

And if you index into an array in C, that's basically like saying `root memory location + stride * index`. In Rust it's calling a trait function which could be doing arbitrary work.

Rust and C++ are on similar levels of abstraction, but C is much, much simpler.

How is Rust memory management totally abstracted away from you? You have to opt in to every heap allocation, just as you have to call malloc() in C.

And it's certainly true that Rust has overloading and C doesn't, but that wasn't what I was getting at. The point is that C is defined in terms of the C virtual machine, not the underlying hardware. The C virtual machine is quite far from the actual CPU instructions.

In Rust you opt into every heap allocation with an abstraction like Rc, Arc, Box etc. With C you would have to implement each of those behaviors with primitives, because C is at a lower level of abstraction than Rust.

malloc is also an abstraction.

I never said C is without abstraction, only that it is a relatively thin abstraction. Are you seriously arguing that Rust is not at a higher level of abstraction than C?

> Are you seriously arguing that Rust is not at a higher level of abstraction than C?

Rust is clearly not at a higher level of abstraction than C++, yet in your own argument you've put C and C++ on the same ground…

No I haven't. I said Rust and C++ are on similar levels of abstraction.

Yet a few comments above in this thread[1]:

> I feel it's missing the quality from C/C++ that they are a very thin abstraction over assembly.

[1]: https://news.ycombinator.com/item?id=30419248

I also said this:

> Rust and C++ are on similar levels of abstraction, but C is much, much simpler.

How is that different from C++? Since you've explicitly put C and C++ in the same basket, this argument doesn't hold any water…

It sees like you're trying to catch me with some kind of gotcha instead of dealing with the argument in good faith.

> C and C++ are not a very thin abstraction over assembly language

We can argue the thinkness (or the thinness) of the abstraction until cows come home, but

  while (*dst++ = *src++) ;

is a direct abstraction over

  L1:
    movb @(r0)+, @(r1)+
    tstb (r0)
    bne L1

(assuming «src» and «dst» are both «char *» and addresses are loaded into «r1» and «r0» registers, consequently) in the PDP-11 architecture that C was designed on and for. The instruction sequence is exactly 4x 16 bit words long. As well as

  *ptr &= 1;

becoming

  and #1, (r0)

and being 2x 16 bit word instruction (assuming «ptr» is an «int *» and is loaded into «r0»). Pointer arithmetic and array design in C as we know them today was highly influenced by the addressing modes existing in the PDP-11 ISA, with many C abstractions having to a direct correspondence to specific sequences of PDP-11 instructions.

C++ is much less of a hardware abstraction, specifically when it comes to the higher level language features.

Except that breaks outside non PDP-11 CPU, where many languages offer the same "low level" capabilities of C.

Or 8 bit CPUs like 6502 and Z80 that aren't even able to fully support C.

6502 and Z80 had not existed yet when C was begot for the PDP-11 architecture.

Yes – historically – C has never been a perfect fit for 8-bit architectures as it had been conceived for a 16-bit architecture. So what? There are C compilers for 68HC08 68HC11 MCU's as well.

Yet, C has outlived «many languages offering the same "low level" capabilities of C».

The reasons for its survival cross many axis, it wasn't just for the language alone on its own.

It really was an elegant instruction set.

You mean the learnings of Modula-2 in 1978, but with a C like syntax?

Clang has a nullability extension and associated nullability sanitizer: https://clang.llvm.org/docs/AttributeReference.html#nullabil...

Yep! And it's great where you've got it, but the world is not Clang. :(

>why can't I specify, and have the compiler yell at me if I don't properly handle, "this pointer may never be null"

You can do so easily. A reference is a pointer that is never null.

C++ isn't C.

The GP was referring to C++

>I would almost never write C++ …

Edit: nevermind, I missed the point! GP is saying he wouldn’t write C++ if C supported these features.

> A reference is a pointer that is never null.

This isn't even theoretically true:

    void blah(int &x) { x++; }

    int main() {
      int *x = NULL;
      blah(*x);
    }

You can definitely write a smart pointer that more or less provides some kind of guarantee about this (with a combo of runtime checks and typefoo) but references only provide a guarantee that they are not statically initializable to null, which is very different.

Compilers are free to assume x is non-null at the time it’s dereferenced, so isn’t it true by definition? Do you have an example that doesn’t rely on undefined behavior?

"Compilers are free to assume" is a fine thing for like, a loop, but the compiler isn't free to assume you didn't mean to dereference the reference in the code snippet I posted, it's just free to not check before it does.

So it will crash, whether that's undefined behaviour or not. The thing at issue here is that other languages have reference types that are more strictly statically guaranteed to be non-null. My point is that references are not a substitute for those, because holding them wrong is not only easy, it's extremely likely to happen in code of any reasonable complixity that mixes pointers and references (ie. almost all production C++ code).

C begins to increase rate of adding breaking changes.

C23 is about to

- add keywords that was valid identifiers before

- remove K&R parameter syntax

- change semantics of the most popular function argument list declaration

- forbid representations other than 2's complement

https://news.ycombinator.com/item?id=30395016

What new keywords? Everything new goes into the reserved namespace with macros to look like the C++ versions.

The over adherence to bloat in the name of backwards compatibility holds the language back - these are incredibly conservative changes that reflect practices which have already been used for decades!

As much as I hate some aspects of C, I also love it. I love it because the committees are so slow and conservative, I'm sure I can write in C89 now, I can write in C89 in ten years' time, and I don't need to care about new features someone might add or not.

You can call it a moot point since the amount of what you can do in pure C today is very limited - you have to use at least a few libraries to do anything remotely useful even on very light systems, but in today's fast developing tech world it's one of these things that really stand out.

> As much as I hate some aspects of C, I also love it. I love it because the committees are so slow and conservative

You might find this an interesting perspective:

https://news.ycombinator.com/item?id=30404636

For what it's worth, I find it remarkable what you actually can do with C with just a few libraries. For instance it's entirely possible to write a simple video game in pure C with a few well-chosen libraries for things like audio and asset loading.

There's just so much prior art out there.

Naturally the libraries for audio and asset loading aren't pure C, unless I missed some chapters on ISO C document.

That's why you keep your language small like clojure.

That's generally the fate of all complex systems.

"avoid success at all costs" — Haskell does it right.

Having a core language helps a lot too. E.g. I don't expect Rust to go off the rails.

Kind of, I lost count of how many extensions exist currently, and some of them are incompatible.

Fair. What remains to be seen is whether the political will to delete outmoded extensions exists.

I neither expect Rust to go off the rails, but the Core developer team drama lately and Mozilla stepping away makes it that I will neither be surprised in the even that it does.

The Mozilla/Facebook partnership makes me glad they have distanced themselves from the Rust. Obviously not a lot of good judgement happening at Mozilla.

I am mostly a fan of Rust, but it's made some missteps in its evolution imo.

For instance sync rust is mostly nice to work with, but async is another story entirely. I have the impression that it was somewhat rushed into the language due to community demand, but it's not really a fully solved problem.

>async was somewhat rushed into [Rust]

My understanding is this is a FUD meme that has been passed around. Async isn't finished yet, but was debated for years and considered with incredible care and input from the community.

more context in the comments here: https://news.ycombinator.com/item?id=26406989

specifically https://news.ycombinator.com/item?id=26407565

I don't know if that's FUD or not, but personally async turns rust in a language within a language: core rust is interoperable with everything via C FFI, you can build on top of existing stuff. But if you let async rust lure you with its (well deserved) appeal, you end up in a parallel universe, where everything is pure rust.

Surely you want to use the pure rust async aware postgres client and the pure rust grpc implementation, but with async that's not a free choice.

You now have to deal with the fact that these (actually often quite well written) reimplementations often lag quite a bit in functionality.

For example you think you can just use some boring technology like a RDBMS but then you discover that pgbouncer doesn't really work well with sqlx. Similar stories for gRPC and other stuff.

Don't get me wrong, I'm not saying that's because async implementation is bad or it hasn't been well thought out. Other languages make other tradeoffs (e.g. Go detects blocking syscalls and increases the size of the thread pool, which makes it a bit easier to accomodate blocking FFI with the core async model, but that comes with a price).

What I'm saying is that in practice async rust feels like another language, a language built on top of rust, that looks like rust, that can call rust, but effectively creates its own ecosystem. The problem is compounded by the fact that it's still called rust, and often you can write libraries that can do a bit of async or not based on optional features.

It's probably all unavoidable and for the better, but it does add a source of fatigue that must be acknowledged and not dismissed as FUD.

Does async rust prevent the use of C FFI? A quick google shows me nothing there.

It doesn't. You can call non-async Rust and C from async Rust just fine. You just have to be beware of calling blocking things if you're not in a context where blocking is ok (i.e. in a CPU work pool thread).

I'm not sure what the GP meant, to be honest. Async "colored" code does have an tendency to "infect" more and more of your codebase, but you can still write and integrate big chunks of non-async code (e.g. a parser or a network protocol) if you're mindful about your design.

Sure, you can technically call other rust code from async rust and thus you can also technically call C code via FFI, but if that code blocks you have a problem. There are ways around it but they are hard to use and create the pressure towards just rewriting the whole thing in rust.

I could be wrong though. The reason I like to discuss these things here is the opportunity to be proven wrong by someone who knows more and offers a counter-example

If you need to call blocking code from an async code just use spawn_blocking.

https://docs.rs/tokio/latest/tokio/task/fn.spawn_blocking.ht...

Yes you can. And this will create threads on demand as needed.

But you need to know when you must call this and when it's ok to not call it.

The type system won't help you with that. But if you forget to call it you can cause starvation and if you call it too often you may create too many threads.

What I see in the ecosystem is that such tricks are perceived as hacks and that it would be just better if one could just write a pure rust reimpl.

Surely there are enough reasons that drive people to reimplements stuff in rust. I think this aspect of async nudges people even further into that though.

I think async creates a mini-language within _any_ language, i.e. the whole what-color-is-your-function problem. It's turtles all the way down or nothing.

In return, of course, you get a style of concurrency that tends to be much easier to reason about and much less prone to subtle bugs than traditional preemptive multitasking.

Whether that tradeoff is worth it is obviously very dependent on the particular situation.

I think you're right that async Rust isn't quite done yet (improvements on this front look to be a major focus for 2022). But I think the fact they were able to get an MVP released that so far looks like it can be built upon without too much technical debt is positive rather than a negative. Rust would be far less useful without the async feature.

async is a good example! I agree it is fine for the time, but of less quality than the rest of the language.

Still, the fact that Rust has MIR I think very much limits the damage premature async can do. If we get something better, it should be quite possible to extra "Rust - today's async" to recreate it.

Conversely, I wouldn't be surprised if many of the misfeatures in Switch are in impossible to extricate.

The recent post[^1] about the roadmap for Async Rust shows promise for the coming years.

[^1]: https://blog.rust-lang.org/inside-rust/2022/02/03/async-in-2...

> E.g. I don't expect Rust to go off the rails.

Unless the rails are too rusty :-)

Rust dropped the GC before reaching 1.0, it was the best decision back then as the memory management evolved. But right now as it guarantees backward compatibility, only new features are allowed to be added (although a lot of new features are coming without new extra syntax).

I still love Objective-C. And to me—I'm so amazed that Apple added "Property Syntax" and "Properties". It's pretty easy to do much of this with Macros (which could have been baked into the system) and the language stays very simple.

You would have 2 lines of code per property but one fewer concept—and I think that is a much more important factor. To me—this was not the right way to add sugar.

Yeah, no macros in Swift is a bit of an odd choice. It means that every would-be macro has to go through the language evolution process and be blessed by the Swift team. You can't release macro-like functionality, such as Rust's serde, without support from Apple.

Write your own preprocessor?

It’s certainly something that they want. I suspect it’ll be added someday in a major release.

As someone who started learning Objective-C only after Swift become firmly established, I have to say I strangely like the language. I picked it up fast and have had no issues with adding features to a legacy codebase.

When I started, I thought it would be some complicated beast, but no - its a reasonably simple and elegant C superset with the only disadvantage of some extra verbosity. (but Apple API's suffer from verbosity as a principle)

I have to wonder: why did Apple create Swift ? Objective-C is quite nice, especially for C/C++ programmers. With Objective-C++, interop with C++ libraries is also terrific. Swift offers nothing like this yet.

> I have to wonder: why did Apple create Swift?

They wanted a safe, performant language that interoperates with Objective-C. Safety gets them fewer vulnerabilities, interoperability means they can gradually decrease (Objective-)C usage.

Also:

- opinions on the nicety of Objective-C differ (but the only arguments I’ve heard why it would be bad more or less are “I don’t like the syntax” and “it’s verbose”, both of which, IMO, are weak. Both, IMO, are acquired tastes. I don’t think anybody is born preferring terse K&R C, for example.

- as you probably know, work is being done on C++ interop (https://github.com/apple/swift/blob/main/docs/CppInteroperab...), so that may improve.

>I have to wonder: why did Apple create Swift ?

I asked this many times over the years, even in this thread [1]. Still no concrete answer. I still think overall it is a distraction.

[1] https://news.ycombinator.com/item?id=30418197

Plenty of Chris Lattner interviews answer that question.

https://atp.fm/205-chris-lattner-interview-transcript

I know Chris lather's intention. And I have read and listen to all the interview he did. I think the question should be, Why was it necessary for Apple to bet on Swift. Something I dont think Bertrand Serlet or Avie Tevanian would have done.

That is the answer right there, they weren't the ones calling the shots and the direction bought into Chris' intentions.

Oh well. I guess this is another thing I could blame it on Craig Federighi.

I thought it should be obvious. Apple was competing with Google/Android for mobile developers. For Android, you programmed in Java, which everyone learned in school. For iOS, this funny language with smalltalk syntax was a barrier to entry.

So Apple needed a nice language with C-like syntax to woo developers.

Because they wanted a modern language to power their platforms. Objective C is ancient, and showing it.

Chris Lattner has mentioned that in a couple of interviews, there is a limit how much they could improve Objective-C towards being a safe systems programming language, exactly due to its C heritage.

It seems you like some ancient language which can't even concatenate a string without writing this dull statement with bunch of symbols.

  NSString *string1 = @"Some";
  NSString *string2 = @" string";
  NSString \*string3 = [string1 stringByAppendingString:string2];

Not to mention it didn't have ARC back in the days.

For sake it was built nearly 40 years ago. Not sure if there's any room to question why Apple and devs wanted a new language.

I was amazed why anyone would want to use this language before Swift but people didn't have a choice.

There were efforts like MacRuby.

To be fair, while Swift includes nice convenience methods for strings, the new API comes with a considerable cost:

https://www.mikeash.com/pyblog/friday-qa-2015-11-06-why-is-s...

That article is from 2015. A lot has changed, though some people still complain.

Doubtful that the technical underpinnings of the API have changed all that much since 2015.

They very much have.

ARC has been there for almost a decade now. Also if you wish to do heavy string concatenation, please use a NSMutableString and you can simply do: [string1 appendString:string2];

It is amazing that people forget to simply use the right tool for the right job and blame the PL instead.

As I see it, when we will have built languages that didn’t de-evolve into a bazaar of features, those will be dependently typed languages.

Because a dependent type is a type that represents a computation. A word that symbolises a computation, a word which can be manipulated by hand and assured by machine – and vice versa.

Software is automation. Types are signifiers of meaning. Dependent types are the automation of the automation.

Using a dependently-typed language feels like handling a machine which is the result of having closed a fundamental loop of expression vs. meaning. And that is what it is.

It’s very philosophical-sounding! It has its roots in philosophy – in intuitionism, where math dug down and met philosophers who had dug down from the other side. Kind of.

Practically, the upshot is that things actually become simpler. Kind of because you can grip the tool everywhere. Un-dependently typed languages feel kind of like they’re part tool, part void. You usually can’t express things relating the context you’re in, or looking at.

what's an example of said language?

Idris, some Haskell extension, and Agda

Dependent types are a false idol. It’s better to express propositions just as propositions, like in Isabelle/HOL.

Tell me more!

(As I see it – at least these days – dependent types just are. It’s very, very nice to just have higher-order unification and the things that sort of fall naturally out of having it.)

They are a false idol in that, when people learn about them they seem like they’re the answer to all problems, and they’re not. The fact that types are equivalent to propositions doesn’t mean that making all of the propositions about your code at the type level is a good idea. For me, it’s completely unnatural, clunky, and more verbose than just writing propositions as logical statements.

I found this talk from Xavier Leroy a while back too: http://www.cs.ox.ac.uk/ralf.hinze/WG2.8/26/slides/xavier.pdf. He is the main person behind CompCert, the formally verified C compiler. They do that verification in Coq, so I was expecting him to be a believer of dependent types. But he had this to say:

“ Dependent types work great to automatically propagate invariants

- Attached to data structures (standard); - In conjunction with monads (new!).

In most other cases, plain functions + separate theorems about them are generally more convenient.”

For that reason I prefer Isabelle/HOL as a theorem prover. The core logic is simpler, but you can express whatever you want as a theorem, without worrying about phrasing it within the type system. It feels a lot more natural.

That’s not without downside either of course. Proofs in Isabelle notoriously must match the structure of the code being verified, so changes to the code require proof changes. Liam O’Connor wrote an example of where they he feels dependent types are better here: http://liamoc.net/posts/2015-08-23-verified-compiler/index.h....

Even with that, I’d rather have simple code plus simple propositions with complexity at the proof level. This will likely be another eternal holy war though.

Thank you so much for taling the time to write this thoughtful and valuable reply!

It helps me see what I think I’m seeing, or rather to define it. It also has helped me to perspectives I hadn’t seen.

I’m coming to dependent types from here: “simple, clear code good yes program program argh I can’t express a very distinct thought without escaping to another language layer or generating code using string concatenation”, and from here: “my data structure is simple and clear but argh it needs a handwritten parser and serializer and it needs to be maintained and argh why am I writing a parser AND a serializer it should be just one bidirectional definition? and argh why do I need to write it for each output/input format?”, and from here: “my code is simple and clean and my variables are well named and my tests are well defined and my documentation is well written but argh why can’t I just fold the mechanics that the tests define into the code? as proofs? (and… argh? why can’t my variables and documentation and method names be checked against the code?)”.

It’s metaprogramming that I’m thinking about. And most programming ought to be programming. But we definitely need metaprogramming, and it needs to be understandable and composable and simple and clear. And I don’t know if dependent types are a complete solution to that, but I do think that they are necessary for it.

That-which-is dependent types, which by definition is a computation of what it is and is a proof of what it is. Those philosophical terms finally become practically grounded and practical help in a lot of the work I find myself doing.

I’ll certainly look for the false idol too! My sincere thanks.

  > Software is automation.

software is a lot more than just automation

I don’t disagree!

You either stay unpopular enough that no-one demands that you compromise your vision, or you become popular enough that there is constant pressure to add features that are important to some part of your community.

C# will not rest until it has every feature of every language.

It's funny because it mirrors MS' approach to product development in general.

I rather love C# pace of evolution.

Is Java and C++ not the same? I think so. No hate for all three: I use all of them, and there are pluses and minuses about all of them!

Wider question: How can a language and its core library stand still? To me, standing still is death for any computer programming language ecosystem. Many languages are just getting started on the idea of "green threads" and "colours" (sync vs async). Some of this can be done purely with a core library using existing language features, but some evolutions are better done with language features.

Java is leaner than C# and C++.

> How can a language and its core library stand still

I guess by having a more abstract foundation and relying less on adding hacks like colored function? Haskell seems to be like that.

Another thing is language extensions that you have to turn on to use. This makes deprecating stuff easier in the future, so languages can trim itself instead of keep growing.

Java looks more leaner, except when really wants to master it, also needs to understand JVM APIs for low level coding (invokedynamic and friends), annotation processors, JVM agents, just like C and C++ how the many existing implementations behave, bytecode rewriting libraries,....

C# has all of that, and more syntaxes. And I don't think anyone's ever taken the position that Java is as complex as C++

Sure, but day-to-day Java doesn’t usually require that any more than day-to-day development in Objective-C doesn’t require learning the details of the runtime.

I sort of agree with this sentiment but I must say that the implementation of said features has been pretty sane so far, especially if you compare with C++.

Kind of, string? MyFunc (string really!!)

Looking forward to C# 11 code.

There’s a concept from compiler optimization called Local Reasoning that I have stolen because I think the name applies at least as well to ergonomics/DevEx concerns.

A good deal of bad code design comes down to not being able to predict what a bit of code is going to do without stopping everything, unrolling whatever built up state you had in your mind (from the thing you were actually trying to do) and sit and become one with the code for a time. But at least when you’re unsure what the code is doing you have a suspicion that is the case. The worse sin by far is misdirecting you into thinking it does one thing when it does something else, or even the opposite.

We like to complain about extroverted business people interrupting us, but we seem to have very little guilt about doing it to each other by leaving these sorts of time bombs in our code.

> used to [..] you could look at a piece of Swift code and roughly understand

For all the critique of java, I think this is the one thing java got correct. It is (no matter how verbose or clunky) still easy to read and understand.

Ditto for Objective-C, which by convention handles verbosity in a more elegant way than Java imo.

Objective-C is a neat little language. Don't get me wrong - I would never go back to it, largely because of runtime errors due to duck-typing - but there were definitely things to like about it.

The best part was the perfect C/C++ interop. When I was working on iOS apps in Objective C, I found myself writing a lot of pure functional code using C and it was pretty neat to be able to integrate that with the OO stuff from Obj C so easily and with a clear dividing line.

Not in the real world, though. And for similar reasons, too. Most real Java projects I end up working on/with are littered with annotations that do God-knows-what.

In enterprise Java code is filled annotations from some random half-assed framework. While talking to developers I feel they think annotations automatically reduce code. E.g @Validation annotation somehow magically validate input data whereas right in front of their eyes code is still if/else conditions and strings manipulations.

Of course one can't make them understand as they are just following "best practices" enforced at employers.

Yeah, I would say prior to annotations taking over, the Java codebases I worked with were often quite understandable. Annotations have certainly clouded things though. Spring, for instance, is great conceptually but there's way too much magic and clutter when using its annotations.

Annotation is the worst one that obscure what happening. Java language needed to be improved before annotation/javaassist based approach getting so popular

It's trivial to look up the docs to see what they do. It's not unlike looking up what a function call does.

In my experience, it's much more of a momentum killer and context switch to research an annotation than a function call.

First of all, in most IDEs, it's very quick to jump to a function's actual definition to investigate such questions as "What if both of the arguments are < 0?" or "Is null an acceptable argument?". With annotations, you'll often go-to-definition and be staring at an almost empty class that hopefully has a docstring. This is because the annotations, themselves, don't actually do anything- you have to go find the code that actually checks for the annotation and does stuff.

In my experience, the docs are often not good enough when I run into a problem. I was wrestling with some strange behavior with JacksonXML some time ago, and I had a very hard time figuring out what went wrong because Jackson has so many options and they don't actually all compose well, so it's not even about figuring out what one option/annotation does- it's about figuring out what happens when I set OptX=1 and OptY=4 at the same time. Unfortunately, the docs only tell me what is supposed to happen when OptX=1 and what's supposed to happen with OptY=4, but nobody has decided to document every single combination of every single setting in the library.

I cant tell if this is a joke. Have you ever looked at a production java codebase once

I was wondering the same. It's usually a game of "find the actual behaviour" among a sea of interfaces, frameworks and so forth. Go, I can see the argument for.

Golang is quite bad when trying to find an implementation for an interface, because it is quite easy to accidentally implement an interface even if you're not intending to. This also makes it much harder on the IDE to index everything.

To illustrate the above point (a little hyperbolically) https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

But what they're referring to is that none of the code in that is hard to understand... unlike in C/C++. This is like of like the same idea behind Go. You make the language simple and straight forward and even though there may be a LOT of code the code will be be easy to understand.

And I would add that Go is obviously easier than Java here by design, but anyone could write a horribly over-abstracted Hello World or Fizz Buzz in any language given the motivation.

> And I would add that Go is obviously easier than Java here by design

Nothing in golang makes it easier to understand compared to Java by design, and the opposite is actually true (e.g. no proper enums, no records, no pattern matching, etc.) make it more verbose and harder to get to the underlying logic.

That being said, you should see some of my employer's golang code with their web framework that they wrote and the 80+ line stack traces.

I have looked at many production java codebases. I agree that some things can be complex, but that is typically a feature of a framework (java has many configuration heavy frameworks) and not the code aspects. But I haven't seen any production code that is complex simply because it is production java.

Could you give an example for your point?

I've seen an internal Java-based web application (a digitization of some business processes involving what used to be paper forms) in which nested elements in a web page corresponded with subclasses in Java. Way high up in the hierarchy, it had `HTML`, `CSS`, and `JavaScript` classes, each of which eventually descended from a `Document` class.

It was impossible to properly trace any behavior through. Every method zigged and zagged through the inheritance hierarchy multiple times as you traced deeper. And so:

> It is (no matter how verbose or clunky) still easy to read and understand.

The sentiment is taken well, but it's just not true. Credit your fellow engineers for the positive experience, not any particular language.

> For all the critique of java, I think this is the one thing java got correct. It is (no matter how verbose or clunky) still easy to read and understand.

I think that this comment was written with a positive spirit, but that quote-chopping is incredibly meaning-distorting in a way that counters your point. The original poster stated that Swift "used to be the case that you could look at a piece of Swift code and roughly understand how it would compile to assembly pretty easily" -- you chopped after "understand". There are very few languages where it's /harder/ to understand how they compile to assembly than Java. The JIT compilers are both incredibly complex and incredibly varied, and almost all of them have multiple possible compilation outputs for the same code.

Java, as a language, has been relatively successful in making it easy to understand programmer intention when reading code, as your chopped quote implied -- but the same could be said of Python, Julia, and plenty of others. Swift is in the much smaller category of languages where you can understand how the code will /run/ -- along with C, etc. One could argue that Swift's greatest virtue is that it falls into both categories, but that's another discussion.

I think that "how it would compile to assembly" is a shorthand for "understanding what the code does".

Not many people these days can read and fully understand the 64-bit assembly code generated by llvm. I think it is less than 1% of Mac developers.

C++ also have a lot of magic going on. Even C can be tricky with an optimizing compiler.

I'd accept "how it would compile to assembly" as "understanding the machine-level behavior of the code," but again, I find this extremely lacking with Java.

I don't know what percentage of developers can read assembly, but the popularity of tools like Godbolt strongly suggest it's non-zero. In my own experience, all of the most skilled developers I've worked with have been comfortable digging down to the necessary level -- and doing that in Java, or most other JIT'd languages, is just not fun.

You'll notice that I very much didn't put C++ on either the "easy to understand intent" or "easy to understand behavior" lists -- while it's my preferred language and my primary language, ease of understanding is not its virtue. And while I agree that C compiled with a minimally optimizing compiler (CompCert, clang -O1, etc) is easier to understand than optimized code (for me, the sweet spot for understanding is as compiler that does good register allocation and constant folding, but only really does instruction reordering for memory ops), it's pretty rare that I look at the output of highly optimized code and am surprised or find it hard to follow. Some constructs (medium sized switches, for example) can be pain points... but most often reading assembly output from optimized C is either "yeah, that's about what I would have written" or "close, but you missed this optimization/intrinsic, I'll do it myself."

It really depends. Yes, you can more or less easily what each line of code is doing, but figuring out the purpose of everything in enterprise code can be a real challenge. Sometimes I have a feeling someone really wanted to make it as convoluted as possible since the same thing could have been done in a much simpler way. I remember the time when EJBs were all the rage and still can't understand why.

Come and join us in the Rust community! It's a bit more fiddly than Swift, but it's incredibly well designed, still has that slow and steady mentality, and has a lot of the same nice quality of life features that Swift has.

The problem is there are very few jobs currently.

Rust has some very nice things going for it, but it really lacks the kind of design polish that a Swift programmer is talking about. To put a crude analogy in it, it’s kind of like comparing macOS with Ubuntu.

> A few years ago that seemed to start to change. From my perspective, some of the features added to the language to support SwiftUI - specifically property wrappers and function builders - very much felt rushed and forced into the language based on external deadlines.

Yep. If anyone had doubts that the language was no longer the one Lattner designed, SwiftUI should've put the nail in that coffin.

Swift is an imperative, statement-oriented, language. In fact, I get kind of frustrated when writing Swift after spending some time with Rust: I just love writing `let x = if foo { 1 } else { 2 }` or `let x = match foo { ... }`, and it's ugly as hell to try to assign a variable from a switch statement in Swift, etc. BUT, that's okay- I'm almost sure that zero programming languages were written with my opinion in mind, and Swift is Swift.

But, SwiftUI is declarative, which just doesn't work with literally the entire rest of the language. So they added result builders and these weird, magical, annotations just so we can have a UI DSL.

Error handling is now inconsistent and annoying, too. The original approach was to use this quasi-checked-exception syntax where you mark a function as `throws`, and all callers are forced to handle the possibility of failure. The difference between this and Java's checked exceptions is that the specific error type is not part of the signature and therefore the caller only knows that they might get an Error, but not what specific type of Error.

They even have a mechanism for higher-order functions to indicate that they don't throw any of their own errors, but will re-throw errors thrown by function arguments. Clever.

Okay, fine. Pros and cons to that approach, some like it, some don't, etc, whatever. Except then they realized that this approach falls flat in some scenarios (async/promises), so we really just need to go back to returning error values. So they stabilized a Result type.

So, now we need to figure out when we're writing a function if we want to return a Result or make it throw. And, even more annoyingly, Result has a specifically-typed error variant! It's actually a Result<T, E>. Which is it, Swift team? Should immediate callers care about specific error types or not?

Just recently, they landed the async and Actors stuff. Async is fine and great, and is consistent with the imperative syntax and semantics of the language, and it even supports `throws`, IIRC. But Actors? What the hell is that? That's totally out of left field for the rest of the language.

I used to really enjoy Swift in the 2.x to 3.y days, but it really seems like it doesn't even know what it wants to be as a language anymore, which is a real shame- it had a real shot to take the wind out of Rust's sails, IMO (The number one "scary" part of Rust is lifetimes and borrow checker. Swift has CoW structs and auto-ref-counted classes, instead, which can be seen as more appropriate for higher level tasks than writing system libs, etc).

I totally agree. I've been writing varying levels of Swift code since the 1.0 days and I truly can't think of a time I've felt constrained by not having the actor keyword. The threading and DispatchQueue APIs are so rich and flexible already, I just don't really see the use case. Maybe someone who's worked more with them can chime in?

I think the motivation for actors is that it's an abstraction which lets you write concurrent code with reasonably strong safety guarantees without adding as much cognitive overhead as a strict system like Rust. GCD is a really nice abstraction for async, but it doesn't protect you from shooting yourself in the foot if you're not careful about what thread is doing what.

That said, I'm really not sold on actors. I think CS as a whole hasn't really landed on the right abstraction for concurrency yet, actors seem a bit experimental, and GCD is plenty good enough in most cases.

A good critique of libdispatch is here: https://tclementdev.com/posts/what_went_wrong_with_the_libdi...

I think the main issue with GCD is the potential for deadlocks in serial queues (which it doesn’t really help you with), and the related problem of thread explosion in concurrent queues.

Actors make protecting shared mutable state really easy, solving a big chunk of the reason you’d want to use semaphores and serial queues in the first place. If you stick with async/await/Task{}/actors, you’re guaranteed to only have the optimum number of threads that can saturate cores, and won’t have deadlocks. If you use Sendable properly and heed all the warnings, you’re a good way towards the kind of “fearless concurrency” that Rust gives you. It really is pretty great IMO compared to GCD.

I’ve been using Swift Concurrency for the last several months and while it has a lot of nice things going for it there’s still a lot of ways you can “hold it wrong” and get incredibly poor performance. If you block a thread in the thread pool you’re going to deadlock. It’s still pretty easy to create data races (possibly with mis-annotated or poorly thought out types). And logical races are absolutely still a thing, and I might even say they are more common because the messaging is that this’ll magically solve all your concurrency problems and it doesn’t do that.

> If you block a thread in the thread pool you’re going to deadlock.

I’m actually happy with this decision… it was very much done intentionally to prevent the kind of thread explosion that is all too common in GCD. The criticism of GCD I linked to was very skeptical of actors for this reason; if the implementation decides to add more threads to avoid deadlocks, you get the same performance pitfalls as in GCD, and thankfully that didn’t happen.

In practice, I’ve found that avoiding deadlocks is as simple as grepping for `DispatchSemaphore|DispatchGroup` in your codebase and eliminating them with extreme prejudice. If you stick to Tasks/TaskGroups/Task.sleep, there’s no real possibility of accidentally introducing deadlocks unless you try really hard to do so.

And yeah, logical races can still happen in actors, but it’s easy enough at a glance to tell whether you’ll run into one… if you avoid using `await` in a section of code that needs to run exclusively, you’ll be fine. (Even with `await` calls you may get lucky if there’s no actual suspend point happening, but a quick and dirty rule is just “don’t call await and your code will never be run concurrently.”)

> I’ve found that avoiding deadlocks is as simple as grepping for `DispatchSemaphore|DispatchGroup` in your codebase and eliminating them with extreme prejudice.

You’d think so but then you realize that framework code you call into might decide to do this and you wouldn’t know until it deadlocked. On a 6-core iPhone 13 this is probably not going to be noticeable, but that’s probably not true on a 2-core iPhone 6s…

Framework code you call into can block so long as it makes forward progress. Deadlocks happen if you lock a thread in the shared Concurrency thread pool, and expect some other code running in the same thread pool to do the unlocking.

But if you’re calling into framework code which is using GCD, the queues it dispatches into will be run on a separate GCD thread pool. If said framework code is using a semaphore or lock to block your calling (Concurrency) thread, then it stands to reason there’s another thread in the GCD pool which will eventually unlock it. (Or else it’s a deadlock no matter what you do.)

I haven’t come across any framework code which violates this, although maybe you’ve run into problems I haven’t.

Swift seems to me very similar to Rust in the sense that it's a language that try to do everything, to be both low and high level. Rust is leaning on the lower end and Swift is higher end. The different is Rust has a selling point, which is the borrow checker. Swift's selling point is... made by Apple? In that sense Swift might be closer to C#.

To be fair, I think Swift does have a reasonable selling point in that it's an easy-to-write language with ADT's, named function parameters and excellent nullability handling. It really can be quite nice to work with.

But I think it's over-sold as a systems/low-level language. Relying on ARC for all reference types creates a significant floor in terms of performance which makes it unsuitable for a lot of systems programming applications - unless you resort to unsafe Swift, in which case you're not really writing Swift.

Like Rust, Swift offers the performance of a compiled language with memory safety.

> And imo they have a largely negative impact on the language: it used to be the case that you could look at a piece of Swift code and roughly understand how it would compile to assembly pretty easily, but with these new features there's a ton of compiler magic going on behind the scenes.

What do you think the ratio between people who want to understand what the assembly will look like, to people who want a simple and powerful way to write apps? I think it's very close to 0.

Reply on news.ycombinator.com