Closing this as we are no longer pursuing Swift adoption

https://github.com/LadybirdBrowser/ladybird/issues/933

by thewavelength • 5 months ago

328 301 5 months ago

WCSTombs• 5 months ago

That's interesting, what happened? They don't explain it there.

For the record, I don't have a dog in this fight. As long as it runs on Linux, I'm willing to test drive it when it's ready.

guywithahat• 5 months ago

It looked to me like it was just due to recurring build issues. Lots of "swift can't import these conflicting C++ versioned libraries concurrently" and "can't use some operator due to versioning or build conflicts". Basically it sounds like trying to add swift to the project was breaking too many things, and they decided it wasn't worth it.

It's a shame, I think swift is an underappreciated language, however I understand their reasoning. I think if they tried to just use swift from the beginning it would have been too ambitious, and trying to add swift to a fragile, massive project was probably too complex.

jarjoura• 5 months ago

Looking at their integration, with cmake, they definitely took the hardmode approach to adoption.

drnick14• 5 months ago

Not too surprising. Swift is too tied to Apple and it's not really clear what the benefit would be relative to a subset of C++ written with contemporary memory safety practices. It's a battle tested choice and pretty much every browser actually in use is written in C++.

ahartmetz• 5 months ago

Well, it was a terrible idea in any case unless it was for high-level-ish code only. Swift generally can't compete with C++ in raw performance (in the same way as Java - yeah, there are benchmarks where it's faster, but it basically doesn't happen in real programs).

jabwd• 5 months ago

Hurray for micro benchmarks. Anyway, every language can be abused. I can make Java run slower than Ruby. Given that it runs on Microcontrollers on billions of devices, I don't think Swift is necessarily the problem in whatever case you have in mind (And yes I stole oracle's java marketing there for Swift, it is true though.)

jsheard• 5 months ago

It's a battle tested choice and pretty much every browser actually in use is written in C++.

Every browser in use is stuck with C++ because they're in way too deep at this point, but Chromium and Firefox are both chipping away at it bit by bit and replacing it with safer alternatives where they feasibly can. Chromium even blocked JPEG-XL adoption until there was a safe implementation because they saw the reference C++ decoder as such a colossal liability.

IMO the takeaway is that although those browsers do use a ton of C++ and probably always will, their hard-won lessons have led them to wish they didn't have to, and to write a brand new browser in C++ is just asking to needlessly repeat all of the same mistakes. Chromium uses C++ because Webkit used C++ because KHTML used C++ in 1998. Today we have the benefit of hindsight.

adzm• 5 months ago

Chromium even blocked JPEG-XL adoption until there was a safe implementation because they saw the reference C++ decoder as such a colossal liability.

Quickly followed by several vulnerabilities in that reference library as well; good move

fc417fc802• 5 months ago

TBF that's less a C++ thing and more that there have been several high profile decoder vulnerabilities over the past however many years. Enough that Google created the custom language WUFFS for the express purpose of implementing secure parsers for arbitrary file formats.

jll292• 5 months ago

It's probably okay to solve one problem at a time: first solve the "free open source browser, developed from the Web standard specs" problem in an established language (C++), and then the "reimplement all of part of it in a more suitable (safer, higher productivity) language - yet to be devised - problem.

And Andreas Kling already proved the naysayers wrong when he showd that a new operating system and Web browser can be written entirely from scratch, the former not even using any standard libraries; so beware when you are inclined to say 'not feasible'.

amluto2• 5 months ago

a subset of C++ written with contemporary memory safety practices

What is this mythical subset of C++? Does it include use of contemporary STL features like string_view? (Don’t get me wrong — modern STL is considerably improved, but it’s not even close to being memory-safe.)

mempko• 5 months ago

memory safety isn't really much of a problem with modern C++. We have the range library now for instance. What's nice about modern C++ is you can almost avoid most manual loops and talk at the algorithm level.

lyu07282• 5 months ago

