Hacker News Reader

Comment by loeg | Hacker News Reader

> 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.

View on HN

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.

[1] https://forums.swift.org/t/if-let-shorthand/54230/188

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?

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, ...

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.

Fork it!

Call it Bird or Goose or something.

Pull out SwiftUI and keep it simple. Focus on the server market more.

That would actually be an interesting direction. Swift would be an amazing server side language.

Obligate ARC is not a good fit for server software. Even obligate tracing GC ala Go and all the JVM/CLR languages gives you better throughput than that, though obviously doing neither is best.

I think Swift could work very well in a lambda/serverless context.

In that case, you'd be writing mostly functional Swift code with sparing use of reference types, which would mean you wouldn't hit ARC at all and you'd have static memory management similar to Rust.

That, along with Swift's expressiveness, ADT's and awesome type system in general would make it a great experience.

Kind of like the ergonomics of Python with an actual good compiler eliminating obvious mistakes like Rust.

> in a lambda/serverless context.

Perhaps, but that's not server software, is it?

You wouldn't consider code executing in a lambda to be server-side? What is it then?

A software function, as in "functions as a service". Very different from the concerns of most server-side code.

Yeah I mean I think it's largely semantic. I think when most people talk about "swift on the server" they mean they want to write their server-side business logic in Swift, and that seems perfectly suitable in a serverless context.

Sorry, don't know enough of the theory behind this – why is that not a good fit?

Happy to read up on this if you don't have the time to type it up.

Because it's too slow.

Great explanation, thanks...

I’m not sure if it’s fair to dismiss ARC as a bad fit for server-side work in general, but the typical argument is that atomic retain/release operations become quite expensive when you share memory across threads. It’s easy to imagine, for example, how a global database connection pool accessed on every request across dozens of threads would have non-zero ARC overhead.

In practice, compiler optimizations reduce the amount of retain/release pairs emitted, but I have no idea how the resulting performance compares to GC languages.

Ah I see very interesting, thanks!

Bad, like really bad.

https://github.com/ixy-languages/ixy-languages

Interesting, thanks for sharing.

Related thread on Swift forums [1] seems to suggest that the latest Swift compiler would generate code that performs a lot better than the Swift 4.2 version. I'm interested in checking that for myself.

[1]: https://forums.swift.org/t/swift-performance/28776

It's mostly not the atomic op overhead that's expensive, though -- it's the sharing.

You can write shared-nothing algorithms using ARC objects that are local to a single thread or core, and while it will be slightly more expensive than RC objects, the N^2 effect of sharing between N cores won't occur.

I think he has enough on his plate.

IBM took a stab at it a bit ago - https://developer.ibm.com/languages/swift/

There is some neat stuff that you can do with it in docker https://hub.docker.com/_/swift

> Call it Bird or Goose or something.

I'd cast my vote for Crested Shriketit. Or maybe Mionectine Flycatcher? Many-Coloured Rush Tyrant?

Incidentally, Wikipedia's list of birds is truly a wondrous place: https://en.wikipedia.org/wiki/List_of_birds

Prothonotary warbler? At least it's not red.

UnladenSwallow

But an African or European one?

I don't know that!

A rename would be welcome. That singer girl pops up every other search about Swift, so irritating.

Since we'd be adjusting it to fit, perhaps Tailored Swift would work as a name?

Rename it to Taylor

I just searched "swiftlang" and the knowledge box was to some other language called Swift.

What do you mean by keep it simple? SwiftUI isn't a part of the Swift language.

Reply on news.ycombinator.com