Andreas Kling @awesomekling · 44m
My 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
==============================
I've seen way more people complaining about Rust evangelism and toxicity than I've seen of Rust evangelism or toxicity itself, especially here on HN. Even "Rewrite it in Rust" is something I've mostly only ever seen as a denigrating joke (and usually in response to a project choosing to be rewritten in Rust, not even to calls to rewrite something in Rust). I'm starting to wonder if the Rust toxicity and evangelism are more meme than reality.
Doubtful. If you're running a somewhat known FOSS C or C++ project, chances are you've had to close issues from Rust fanatics aggressively urging you for a rewrite, and shaming you if you object. Nothing has changed in that regard.
In this thread there are two Rust subthreads: someone brought up (and was downvoted) “why not Rust” out of nowhere (evangelism) and this one where we are discussing Rust Evangelism because GP quoted Kling on some separate tweet.
So yes. We mostly seem to discuss Rust Evangelism as a meta thing. Something that has supposedly definitely happened, or is happening somewhere else, just rarely right in front of us in the discussions at hand.[1] I think that qualifies as a meme.
That is exactly the way to put off people, that initially could even be welcoming to hear about what the language is all about.
I realize this is not what people generally are referring to when they complain about the Rust community, but this is the part that annoys me.
Feels like every damn day I see people preaching the Good News of Rust, pointing to things as being the unique and sole property of their preferred language. Except those things have been around for ages, in other languages.
Memory safety? Invented by Rust! Algebraic Data Types? Invented by Rust! Funadamental FP constructs? Invented by Rust! High performance? Invented by Rust!
If instead they just said that they enjoy having all of these things in a single language, well great. But instead it has to turn into a preach fest.
Interesting observation...I have the exact opposite experience. Rust is especially amazing for long last program because you spend twice as much time developing it and then forget about it for the rest of your lives until you have to change something. And just by browsing the code, a flood of contexts come in because its expressed in the language fairly well (This function returns Option because ...., this function is generic over Read because ...)
I think a lot of this is just rumors and maybe one or two high profile people. When I go to discord servers for rust and rust libraries, the help I get is as good as, if not better than support from companies I literally pay.
If you keep such a list, you'll easily recognize projects you better stay away from. For me, this was one of the reasons to keep away from Rust.
I have plenty of my own beefs with rust that I won't go into here, but... it comes out on top for complex projects.
In my humble experience, Rust gives me great confidence that my refactoring will likely be correct, but the type system makes refactoring anything moderately complex very difficult. I tend to paint myself into corners, and the compiler, in it's religious oath of correctness, won't allow a mortal like me to get away with it.
I guess you can dismiss that as a skill issue, but Rust feels like a language that is very tough to iterate with. It's probably something I will reach for when I'm sure of what exactly my program will do, and how it will do it.
- Excellent for short-lived programs that transform input A to output B
- Clunky for long-lived programs that maintain large complex object graphs
To rust purists the latter should be solved through composition of many of the former. This is what happens when constantly going on about the evils of state becomes one of your cultural norms.
That said I recently poked swift for non mac use and was not impressed by the status quo, and am not sure Apple are committed to the exercise. The core language is very nice though.
Switching programming language (or game engine) mid-course is a well known suicidal move.
Who is asking them to use a different programming language? I am not a C++ fan, but it is a lot less risky to stick to it than switching, and this is true for any large projects ran by experts.
In the NGO world using or funding greenfield C/C++ is a great way to make yourself a social pariah I bet.
A corporation wouldn't care, because they're driven by what makes dollars and cents.
But in non-profits (which Ladybird chose to be part of) it's all about ideology.
The only way to get an exemption is if you're doing AI which he isn't.
Most of the time, you’ll be successful. However, nobody seeing your plight would be shocked if your foot eventually gets blown up. To claim this state of affairs is just fine because you’ve done it for years, pitiable.
Also, they’re not doing a massive rewrite:
> The Swift team is also investing heavily in C++ interop, which means there's a real path to incremental adoption, not just gigantic rewrites.
To me, the Tweet does a good job justifying the decision. I’m rooting for Ladybird, and I hope this decision pays off. A modern browser in a modern language sounds like a dream come true.
Yes. But many terrible decisions are taken this same way.
> and I hope this decision pays off
It is terrible when we need to hope for something to succeed because we see that they are clearly doing something wrong but will do it that way anyway because they are strong-willed. Just take the obvious path everybody is pointing to.
Guy doesn't even know Swift yet, wants to rewrite a Chrome/Firefox alternative using it. That's a great recipe for failure. Alright, I need to find another browser project to be delusional about.
You either know something the rest of us don’t or you have made an emotional outburst in the form of an insult.
Write a browser in COBOL for all I care. If it’s open source, it’s still a gift.
Same applies to all C and C++ compiler vendors, that have replaced their proprietary compilers (there are plenty more than just clang/gcc/msvc), with LLVM.
Such is the freedom of Apache/MIT/BSD style licenses.
The browser story is not great for Rust as we can only point to Servo which isn't ready to be used as a daily driver for millions of users. But Arc Browser is written with a combination of Swift and C++ to run on macOS and Windows.
Other than iOS apps, perhaps Swift found another use-case in large C++ code bases thanks to the C++ interop story.
Rust isnt the only compiled language that provides memory safety by default. Swift does as well.
The C++ interop thing I think is massive. But isn’t there also the problem that with Rust you can’t have the equivalent of shared pointers, so you can only have a single reference to one object (sorry I don’t really know Rust, just going from how this has been described to me) which apparently makes representing things like DOMs and abstract syntax trees an absolute nightmare?
Both these constructs use the "clone" trait to iterate the reference count.
I make primarily concurrent and async applications these days so I use Arc a lot for accessing memory that is very large and shared many places, such as context.
I think the real problem is Rust has a lot of rules (that make sense for safety) that take time to understand and most people aren't patient enough to make good software because of corporate conditioning.
I think you mean "one of which is Rust".
I know that is a run-on sentence, but I need to get my exercise.
It's less a "rewrite from the ground up" and more a "this is the main language we'll be using from now on".
As for the reason to stop using C++; honestly what reason isn't there by now. The only reason to still use C++ in this day and age is if you're targeting very non-standard hardware or are developing videogames. The language is memory unsafe in a way that almost every other language isn't (like, even if you don't pick a language with an overly worrywart borrow checker, C++ is remarkably worse at memory management), the standard library is awful and it's stuck with the chain and ball of being a superset of C on it's leg, meaning that every reason why you wouldn't use C also applies to C++ (minus the "C isn't OOP" one).
C++ is not a perfect language, but it works, and they have experts on the team, what they are trying to achieve is difficult enough.
Well, RIP Ladybird, I was hopeful about this project, this seriously makes me sad.
(This is of course by design, Apple intend to use Swift from everything from firmware of things like the Secure Enclave chip, through to the kernel, through to all the apps, but to be able to bring it in gradually with the interop, so not having to rewrite everything from scratch).
But as they say, you choose a language for its ecosystem, not for the language itself.
It would be great if Swift’s open source ecosystem for stuff other than app development grew. It does indeed seem like Apple is pushing for it with stuff like Swift for embedded. The fairly recent presentation about starting to move FoundationDB to Swift[0] was also very interesting. A follow-up on that at some point would be quite interesting to see too, and would inspire confidence if the process is going well. Arc is also a nice example of a cross-platform app written in Swift, with their fairly recent addition of Windows support.
Either way, fingers crossed, and very happy with TFA.
PS: does anybody have experience with async/await in Swift? Is it pleasant to use?
Given that this is Ladybird, which came out of the Serenity OS project (which didn't allow any external code at all), it's not surprising that they didn't prioritize ecosystem when picking a language. I believe they're planning on being less strict about that with Ladybird, but the culture of independence is likely still there.
Swift async/await is quite nice.
The Actor stuff is IMO way oversold - reentrancy issues make it not actually useful for the things that they claim, like querying a database. It’s still a useful construct to have, you just need to be aware of what it does or doesn’t provide.
TLDR: Seems like it uses a global thread pool, where each async method call yields to the runtime. Additionally, you get actors which are special classes with serialized method calls, and everybody other than itself has to call those methods as async. Additionally, you can have custom executors, who, if I understand correctly, still only pass tasks to the global thread pool, but can influence the scheduling order. Finally, you can force functions/actors to run on the main thread (outside of the thread-pool) as iOS requires the UI to run on the main thread.
Interestingly (from an API evolution perspective), async protocol functions can be implemented in classes by synchronous functions, as async in swift means "this could be async". Which plays well with the fact that async functions can call sync ones, but not vice-versa.
Additionally, it has cooperative cancellation (you can basically check if you've been cancelled and react accordingly). Concurrency is by default structured, and cancelling a parent task will cancel its children.
[0]: https://swiftrocks.com/how-async-await-works-internally-in-s...
[1]: https://docs.swift.org/swift-book/documentation/the-swift-pr...
I think that the cross platform story both in terms of developer libraries, experience, and tooling is still much better on .NET, and provides a happy middle ground between something like Swift and Java. With that beings said I hate the options for Mobile/GUI with .NET (MAUI, or AvaloniaUI), and would recommend Java/Kotlin if you want to do that. I want to give a special shout out to F# as I feel like it is the most sensible functional programming language I've ever used, and is a lot less verbose then C#. The only knock against it I have is that it's a smaller community than C# and most of the libraries you use will be written in C# so you need to know a little C# as well to be effective
Unfortunately freebie UNIX, and security was yet decades away to be relevant to governmental regulators, thus they never managed to gain enough mindshare to keep going.
Additionally even with all the .NET team efforts, the technology remains mostly relevant to Microsoft shops.
I seldom see RFPs from UNIX first culture companies, that quote .NET as possible delivery technology.
For example, Avalonia implemented Vulkan back-end some time ago, no C or C++ required: https://github.com/AvaloniaUI/Avalonia/pull/12737
Even then, you are absolutely not married to any of these GUI frameworks, but if are targeting desktop, then Avalonia offers great user experience.
(Also it's a really young language with <5 recurring contributors, of course it's not even on the radar :)
Improving, as in ready now or still far in the future?
What does the current state of Swift look like for Linux and Windows? And how well does the LSP server function today?
Both the VS Code extension and the LSP are open source and seem pretty active, so hopefully they’ll get even better over time.
The package ecosystem does feel sparse, especially coming from doing Node development.
It has smaller AOT binary size, faster application code performance and much bigger ecosystem of GUI libraries and native GUI library bindings (everything you have in C and C++ you pretty much have in C#) which can be used with very low overhead. Not to mention better cross-platform tools and build system.
With that said, I do like and respect Swift, and am curious to see what Ladybird team will do with it.
On a language which doesn't have any safety, doesn't plan on implementing basic features such as incremental compilation, tagged unions, async, or package management and others, and nobody is currently working on? Good luck.
1) Choosing Swift implicitly adds improving the status quo of open source swift to the tasks of ladybird. This obviously expands the already huge scope of the project but also derisks it in some ways because it means the project can have a lasting impact regardless of its goals as a competitive browser. Remember that Rust was tempered as a language through the development of Servo and Ladybird could do the same for the non-Apple Swift ecosystem.
2) It unlocks access to a huge number of Swift developers and offers them a unique open source project to work on rather than just building apps for Apple products. As far as I am aware there is no other major language with such a massive (size of developer base):(open source opportunities) ratio. Ladybird acting as the cornerstone of that community could have mutually beneficial results that improve the development of ladybird while also fostering excitement for open source, non-Apple Swift projects.
Ladybird is a wildly ambitious project. We have N=3(ish) for how long it takes to develop a competitive browser from scratch in C++ even with the support of massive companies behind you and it isn't very fast. Obviously we know it works but Ladybird is on mile 100 of a bicycle race around the globe that started 30 years ago. Staying the course on C++ to me looks like saying "We're already so far behind, we can't afford to stop and add an electric motor!" meanwhile everyone else is still pedaling and you aren't getting any closer.
But it was predictable - Andreas comes from Apple background so.. The other thing is no one can build a browser alone - the ability to attract the right people is what differentiates a mainstream usable browser and a toy one. IOW focusing on adding another language that is not as popular amongst the right developer demographic seems like the wrong thing to focus on at this stage.
Oooh, or maybe I can even contribute now! I've supported Kling via GitHub for a while now and have been stoked about his pivot to building a browser. I never really dreamed of contributing, given C++, but now it feels more achievable.
I just wish they could at least delay it until Swift 6.1, giving time for it to mature. And let the idea to jump right into Swift after 6.0 to age a little more.
Developers have a tendency to jump to new language, new tools, new problems because it is exciting and fun.
That being said, this is a rather odd decision. Why would you go so much out of your way to add yet another compiling stage, yet another language that, far as I can tell, is not getting much traction in this space?
Andreas has demonstrated time and time again that he can't keep his word. He says one thing and does things differently.
That wouldn't be too much of a problem if he didn't accuse others of what he is guilty of, toxicity.
He is also known for bashing other projects to promote his own. I would go help Servo instead. Ladybird isn't going anywhere, same as SerenityOS.
I would say the same thing with any languages switch, except C and C++ as they tend to mix well and coders are usually familiar with both.
But Swift is, in my opinion, the worst possible choice. It is known to be a mess, even criticized by its original maker.
The compilation times are horrendous and nobody in the team is a Swift expert.
When making large architecture decisions on such a complex and difficult project, the people in charge should use all their mental energy on that task, not exploring new idioms or styles.
The only valid explanation that I can think of is that they are being funded to promote Swift.