They probable mean safe code like this:

    class FontFeatureValuesMapIterationSource final
    : public PairSyncIterable<CSSFontFeatureValuesMap>::IterationSource {
    public:
    FontFeatureValuesMapIterationSource(const CSSFontFeatureValuesMap& map,
                                      const FontFeatureAliases* aliases)
      : map_(map), aliases_(aliases), iterator_(aliases->begin()) {}

LeFantome9• 5 months ago

What is this mythical subset of C++

Ladybird inherits its C++ from SerenityOS. Ladybird has an almost completely homegrown standard library including their own pointer classes and a couple of different string classes that do some interesting things with memory. But perhaps the most novel stuff are things like TRY and MUST: https://github.com/SerenityOS/serenity/blob/master/Documenta...

You see this reflected all the way back to the main function. Here is the main entry function for the entire browser:

ErrorOr<int> ladybird_main(Main::Arguments arguments).

https://github.com/LadybirdBrowser/ladybird/blob/master/UI/Q...

If Ladybird is successful, I would not be surprised to see its standard library take off with other projects. Again, it is really the SerenityOS standard library but the SerenityOS founder left the project to focus on Ladybird. So, that is where this stuff evolves now.

abraxas• 5 months ago

Wasn't Rust developed specifically for Mozilla? Isn't mozilla written in Rust?

wmf• 5 months ago

Firefox has some Rust components but it isn't written in Rust overall. Servo is written in Rust but it isn't a full browser.

tvshtr8• 5 months ago

Yes and yes. Firefox is partially written in Rust.

Leynos• 5 months ago

Only parts of it. Servo is the engine written in Rust, some of which ended up in Mozilla.

snerbles2• 5 months ago

Mozilla laid off the Servo team years ago.

incognitojam• 5 months ago

The commit removing Swift has a little bit more detail:

    Everywhere: Abandon Swift adoption

    After making no progress on this for a very long time, let's acknowledge
    it's not going anywhere and remove it from the codebase.

https://github.com/LadybirdBrowser/ladybird/commit/e87f889e3...

IMcD23• 5 months ago

Some more context here too:

https://github.com/LadybirdBrowser/ladybird/issues/933

losvedir• 5 months ago

Ah, that's too bad. Does that mean their own programming language, Jakt, is back on the table?

refulgentis8• 5 months ago

For their sake, I hope not. I don't think an outside-donation-financed project with this much ADD can survive in the long term.

It's frustrating to discuss. It is a wonderful case study in how not to make engineering management decisions, and yet, they've occurred over enough time, and the cause is appealing enough, that it's hard to talk about out loud in toto without sounding like a dismissive jerk.

bbkane3• 5 months ago

Maybe I misunderstand, but I thought Jakt was part of SerenityOS, not Ladybird.

From what I can tell they're pretty laser focused on making a browser (even in this issue, they're abandoning Swift).

hypeatei• 5 months ago

Ladybird split from SerenityOS a while ago, Jakt is not "their" language. And no, I don't think a niche programming language is on the table.

throwaway274483• 5 months ago

Jfc why do they not just use rust? Is it the c++ addiction dominating?

qingcharles• 5 months ago

Rust isn't OO is their main issue at this point.

upmind• 5 months ago

When does the migration to Rust start? /s

weedhopper• 5 months ago

Rust bros already on their way to vibecode a rustbrowser, get their rust stars on rusthub, insult anyone to point out it doesn’t work, and call it a rustday.

densh• 5 months ago

It seems like today. https://news.ycombinator.com/item?id=47120899

stephc_int139• 5 months ago

I remember mocking the switch to Swift back then.

Swift is a poorly designed language, slow to compile, visibly not on path to be major system language, and they had no expert on the team.

I am glad they are cutting their losses.

isodev2• 5 months ago

Swift never felt truly open source either. That people can propose evolution points doesn’t change the fact that Apple still holds all the keys and pushes whatever priorities they need, even if they’re not a good idea (e.g. Concurrency, Swift Testing etc)

Also funny enough, all cross platform work is with small work groups, some even looking for funding … anyway.

stephc_int139• 5 months ago

The fact that Swift is an Apple baby should indeed be considered a red flag. I know there are some Objective-C lovers out there but I think it is an abomination.

