Get the top HN stories in your inbox every day.
skohan
tlb
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.
rob74
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...
caycep
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....
amw-zero
I totally agree. That’s why I’m completely pro the BDFL model. Committees don’t produce good products.
Hareti
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 :(
xiaodai
mixedCase
Democracy is a way to get things done while minimizing the potential damage inflicted by actors that have a lot of power on a large scale for long periods of time.
It is not the most efficient way to do things. It explicitly sacrifices some of it to help prevent leaders with uncontested power from coming up with things like concentration camps for dissidents.
majormajor
There's a lot of shitty "single creator with all the power" software out there too, obviously...
amw-zero
Almost no one practices direct democracy because yes. It’s not good.
bigcat123
No, democracy is for governing human affairs in the areas of value based judgement, that being primarily in politics.
Software engineering is largely non value based, they are technical based. On things they designed for and on things they base their code upon. In such affairs, democracy is a incompatible framework. It's like my c++ compiler does not compile Java code, that's a technical design and facts. It has no implications to anything political.
yodsanklai
Isn't it the fate of all programming languages? they start on clean foundation, only to evolve in a bazaar of features.
mccorrinall
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?
loeg
In its 27th year of life, Lua introduced integers (in 5.3).
pshc
the language so 'clean' it doesn't include array.len()
hdjjhhvvhga
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.
skohan
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.
jb1991
> 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:
rodgerd
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.
Ericson2314
"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.
skohan
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.
Fordec
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.
pjmlp
Kind of, I lost count of how many extensions exist currently, and some of them are incompatible.
lr1970
> E.g. I don't expect Rust to go off the rails.
Unless the rails are too rusty :-)
mucholove
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.
lenkite
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.
bobbylarrybobby
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.
AnthonBerg
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.
amw-zero
Dependent types are a false idol. It’s better to express propositions just as propositions, like in Isabelle/HOL.
andrekandre
> Software is automation.
xiaodai
what's an example of said language?
jslaby
C# will not rest until it has every feature of every language.
skohan
It's funny because it mirrors MS' approach to product development in general.
koyote
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++.
throwaway2037
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.
dodyg
I rather love C# pace of evolution.
xiphias2
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).
hinkley
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.
silvestrov
> 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.
ragnese
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.
geodel
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.
mypalmike
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.
azth
It's trivial to look up the docs to see what they do. It's not unlike looking up what a function call does.
jdeaton
I cant tell if this is a joke. Have you ever looked at a production java codebase once
jen20
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.
ecshafer
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?
Qub3d
To illustrate the above point (a little hyperbolically) https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
hdjjhhvvhga
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.
Apocryphon
Ditto for Objective-C, which by convention handles verbosity in a more elegant way than Java imo.
skohan
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.
addaon
> 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.
silvestrov
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.
nicoburns
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.
saagarjha
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.
undefined
jamil7
The problem is there are very few jobs currently.
ragnese
> 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).
honkdaddy
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?
ninkendo
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.
skohan
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.
nsonha
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#.
skohan
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.
GeekyBear
Like Rust, Swift offers the performance of a compiled language with memory safety.
Grustaf
> 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.
rockbruno
I clicked on this thread because I knew exactly what I wanted to comment about, and was surprised to see that Chris mentioned exactly it in his message:
>After several discussions generating more heat than light, when my formal proposal review comments and concerns were ignored by the unilateral accepts, and the general challenges with transparency working with core team, I decided that my effort was triggering the same friction with the same people, and thus I was just wasting my time.
I stopped paying attention to Swift for this exact reason. I have actually submitted and implemented a feature in Swift and I think it was one of my most frustrating experiences with open-source projects. It seems that almost every thread in this forum devolves into people fighting over the most irrelevant details, and my proposal specifically took months to be submitted into review because a couple of users simply refused to back down from how they personally wanted it to work, ignoring the actual problem the feature aimed to solve. After a long time deflecting the comments, the feature was accepted the way I originally intended and I never entered the forum again.
Example aside, it doesn't take a proposal to see that almost every thread in the forum looks like this. Open sourcing Swift has benefits, but I think when it comes to the actual progress of the project, this particular democratic process was a mistake.
bombcar
Has there been an actively developed open-source language both without a "benevolent dictator" AND without being bikeshredded to death by democracy?
(I wouldn't count C as actively developing, even though it is moving glacially slow, I'm thinking of things like Python, etc. Or other languages that aren't "done.")
worik
Rust
sinistersnare
I think Rust does a _ton_ of bikeshedding. Here is one example[0] showing how much of a discussion is required for a relatively simple QoL feature.
YorickPeterse
I wouldn't consider Rust to fall in this category to be honest, as there are plenty of issues/RFCs where people were bike shedding for months or even years.
raydev
I'd argue that if Swift isn't more popular, it is certainly more visible than Rust. And probably just more popular.
Apple's marketing around Swift advertises the "open source" aspect, and there's a lot of money to be made making iOS apps, so there's naturally going to be a lot of noise around proposals/developments.
worik
Perhaps it was a culture mismatch?
Mozilla has a long tradition of "open source" that Apple does not. So Mozilla were able to cultivate a community around Rust, where Apple laid down a lot of astroturf...
JoelJacobson
It would be interesting to read the thread if you could please share a link to it?
techdragon
Key takeaway for me was the note that it “definitely isn’t a community designed language”. This is telling, I’ve watched a lot of neat languages over the years and absolutely none of the ones without community involvement have grown beyond the sphere of influence of their primary companies.
I like swift enough I’m learning it to build my own personal tech nerd ideal podcast client because I own apple devices and want an app that works between macOS, iOS, iPadOS, tvOS,and watchOS. but I doubt I’ll ever use it for anything beyond this one personally motivated project. Even if i release it as an app on the store for download or purchase I don’t know if I will ever be motivated enough to build anything else using it. Because the scope is too narrow. Business work is converging on open stacks like react, and angular, and the dark horse of C# with its latest release supporting WASM web components backed by GRPC-web and a C# function driven stack from front to back, even without SQL Server costs this is a compelling ecosystem backed by PostgreSQL and other completely open source tools.
But Swift remains Apple’s language for apple stuff and… while a profitable niche, it’s still a niche.
Edit: typo fix.
jon889
I’d much rather have a language specifically for creating apps than another generic language. It’s actually my opinion that Swift got worse since they started wanting it be used for more things like the server side.
manmal
The weird stuff came out of Tensorflow and SwiftUI IMO. Distributed actors looks like it’s not hurting the design.
username_my1
which sucks because apple had the chance not to repeat their mistake with Objective-C .. but history repeats itself.
No matter how much apple market share in whatever market grows, developers want to be able to switch platforms and not have to think about the language.
dmitriid
> apple had the chance not to repeat their mistake with Objective-C .. but history repeats itself.
Objective-C has served them for over 40 years, building several different OSes over a multitude of CPUS and platforms.
If anything, Swift would welcome a repeat of this history.
MAGZine
You can build OSes in many different languages, and compile software to many different CPUs and architectures.
That alone does not make it good.
andrewcl
Objective-C is such a small and concise language. It doesn't get in the way of development in quite the same way Swift can delay building out a feature due to bikeshedding.
snek_case
Vendor lock-in will always inevitably backfire, because developers and users don't want to be trapped. It might work to maximize profits in the short to medium term, but there's very strong financial incentives not to be stuck with a single platform. Vendor lock-in could mean the death of your product, or even your whole business.
infogulch
Most new products are positioned to grow into a form of locked-in market that you can extract value from, drawing a box around their customers for the sole purpose of squeezing it in the future. This business strategy is a mind virus and has even overtaken the aspirations of bright-eyed entrepreneurs. The aim has fallen from the simple "get rich by selling a $1 item to 10 million people" down to "create a product where customers are trapped in a dependency relationship with the product by design, give it away below cost to push out alternatives, then flip it and squeeze them for as much as possible" (where the last part is omitted from the initial business plan but still implied, and enabled by outsourcing the dirty work to new management via buyout).
The primary goal should be to maximize value, and within that a balanced tension between maximizing delivered value vs maximizing captured value. It's reasonable to be compensated for the value you add, but it needs to be in service of maximizing value in general. If the correct hierarchy of goals is inverted and capturing value becomes the primary aim then it inevitably devolves into this antisocial, monopolistic, lock-in behavior.
Grustaf
I'd say at least 95% of Swift users don't mind at all that it's mostly an Apple language.
mehrdada
Objective-C was not originally designed by Apple (or NeXT)
silvestrov
I think Swift was a strategic mistake mainly due to the niche effect, even if it's a better language.
It would have been much more productive to team up with the C# team as C# is a mature language, and a combined Apple + Microsoft would have been able to compete against java (esp. with Oracle as owner of java).
eropple
An Apple C# future is a neat idea, but I'm not sure how you square that with the (IMO correct) observation that allocation control really matters for quality of experience on constrained platforms.
Obviously iOS platforms are much less constrained today, but not having to run a GC is a pretty nice thing.
Maybe C# could've been extended into that universe (I know Midori had their own variant but don't know much about it) but it seems daunting to then make that compatible.
mwcampbell
I agree with you, and I've long speculated that lack of tracing GC is the main reason why iOS devices don't need as much RAM. It's too bad that the options for implementing a GC-free GUI that can target Android are quite limited, and as a consequence, the low-end devices used by people who can't afford an iPhone are inevitably saddled with GC.
silvestrov
Apple tried to do automatic GC but did so very badly and with a language not designed for it, so they had a bad experience and were scared away.
The modern GC in java is amazingly fast and with a few tricks likely to be good enough.
jimbokun
Swift needed perfect interoperability with all the existing Objective C code, and that probably would have been difficult to accomplish with C#.
andrewcl
It's arguably difficult with Objective-C today, let alone C#!
krzat
Rust would be a more realistic choice, as it's built on LLVM.
GeekyBear
> Key takeaway for me was the note that it “definitely isn’t a community designed language”.
If you scroll to the top of the page with Chris' comment, this point is being addressed:
>In the coming weeks, we hope to introduce a new language workgroup that will focus on the core of the language evolution itself, splitting off this responsibility from the core steering of the project. The intent is to free the core team to invest more in overall project stewardship and create a larger language workgroup that can incorporate more community members in language decisions.
jonhendry18
Another committee is sure to fix the problem with the existing committees.
jjtheblunt
> and absolutely none of the ones without community involvement have grown beyond the sphere of influence of their primary companies
C touches much more than telephony
loeg
> the root cause of my decision to leave the core team is a toxic environment in the meetings themselves. The catalyst was a specific meeting last summer: after being insulted and yelled at over WebEx (not for the first time, and not just one core team member), I decided to take a break. I was able to get leadership to eventually discuss the situation with me last Fall, but after avoiding dealing with it, they made excuses, and made it clear they weren't planning to do anything about it. As such, I decided not to return.
Oof. Yeah, that’s relatable. It’s hard to continue contributing volunteer efforts to projects you care about when you’re getting shouted at all the time.
programmarchy
It's very disappointing that such a talented person was pushed out, especially someone like Chris who seems to be a genuinely good person. It's all too common to see brilliant founder types be pushed out by power- and influence-grubbers who end up ruining the original spirit of the project. I read through one of the threads he linked that was producing "more heat than light" [1] and, yeah, it's easy to see why he'd move on. The person responding to Chris wasn't adding any value to the discussion, just being a pedantic troll. What's worse is that person was a moderator.
microtherion
Reading this thread for the first time, it looks to me like (1) everybody is fairly well behaved by the standards of an online forum and (2) Chris is probably using more inflammatory language than anybody else.
So maybe one the problems is that at this point, he's no longer getting the deference from other community members that he feels he's still owed?
undefined
gregoriol
Swift was never about volunteering: it's an Apple product, even if they tried to market it as open, it's Apple that manages the roadmap, with the usual secrecy, ...
loeg
Lattner was volunteering:
> For context, I left Apple over five years ago and the only constant in my life is that I'm always "very busy" :smile:. That said, Swift is important to me, so I've been happy to spend a significant amount of time to help improve and steer it. This included the ~weekly core team meetings (initially in person, then over WebEx), but also many hours reading and responding to Swift Evolution, and personally driving/writing/iterating many Evolution Proposals 19. As such, my decision to leave the core team last summer wasn't easy.
echelon
Fork it!
Call it Bird or Goose or something.
Pull out SwiftUI and keep it simple. Focus on the server market more.
jaredcwhite
I was really excited about Swift when it was first introduced, and I hoped it could grow beyond the confines of Apple's specific needs and ecosystem requirements. Unfortunately, that never really seemed to happen, and rather than Swift actually get better in the areas I care about (coming from a background in very expressive, dynamic languages like Ruby), in some ways it got "worse" (aka lots of verbose syntax all over the place simply to placate compiler-level concerns). SwiftUI was a bizarre advancement in that it attempted to add a very dynamic DSL mindset on top of a language which was far more rigid. Needless to say, everyone I've heard from who's tried to build production-grade UIs using SwiftUI has ended up feeling pretty burned. It's a grab-bag of cool ideas yet remains a buggy nightmare in practice.
I don't really know what Apple can do per se to turn this ship around, but Swift "as a brand" has definitely lost its luster. I'd considered wading back into Apple app development when SwiftUI was first introduced (at the time I hadn't touched any of the dev tools since early-era Mac OS X Cocoa/Objective-C), but I have no interest at this point. (The App Store being a real s**show also doesn't help matters!)
manmal
Having built a few apps with pure SwiftUI, I think you are exaggerating a bit. Yes, there are many many problems with it. I wouldn’t blame those on Swift though, since most people‘s gripes are with runtime issues.
anonymouse008
> I was able to get leadership to eventually discuss the situation with me last Fall, but after avoiding dealing with it, they made excuses, and made it clear they weren't planning to do anything about it. As such, I decided not to return. They reassure me they "want to make sure things are better for others in the future based on what we talked about" though.
This puts a bullet in my hopes for Swift. Why on earth would Apple not support this obvious A-Team player?
ironmagma
I don’t have any hope for the incumbent OS players. They clearly can’t get their priorities straight, and it’s sad that even within these OS vendors the native application development platforms are rotting in favor of cloud and web investments. Think about it, .NET is being sunsetted in favor of .NET Core, but the latter still doesn’t have desktop support and shows no signs of it. SwiftUI is a total letdown from what I’ve heard. It is ripe for disruption, that’s why I’ve been studying OSDev ceaselessly of late and hope I can find some more OS-minded people to collaborate with.
anonymouse008
[Edit: I might be the worst developer on the planet, so take it all with a grain of fine salt]
Yup, hot take: SwiftUI is hot garbage.
Declarative rendering is the worst rendering: it's code written that doesn't have to be written. The beautiful thing about UIKit, NSLayout, and Storyboards, is that when used effectively, not much UI code has to be written, and when it does, it matters.
Now everything has to be written to hells end. And not only do I need a mental diagram of my UI in rendered state, I need it in code state as well.
If someone could enlighten me, I would gladly take the lesson.
Edit: I'm very happy I posted this to learn. I used UITextViews extensively in my only app development, and was extremely frustrated with SwiftUIs readiness on that front.
That said, I still like that my code can reflect the 'flow of thought' rather than the strictness of the UI when developing. I guess a lot of the property wrappers got to me too
And all the improvements given to declarative rendering could be embodied in updates to Storyboards and the like.
bjtitus
I'm a bit confused by this take so my apologies if I'm missing the point. SwiftUI leans far more in the direction of declarative layouts with very little actual code required. It defaults to bottom up sizing so that view sizes are based on their contents and automatically uses default system spacing for basic layout tasks.
The only comparable thing in UIKit is UIStackView. In fact, UIStackView was clearly added to reduce the explicit constraint layout code required for simple layouts. While you don't "write" UI code with Storyboards, it's certainly there, just encoded into a non human readable format.
SwiftUI has many problems (mainly bugginess and missing APIs) but I don't see how the old APIs required "not much UI code ... to be written". If anything, this is one of the primary benefits of SwiftUI: getting to remove most of the explicit layout code and complex type system required to do basic layout tasks with UIKit or AppKit.
skohan
Declarative rendering has a lot of advantages in terms of composability. My main issue with SwiftUI is that the tooling just doesn't seem ready at all. I tried a small project recently, and the preview feature basically doesn't work.
Also I think the decision to make combine a core building block of Apple UI development is a huge mistake. FRP is a plague on the industry, and everyone is going to figure that out in a couple years.
newaccount74
I've recently attempted to use Swift UI for a very simple Mac app, and I have to concur: Swift UI is garbage.
The syntax is incomprehensible and inconsistent, the documentation is ridiculous, the feature set is severly lacking, and worst of all it's unbelievably slow. I have the fastest processor that Apple sells and a proof-of-concept app that I made in a few hours that consists of three Swift files takes 30 seconds to compile. I can't imagine what building non-trivial apps with it wouldbe like.
Eric_WVGG
I found “the old way” of doing things to be a mess. Despite building one of the first apps in the App Store, NSLayout just never became “second nature.”
Instead of the native app world, I stuck to web front ends and managed that awkward transition from jQuery to Angular to React. These models for UI made increasing amounts of sense — instead of fiddling with weird lines a slop gui, I could just tell the system what I want and get it!
Then SwiftUI came along, and lo, I get all the goodness of React in iOS and even MacOS! My first native app in years is coming along swimmingly, and it’s even cross platform!
(yes, I did do an app in React Native, and found it gross for reasons that I can’t put my finger on)
woah
If you don't have declarative rendering, you have imperative rendering with stuff like `canvas.drawLine()` etc. (just a made up example). This code tends to be very annoying to write and maintain because you need to do a lot of building up of elements and tracking the state of them yourself.
What you are referring to with UIKit, NSLayout, and Storyboards is in fact declarative rendering, but the layout code can only be modified with a point and click editor. In most people's opinions, editing code directly is much more controllable and works better for systems like Git.
ironmagma
I think declarative rendering has definite value. When you aren’t using it, you end up having to track your own dirty flags, and often that means you will neglect to update them properly, leading to inconsistent UI. CPUs are fast now, there is no reason to not be doing a few extra tree comparisons if it eliminates bugs and speeds up the development process.
The criticisms I’ve heard of SwiftUI come from a guy who absolutely loved React. I think the problems are unrelated to the overall idea of declarative rendering being flawed.
nodemaker
Couldnt agree more with your core argument. Declarative rendering is way more mental overhead than procedural rendering. Designing a system is more about the "how" than the "what".
krzat
Declarative UI works amazingly well when done properly (see Flutter). But Apple has a tendency to half-ass development tools, so it is what it is.
binarynate
> NET is being sunsetted in favor of .NET Core, but the latter still doesn’t have desktop support and shows no signs of it.
What do you mean? You can build desktop Windows WPF or Winforms apps with the new .NET. There's also MAUI for cross-platform desktop apps.
sblom
Yep. Probably the confusing name change threw him off the scent.
What would have been ".NET Core 5" is just ".NET 5", and that's when the bulk of the desktop framework compat came online.
ironmagma
Thanks for informing me. I hadn’t heard this so I’ll check these out.
mwattsun
I think parent is thinking of .NET Core 3 and doesn't realize that v5 and 6 add back many missing features and .NET Core is now just called .NET again.
CameronNemo
Reminder that Microsoft is trying to steal the name MAUI from an existing open source project.
Microsoft <3 Linux
voidfunc
> This puts a bullet in my hopes for Swift. Why on earth would Apple not support this obvious A-Team player?
There's two sides to every story?
bob1029
I would really like to hear what this yelling was about. Perspective is a hell of a thing.
There are some exceptionally capable people who simply cannot work together on the same idea/problem in my experience. This doesn't necessarily mean that one or the other is inherently bad.
Apocryphon
Lattner’s post linked to an example of a heated discussion:
GeekyBear
I'm pretty sure that Rust didn't fall apart when it's creator, Graydon Hoare, left Mozilla to work on Swift at Apple.
snek_case
My understanding is Swift doesn't have the same level of openness and community involvement as Rust. Apple has a lot more control over the language.
geodel
Yeah, on the flip side Apple is putting some serious engineering resources / funding in it. With Rust it is always creating committees, teams , sub-teams and so on and to actually do implementation there are far fewer resources.
So overall things balance out even if not big win for either.
Swift: Close process + big funding -> fast implementation / less feedback Rust: Open process + little funding -> slow implementation / lot of feedback
Also even with lot of feedback many community members in Rust are already claiming very new features like Async in Rust are deficient in parts and feels rushed.
GeekyBear
Isn't that what normally happens when the language has important in-house use cases?
>Go has community contributions but it is not a community project. It is Google's project. This is an unarguable thing, whether you consider it to be good or bad, and it has effects that we need to accept. For example, if you want some significant thing to be accepted into Go, working to build consensus in the community is far less important than persuading the Go core team.
https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGoo...
b3morales
It's less this one person's (Chris) presence or absence and more the sanctioning (implicit or not) of shitty behavior from some other person or persons.
GeekyBear
Yep. I'm not a fan of people who think yelling is a normal part of debate.
I think this comes down to Chris being a very busy person who has better things to do with his time than argue about the direction of a project he no longer controls.
undefined
undefined
klik99
Correct me if I'm wrong, but Chris seems like a very respectful person and I've never heard this direct language from him publicly - it must've been a pretty bad situation.
It's too bad Swift is straying from his original vision but that's the tradeoff of designing a new language with a large company. Not blaming Apple or anything, kudos for them putting so many resources in an experimental new language, and LLVM wouldn't be where it is today without them (which I think is enabling a sea change in engineering), but at the end of the day there's only one use case for swift that matters.
Zanneth
I've listened to both episodes of Lex Fridman's podcast where he interviewed Chris and he seems like an extremely humble and intelligent guy. No question he is one of the leading experts on compilers too, and has a lot of hardcore engineering background to prove it.
Sometimes organizations just grow to be too large and too remote to sustain a productive and respectful environment. I don't think anyone is necessarily at fault here.
elpakal
Chris is one of those people who gets me to stop what I am doing, shut my door, put on my head phones and just listen. Do not disturb. I am a self taught programmer and have learned my way by many a night studying/reading/debugging but all that teaches me is code. Just code! When I listen to Chris, I feel like I am listening to a technical leader, mentor and visionary. It's hard to find things to teach me how to become that, and it just so happens (maybe it doesn't the more I think about it) that I can usually also learn Swift while learning these other great skills or perspectives _by just listening to him talk_. Thanks for all you've done for the Swift community Chris and good luck in all that you do.
CalChris
I was at the LLVM Meetup last October, waiting in the buffet line and this guy behind me asked Chris, what are you working on? I turned around not quite recognizing him, looked at his name tag and it was Chris Lattner asking me what I was working on. A very nice, extremely smart person.
klelatti
> To answer your question, the root cause of my decision to leave the core team is a toxic environment in the meetings themselves. The catalyst was a specific meeting last summer: after being insulted and yelled at over WebEx (not for the first time, and not just one core team member), I decided to take a break. I was able to get leadership to eventually discuss the situation with me last Fall, but after avoiding dealing with it, they made excuses, and made it clear they weren't planning to do anything about it. As such, I decided not to return. They reassure me they "want to make sure things are better for others in the future based on what we talked about" though.
Seems incredibly disrespectful.
amyjess
Just imagine: if this is how they treat someone with Chris Lattner's reputation, think about how they'll treat a new contributor writing their first new feature proposal. It's not a project I'll ever want to touch.
klelatti
Indeed, astonishing really.
Seems to me to probably reflect a high degree of insecurity: if you're not secure and feel the need to protect your position I can imagine some people reacting this way if Chris is telling everyone he thinks your idea is a bad one.
caycep
I've heard great teams at Apple and toxic teams - maybe more on Software than hardware (see the writeup / postmortem on Aperture which started off great but middle managers under time constraints ruined it/made it toxic).
Not sure if Apple silo-ing off teams lets this perpetuate, but then again, it's not like Google or FB have their own share of toxic groups.
You'd think something like that whole Apple university MBA program would figure out better ways of managing large numbers of people with commensurate egos, but it seems like an unsolved problem.
halfmatthalfcat
Sucks because Apple has hired a lot of really talented developers to work on Swift. I hope they aren't being treated to this kind of toxicity.
fasteo
>>> not for the first time, and not just one core team member
Playing devil's advocate here, but we should hear the same history from the other side, more so if these "insulting and yelling" happened more than once with different team members.
klelatti
That's fair. Also presumably Apple's rules mean that we probably won't be hearing the other side.
staticassertion
Yes, true. But also, there are very few situations where what's being called out here is justifiable.
manquer
Yes there are situations where it is justified, but we shouldn't draw that conclusion with knowing all sides.
I don't know any details to question legitimacy of the issue, however in my experience I am constantly surprised how many times it is just communication breakdown or gap in what each party perceives.
Also the pandemic has made things more stressful for everyone and outbursts do happen with more frequency perhaps it is easier virtually to shout at some one i suppose.
Torvalds was known for his infamous roasts on LKML, he only goes on a triade when he feels the situation warrants and person should know better. That doesn't make it right , but someone had to really explain it to him before he toned it down recently. I don't think his intent was ever to be toxic or aggressive.
Effectively communicating problems can be hard.
throwawayboise
TLDR, life is too short to work with assholes, an attitude I fully endorse. Or maybe he's the asshole, who knows? Either way it works out.
nefitty
One of the strongest predictorsof work satisfaction is satisfaction with one's coworkers. It beats money and autonomy.
undefined
bitL
So they wanted him gone, figured out his sensitivities and he fell into the trap. Sad but common if some higher up decides to remove you "voluntarily".
notreallyserio
It's possible for an environment to be objectively toxic without regard to someone's "sensitivities".
jcims
I don’t generally pay much attention to this space. However, I’ve heard two interviews with Chris, both on Lex Fridman‘s podcast, and I don’t get a sense that he is an emotionally fragile person. The space he’s been operating in for ~20 years is filled with strong and often ideological opinions.
Just sounds to me like he felt like he was wasting his time.
ithkuil
Then why didn't he just say that he wanted to "pursue other challenges" or something like that, especially if he'd actually mean it?
threeseed
You know what's even more common and isn't a conspiracy theory ?
Engineers letting technical disagreements turn personal.
And Chris himself said he disagreed with the technical direction of the project.
klelatti
I'd be a bit skeptical of that. Sounds more like a team under stress and lashing out when someone questions the direction they are going.
In any event though not good.
qaq
They act like real a### on the forum so can only imagine how things are in private. Chris always came off really humble and down to earth.
Hokusai
In many parts of the world that goes against labor laws. You cannot harass or ostracize someone to make them leave. That is not just a toxic environment but way worse as there is intent to make the employee leave.
petters
I don't think there was an employment involved here.
oaiey
Still incredible toxic. Maybe not uncommon but still toxic.
GeekyBear
> they wanted him gone, figured out his sensitivities and he fell into the trap
It's also possible that there are people who feel that yelling is an acceptable part of debate.
Misguided people, sure, but they do exist.
touisteur
Then they should be taught, quick. Once is grounds for an apology, twice is bye-bye land. Who cares about 'objective' toxicity, WTF is wrong with people defending yelling at people.
KKKKkkkk1
To answer your question, the root cause of my decision to leave the core team is a toxic environment in the meetings themselves. The catalyst was a specific meeting last summer: after being insulted and yelled at over WebEx (not for the first time, and not just one core team member), I decided to take a break. I was able to get leadership to eventually discuss the situation with me last Fall, but after avoiding dealing with it, they made excuses, and made it clear they weren't planning to do anything about it.
Apple's management culture is they're basically running an army of orcs. Anyone who threatens the authority of the mid-level bureaucrats - they'll sic the orcs at you.
Apocryphon
Middle management does have a lot of autonomy and leeway to operate as they see fit at Apple, which could explain the lack of oversight.
patrickdavey
I have been lucky enough not to work in an organisation where I've been shouted at. What are you supposed to do in that situation? I'm pretty sure now I'd feel confident calling it out (though I definitely wouldn't have as a junior), but, what can you do if it doesn't stop? Just leave? Bullies just make me so angry.
blantonl
I think you are seeing an example of what you do. Here's a guy that has devoted an enormous amount of time and effort into a project, and decided that being yelled at wasn't for him - enough so that he departs something that is very important to him.
And since he's not naming names, he's being professional about it, but pointing out that the bad behavior isn't for him.
It is about as good as a response that can be considered, given the circumstances.
patrickdavey
This really doesn't seem like a "win" for Chris though? He's having to leave a toxic environment and leave a project he cares deeply about. In a company as big as Apple do they not have procedures in place to stop this behaviour? It just feels like the shouting person learns they can get away with this when they should be told this behaviour must stop or they'll be on their way out.
Apocryphon
> In a company as big as Apple do they not have procedures in place to stop this behaviour?
In my own experience… Apple is a large company, with a huge variety of teams with different accepted standards of conduct.
But the Swift language is also an open source project, so this is a pseudo-open dev community so I’m not sure if Apple’s internal corporate culture even has a strong hold over this mailing list and those WebEx meetings that probably include volunteers, not just Apple employees.
pshc
If you want to fight, maybe it becomes a battle of attrition fighting psychos on their own level. I think it's more of a win to be the bigger person and live your own life, especially after how much he's already accomplished.
samhw
> It is about as good as a response that can be considered
Just FYI, you want:
> It is about as good a response as can be considered
(Incidentally, I couldn't agree more with your comment. It was a very magnanimous response that he gave.)
lawn
You either leave or crush the bullies under your thumb, and there's rarely any middle ground.
So in practice, yeah you leave.
1123581321
You pretty much have to leave. There are some people who will respond well to a direct request to stop or a clear statement of how the shouting makes you feel.
patrickdavey
I guess my question is: why is this tolerated? Isn't it just simple harassment so management have to actually do something (even if they don't want to?)
TavsiE9s
Depends on management. I've certainly ended meetings when someone started to raise their voice and had a one on one conversation with them about professional behavior as well as expectations.
pshc
Perhaps management is complicit? Given they are a pressure cooker culture with even more secrecy than your average org, this might be normal for them.
1123581321
Because the organizations who will hire someone who screams at people are either a) under enormous pressure, b) manned by psychopaths, so your boss's boss either does the same thing or is a cool cucumber who exploits those with less self-control, or c) dysfunctional to the point where they cannot see what's happening or correctly evaluate candidates. It's frustrating and an incredible waste of human potential.
That said you are right; you should also raise the issue to upper management. You have more options than just speaking to them directly.
jb1991
Swift is really one of the most enjoyable languages I've used. I've worked in five languages full-time over the last 10 years, and Swift was the most elegant and productive for me.
Get the top HN stories in your inbox every day.
> 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.