Apple is (was?) good at hardware design and UX, but they pretty bad at producing software.

iLemming2• 5 months ago

Swift never felt truly open source either.

Apple has been always 'transactional' when it comes to OSS - they open source things only when it serves a strategic purpose. They open-sourced Swift only because they needed the community to build an ecosystem around their platform.

Yeah, well, sure they've done some work around LLVM/Clang, WebKit, CUPS, but it's really not proportional to the size and the influence they still have.

Compare them to Google, with - TensorFlow, k8s, Android (nominally), Golang, Chrome, and a long tail of other shit. Or Meta - PyTorch and the Llama model series. Or even Microsoft, which has dramatically reversed course from its "open source is a cancer" era (yeah, they were openly saying that, can you believe it?) to becoming one of the largest contributors on GitHub.

Apple I've heard even have harshest restrictions about it - some teams are just not permitted to contribute to OSS in any way. Obsessively secretive and for what price? No wonder that Apple's software products are just horrendously bad, if not all the time - well, too often. And on their own hardware too.

I wouldn't mind if Swift dies, I'm glad Objective-C is no longer relevant. In fact, I can't wait for Swift to die sooner.

WaldoDude2• 5 months ago

Swift has it's problems, and I certainly wouldn't use it for anything outside of development for Apple platforms, but saying they had no experts on the team is a stretch. Most Swift leads were highly regarded members of the C++ world, even if you discount Chris Lattner.

unsnap_biceps• 5 months ago

I think they were meaning that there were no swift experts on the LadyBird team

stephc_int139• 5 months ago

I meant no Swift experts in the Ladybird team. Their expertise is C++, you may think the transition is easy, and it can be pretty painless at first, but true language expertise means knowing how to work around its flaws, and adapting your patterns to its strenghts. Cool for a hobby, but switching language in the middle of an herculean work is suicide.

TbobbyZ2• 5 months ago

What language do you recommend?

stephc_int139• 5 months ago

The best tool for the job is the one you know and love.

zozbot2343• 5 months ago

The point of Swift is not really the language, it's the standard ABI for dynamic code. The Rust folks should commit to supporting it as a kind of extern FFI/interop alongside C, at least on platforms where a standard Swift implementation exists.

fud1012• 5 months ago

is go the same? what is the consensus best pick right now I wonder, is it C#?

layer8• 5 months ago

Best pick for what? It always depends, and there is certainly no consensus.

xannabxlle• 5 months ago

Great, some languages do not need to be hack into a project.

pbohun4• 5 months ago

There's no way to say this without sounding mean: Everything Chris Lattner has done has been a "successful mess". He's obviously smart, but a horrible engineer. No one should allow him to design anything.

Edit: I explained my position better below.

refulgentis8• 5 months ago

Everything Chris Lattner has done has been a "successful mess".

I don't have an emotional reaction to this, i.e. I don't think you're being mean, but it is wrong and reductive, which people usually will concisely, and perhaps reductively, describe as "mean".

Why is it wrong?

LLVM is great.

Chris Lattner left Apple a *decade* ago, & thus has ~0 impact or responsibility on Swift interop with C++ today.

Swift is a fun language to write, hence, why they shoehorned it in, in the first place.

Mojo is fine, but I wouldn't really know how you or I would judge it. For me, I'm not super-opinionated on Python, and it doesn't diverge heavily from it afaik.

carefree-bob3• 5 months ago

Not just LLVM, but Google's TPU seems to be doing fine also. Honestly it's an impressive track record.

dismalaf5• 5 months ago

That's why there's nothing that comes close to LLVM and MLIR, right?

If he's such a horrible engineer then we should have lots of LLVM replacements, right?

pbohun4• 5 months ago

QBE is a tiny project, but I think illustrates a better intermediate language design. https://c9x.me/compile/

levodelellis6• 5 months ago

Many compilers including my own uses C89

bahmboo4• 5 months ago

You don't explain or support your position, you are calling Lattner names. That's not helpful to me or anyone else if we are trying to evaluate his work. Swift has millions of users as does Mojo and Modular in general. These are not trivial accomplishments.

satvikpendem6• 5 months ago

Mojo and Modular have millions of users?

pbohun4• 5 months ago

People are correct I didn't explain my position.

LLVM: Pretty much everyone who has created a programming language with it has complained about its design. gingerbill, Jon Blow, and Andrew Kelley have all complained about it. LLVM is a good idea, but it that idea was executed better by Ken Thompson with his C compiler for Plan 9, and then again with his Go compiler design. Ken decided to create his own "architecture agnostic" assembly, which is very similar to the IR idea with LLVM.

Swift: I was very excited with the first release of Swift. But it ultimately did not have a very focused vision outlined for it. Because of this, it has morphed into a mess. It tries to be everything for everyone, like C++, and winds up being mediocre, and slow to compile to top it off.

Mojo isn't doesn't exist for the public yet. I hope it turns out to be awesome, but I'm just not going to get my hopes up this time.

jervant• 5 months ago

How many languages are using LLVM as its backend vs Go's?

levodelellis6• 5 months ago

Yes. I also written a compiler and I also complained about LLVM.

LLVM is

  - Slow to compile
  - Breaks compilers/doesn't have a stable ABI
  - Optimizes poorly (at least, worse than GCC)

Swift I never used but I tried compiling it once and it was the bottom 2 slowest compiler I ever tested. The only thing nearly as bad was kotlin but 1) I don't actually remember which of these are worse 2) Kotlin wasn't meant to be a CLI compiler, it was meant to compile in the background as a language server so it was designed around that

Mojo... I have things I could say... But I'll stick to this. I talked to engineers there and I asked one how they expected any python developers to use the planned borrow checker. The engineer said "Don't worry about it" ie they didn't have a plan. The nicest thing I can say is they didn't bullshit me 100% of the time when I directly asked a question privately. That's the only nice or neutral thing I could say

saagarjha2• 5 months ago

LLVM: Pretty much everyone who has created a programming language with it has complained about its design. gingerbill, Jon Blow, and Andrew Kelley have all complained about it. LLVM is a good idea, but it that idea was executed better by Ken Thompson with his C compiler for Plan 9, and then again with his Go compiler design. Ken decided to create his own "architecture agnostic" assembly, which is very similar to the IR idea with LLVM.

I suggest you ask around to see what the consensus is for which compiler is actually mature. Hint: for all its warts, nobody is writing a seriously optimized language in any of the options you listed besides LLVM.

lenkite• 5 months ago

Chris Lattner is definitely a genius engineer at innovation, implementation and delivery but long-term, robust, maintenable software-design doesn't appear to be in his capability set.

The latter is definitely a defining capability of Anders Hejlsberg. (C#/Typescript designer)

meisel• 5 months ago

Why did Ladybird even attempt this with Swift, but (I presume) not with Rust? If they're going to go to the trouble of adding another language, does Rust not have a better history of C++ interop? Not to mention, Swift's GC doesn't seem great for the browser's performance.

mlinksva• 5 months ago

https://x.com/awesomekling/status/1822236888188498031 https://x.com/awesomekling/status/1822239138038382684 "In the end it came down to Swift vs Rust, and Swift is strictly better in OO support and C++ interop."

refulgentis8• 5 months ago

Swift is strictly better in OO support and C++ interop

Fascinating.

They've shown the idea it is better on C++ interop is wrong.

I don't know enough to say Rust has same OO support as Swift, but I'm pretty sure it does. (my guess as a former Swift dev: "protocol oriented programming" was a buzzy thing that would have sounded novel, but amounted to "use traits" in rust parlance)

EDIT: Happy to hear a reply re: why downvotes, -3 is a little wild, given current replies don't raise any issues.

ckcheng2• 5 months ago

In the end it came down to Swift vs Rust, and Swift is strictly better in OO support and C++ interop

Why not D?

archargelod• 5 months ago

Did they consider using Nim? It has great C++ interop, OO and same ARC memory management as in Swift.

lukeh• 5 months ago

Swift actually has excellent C++ interop [1] (compared to other languages, but, I guess, not good enough for Ladybird).

[1] https://www.swift.org/documentation/cxx-interop/

palata4• 5 months ago

I actually looked into that recently (calling C++ from Swift), and I was surprised by the amount of limitations.

Said differently: the C++ interop did not support calling the C++ library I wanted to use, so I wrote a C wrapper.

bergheim• 5 months ago

I so wholeheartedly agree. You are making a new web browser - akin to a new OS - and you want it open source for everybody but you choose swift not rust?

rvz4• 5 months ago

This experiment has shown that both are actually bad choices.

carefree-bob3• 5 months ago

The ladybird developers tried Rust and Swift both and voted to adopt Swift.

password4321• 5 months ago

It will be interesting to see any further justification; I believe Rust was rejected previously because of the DOM hierarchy/OOP but not sure IIRC.

20240810 https://news.ycombinator.com/item?id=41208836 Ladybird browser to start using Swift language this fall

jll292• 5 months ago

Andreas Kling said Rust lacks OO, which he says is useful for GUI coding.

He even made an attempt at creating his own language, Jakt, under SerenityOS, but perhaps felt that C++ (earlier with, now without Swift) were the pragmatic choice for Ladybird.

stingraycharles2• 5 months ago

But wasn’t Rust designed specifically for being a language for developing a rendering engine / web browser?

elcritch• 5 months ago

Also I believe one of the core LadyBird devs was an ex Apple employee on WebKit which has been using Swift as well.

LeFantome9• 5 months ago

The Ladybird founder was one of the original KHTML devs and worked on Safari at Apple.

saagarjha2• 5 months ago

I’m not even sure he was at Apple when Swift came out. WebKit integration is very recent.

diath5• 5 months ago

Why did Ladybird even attempt this with Swift, but (I presume) not with Rust? I

Probably the same reason why Rust is problematic in game development. The borrow checker and idiomatic Rust do not go well together with things that demand cyclic dependencies/references. Obviously there are ways around it but they're not very ergonomic/productive.

gardaani• 5 months ago

Here's Andreas Kling's general thoughts on Rust:

- Excellent for short-lived programs that transform input A to output B

- Clunky for long-lived programs that maintain large complex object graphs

- Really impressive ecosystem

- Toxic community

https://x.com/awesomekling/status/1822241531501162806

alper3• 5 months ago

I think that's fair. Funny to have a language that makes it prohibitively difficult to use most of the core computer science constructs (lists, graphs etc.).

sparky4pro• 5 months ago

Swift != GC

ozgrakkurt• 5 months ago

I remember watching the project lead say something like “the developers just don’t enjoy rust”

generalpf• 5 months ago

Swift doesn't use a garbage collector.

myko• 5 months ago

ARC is GC, Swift definitely uses GC.

It isn't a _tracing_ GC

noobermin• 5 months ago

I hate to be the one to point this out but really, in 10 years, how many rust ports will face the same fate?

tvshtr8• 5 months ago

none

hu32• 5 months ago

some? It can happen with any language.

nylonstrung• 5 months ago

Hard to feel excited for this project when it feels so handwavey and when basic technical decisions have never been nailed down.

What are other projects trying something similar that deserve attention?

tredre3• 5 months ago

when it feels so handwavey

Carefully making decisions and then reassessing those choices later on when they prove to be problematic is the opposite of handwavey...

LeFantome9• 5 months ago

What projects are trying something similar to Ladybird? Well, mobody really. But Servo is pretty close though they are not writing their own Javascript engine or anything.

But you should perhaps give your attention to Servo. They were founded as a project to write a modern browser in Rust. So, no hand-waving there.

No hand-waving on the Ladybird team either in my opinion. They have very strong technical leadership. The idea that building a massive application designed to process untrusted user input at scale might need a better language than C++ seems like a pretty solid technical suggestion. Making incedible progress month after month using the language you started with seems pretty good too. And deciding, given the progress buidling and the lack of progress exploring the new language, that perhaps it would be best to formally abandon the idea of a language switch...well, that seems like a pretty solid decision as well.

At least, that is my view.

Oh, and I was a massive Servo fan before the Ladybird project even began. But, given how much further Ladybird has gotten than Servo has, despite being at it for less time and taking on a larger scope...well, I am giving my attention to Ladybird these days.

This comment was written in Ladybird.

drnick14• 5 months ago

Regardless of the language it is written in, one thing that I hope Ladybird will focus on when the time comes is a user-respecting Javascript implementation. Regardless of what the Web standards say, it is unacceptable that websites can (ab)use JS against the users for things such as monitoring presence/activity, disabling paste, and extracting device information beyond what is strictly necessary for an acceptably formatted website. One approach could be to report standardized (spoofed) values across the user base so that Ladybird users are essentially indistinguishable from each other (beyond the originating IP). This is more or less the approach taken by Tor, and where a project like Ladybird could make a real difference.

diath5• 5 months ago

There's just too many defense mechanisms on popular websites that would simply make Ladybird flagged as a bot and render the website unusable. I wouldn't mind a toggle to switch between this and normal behavior but having that as a default would be bad for wider adoption.

drnick14• 5 months ago

If those "popular websites" are the likes of Facebook and Instagram, I don't see that as a big loss. That being said, I find that most of the Web works just fine on Tor, so it's certainly possible. Most of the issues seem related to the (known) the exit IP being overused or identified as Tor.

bluGill3• 5 months ago

Only if there is not widespread adoption.

mvdtnz2• 5 months ago

A web browser that explicitly does its own thing regardless of web standards is the last browser in the world I would consider using.

WoodenChair• 5 months ago

Their Mac UI is a thin layer of AppKit. Even there they're currently using Objective-C++ it looks like, not Swift:

https://github.com/LadybirdBrowser/ladybird/tree/master/UI/A...

trflynn89• 5 months ago

Hi, I'm the one who originally wrote Ladybird's AppKit UI. Just FYI, it was written long before Ladybird split from SerenityOS, and even longer before Swift was on the table. I only chose Objective-C++ because it was the language I was familiar with at the time :)

miffy9003• 5 months ago

As someone who first began using Swift in 2021, after almost 10 years in C#/.NET land, I was already a bit grumpy at how complex C# was, (C# was 21 years at that point), but then coming to Swift, I couldn't believe how complex Swift was compared to C# - Swift was released in 2014, so would've been 8 years old in 2022. How is a language less than half the age of C# MORE complex than C#?

And this was me trying to use Swift for a data access layer + backend web API. There's barely any guidance or existing knowledge on using Swift for backend APIs, let alone a web browser of all projects.

There's no precedent or existing implementation you can look at for reference; known best practices in Swift are geared almost entirely towards using it with Apple platform APIs, so tons of knowledge about using the language itself simply cannot be applied outside the domain of building client-running apps for Apple hardware.

To use swift outside its usual domain is to become a pioneer, and try something truly untested. It was always a longshot.

belmont_sup• 5 months ago

Not to mention how heated my laptop gets when I try to compile a new vapor template. On an m1.

VerifiedReports2• 5 months ago

I started using it around 2018. After being reasonably conversant in Objective-C, I fully adopted Swift for a new iOS app and thought it was a big improvement.

But there's a lot of hokey, amateurish stuff in there... with more added all the time. Let's start with the arbitrary "structs are passed by value, classes by reference." And along with that: "Prefer structs over classes."

But then: "Have one source of truth." Um... you can't do that when every data structure is COPIED on every function call. So now what? I spent so much time dicking around trying to conform to Swift's contradictory "best practices" that developing became a joyless trudge with glacial progress. I finally realized that a lot of the sources I was reading didn't know WTF they were talking about and shitcanned their edicts.

A lot of the crap in Swift and SwiftUI remind me of object orientation, and how experienced programmers arrived at a distilled version of it that kept the useful parts and rejected dumb or utterly impractical ideas that were preached in the early days.

raw_anon_11112• 5 months ago

But there's a lot of hokey, amateurish stuff in there... with more added all the time. Let's start with the arbitrary "structs are passed by value, classes by reference." And along with that: "Prefer structs over classes."

This is the same way that C# works and C and C++ why is this a surprise?

fingerlocks3• 5 months ago

Nowhere does it say structs provide “one source of truth”. It says the opposite actually- that classes are to be used when unique instances are required. All classes have a unique ID, which is simply it’s virtual memory address. Structs by contrast get memcpy’d left and right and have no uniqueness.

You can also look at the source code for the language if any it’s confusing. It’s very readable.

zffr• 5 months ago

Prefer structs over classes != only use structs.

There are plenty of valid reasons to use classes in Swift. For example if you want to have shared state you will need to use a class so that each client has the same reference instead of a copy.

ChrisMarshallNY2• 5 months ago

I think Swift was developed to keep a number of constituencies happy.

You can do classic OOP, FP, Protocol-Oriented Programming, etc., or mix them all (like I do).

A lot of purists get salty that it doesn’t force implementation of their choice, but I’m actually fine with it. I tend to have a “chimeric” approach, so it suits me.

Been using it since 2014 (the day it was announced). I enjoy it.

sumuyuda• 5 months ago

when every data structure is COPIED on every function call

Swift structs use copy on write, so they aren’t actually copied on every function call.

fud1012• 5 months ago

So did you go back to and keep using C#/NET?

miffy9003• 5 months ago

well for backend development, yes - I technically never stopped as I had existing projects to maintain. But after trying out Swift a couple times, I've dropped it entirely for backend. For new backend work it's C#/.NET all the way.

I wanted to try using a native language other than C++ and Swift ostensibly seemed easier to pick up. I continue to use Swift for iOS app development though where it is much easier to use; but that has its own share of compromises and trade-offs - but not centred around Swift, around SwiftUI vs UIKit.

librasteve5• 5 months ago

In the last years, simplistic languages such as Python and Go have “made the case” that complexity is bad, period. But when humans communicate expertly in English (Shakespeare, JK Rowling, etc) they use its vast wealth of nuance, shading and subtlety to create a better product. Sure you have to learn all the corners to have full command of the language, to wield all that expressive power (and newcomers to English are limited to the shallow end of the pool). But writing and reading are asymmetrical and a more expressive language used well can expose the code patterns and algorithms in a way that is easier for multiple maintainers to read and comprehend. We need to match the impedance of the tool to the problem. [I paraphrase Larry Wall, inventor of the gloriously expressive https://raku.org]

grey-area3• 5 months ago

Not sure how I feel about Shakespeare and JK Rowling living in the same parenthesis!

Computer languages are the opposite of natural languages - they are for formalising and limiting thought, the exact opposite of literature. These two things are not comparable.

If natural language was so good for programs, we’d be using it - many many people have tried from literate programming onward.

integralid• 5 months ago

But writing and reading are asymmetrical and a more expressive language used well can expose the code patterns and algorithms in a way that is easier for multiple maintainers to read and comprehend.

It's exactly the opposite. Writing and reading are asymmetrical, and that's why it's important to write code that is as simple as possible.

It's easy to introduce a lot of complexity and clever hacks, because as the author you understand it. But good code is readable for people, and that's why very expressive languages like perl are abhorred.

spongebobism• 5 months ago

Perlis's 10th epigram feels germane:

Get into a rut early: Do the same process the same way. Accumulate idioms. Standardize. The only difference(!) between Shakespeare and you was the size of his idiom list - not the size of his vocabulary.

i_am_a_peasant• 5 months ago

same. i thought it would have been as quick to pick up as rust. nowhere near. i spent weeks trying to go through every feature of the language at least once. time in which i could’ve read several rust books and already start hacking up some interesting projects. so much in swift is pointless syntax sugar. why do i need 50 ways to do exactly the same thing, it’s just nonsense. then i have to look up the language reference whenever i read a new codebase

alper3• 5 months ago

Swift is Apple's toy language and they cannot and will not allow it to be anything more than that.

Closing this as we are no longer pursuing Swift adoption

Related Stories