Hacker News Reader

Comment by mr_00ff00 | Hacker News Reader

I know this might be opening a can of worms, but technically doesn’t Swift do reference counting? Which is faster than “mark and sweep” GC but will never compare to manual management (like C/C++ and rust ownership)

I assume that’s the big reason.

View on HN

Reference counting is not faster than tracing GC for general purpose workloads, at least not without a lot of extensive tuning that includes stuff like using tracing and moving GC for the young generation (prior to the first collection), deferring reference count increment/decrements using write barriers, limiting reference count bits (and reclaiming stuck objects with some variant of full heap tracing), and so on. Many of these benefits cannot be effectively realized if you insist on prompt execution of finalizers, either. Languages like Rust and C++ gain their performance benefits not from using reference counting or immediate reclamation, but from avoiding creating garbage in the first place by stack allocating most stuff, creating large objects by-value and within vectors to reduce pointer chasing, using direct interior references into data structures in ways that it would be difficult to trace efficiently, and using data structures like arenas to emulate the benefits of generational GC in controlled contexts where a maximum lifetime can be statically determined.

My personal feeling is that it's very hard to directly compare manual memory management and GC from a performance perspective because so many of the techniques that make tracing fast involve moving pointers, which is very costly to combine with many of the techniques that make manual memory management fast which rely on values not moving in memory. I think any such solution that is efficient for both kinds of memory will probably require the programmer to have very tight control over when the garbage collector can execute, whether pointers can move at particular times, etc., and the complexity of maintaining that kind of control (and getting it right!) seems so high that I'm not sure it would ever be usable for general purpose programming.

The Swift compiler does some of the optimizations/techniques you mention Rust does. It won't reference count, when the setup is possible to analyze statically and elide ref count. Swift also has widely used complex value types, which are stored on the stack. It will also even put some reference types on the stack after doing escape analysis etc.

I don't know which benchmark to trust anymore, but for some reason iOS software tends to seemingly overperform comparable ART (GC) code.

Value types are stored wherever appropriate. If they escape they’re going on the heap like everything else.

If they are very large and implement copy-on-write, sure, parts of them may be on the heap. But they don't need to be on the heap if they escape if they're just returned by copy.

s/very large/a couple of words/

I think you’re missing the context that people are choosing Rust over Swift even in domains like backend web development which should theoretically be a good fit for Swift. And this is largely because the Swift ecosystem outside of Apple is pretty minimal.

And frankly, I have zero confidence that Apple will sufficiently invest in the language outside of their ecosystem. That's just not how Apple operates.

That's definitely the elephant in the room.

And the fact that it does not have clean and easy C integration.

If you could do direct memory stuff and control the ARC stuff, and easily integrate with C ...

... and the docs were clean, and you could easily use something other than XCode ...

Then Swift would be huge.

It's a neat language but it's just not designed to go beyond Mac.

The entire C++ world would move away in an instant to something clean and flexible. Rust is just too specific for most things, and Swift is just about outside. So sad.

Using VSCode instead of Xcode should work fairly well:

https://www.swift.org/blog/vscode-extension/

https://marketplace.visualstudio.com/items?itemName=sswg.swi...

I've found Swift->C to interop very well with Swift. Yes, you get absolutely buried in UnsafeXXX wrapped types but it does do exactly what you expected. Going the other way is somewhat "herebe dragons" since @_cdecl is technically non-standardized (though there is a movement to standardize it [1]) but it definitely works fine.

[1] https://forums.swift.org/t/formalizing-cdecl/40677/7

What do you mean about rust being too specific for most things? It seems like a fairly obvious choic for c++ replacement in a new project, the issue is large c++ codebases already exist, and that migration is painful in my experience. Autocxx type support is still largely missing or in work, diplomat seems reasonable, but I haven't had an opportunity to use it for something real yet.

I think for Rust to truly replace C++, it needs a better dynamic linking story. I wish they would make their ABI stable within a given edition. That would make it much easier for people to rely on dynamic linking, similar to how C++ does it. Without it, Rust binaries are quite huge.

The stable ABI in Rust is called the C ABI. Which means you can write C compatible dylibs/.so in Rust that can be used by any language with a C FFI. This is used in the real world for seamless rewrites of existing dynamic libraries in Rust - librsvg being a well-known case. You don't need all the hacks OP is talking about.

Sure, dropping down to a C interface is easy enough, but far from ideal. So much of Rust's expressive power is lost by doing so. What would be the downside of providing a stable ABI for an edition? It seems to me it resolves both sides of the argument on stable ABIs. By the way, I'm mostly thinking about Rust -> Rust dynamic linking.

In C++ land, classes are a part of the stable ABI. Pretty much everything is, except for templates (but including explicit template specializations).

I think that is a good idea, but dynamic linking seems to be reserved for system level stuff like glibc. When even embedded arm7 targets are shipping as comtainers, what difference does it make if we use dynamic or static linking within that container? The dynamic libraries aren't getting used by multiple executables anyway. The main case I see is to protect yourself from a copy-left license impacting all the bsd and mit stuff from crates.

Rust will not replace C++. Everything is thrown out the window, including developer productivity in order to provide the 'zero overhead runtime guarantee' feature. The code ends up quite laborious, and it's just not suitable for many things, and it doesn't play so easily with C.

Most projects do not require what Rust provides at the cost it provides it at.

C++ people really wants a C++ that is clean, modern, parsable, without all the legacy cruft.

Also I think that Rust is a 'V1' version of a borrow checker and I can't wait for newer iterations which I think will be better.

> Most projects do not require what Rust provides at the cost it provides it at.

If this is true, it's because most projects should use a GC'd, memory safe language, not because most projects should use memory unsafe languages. There is little to no place for memory unsafe languages such as C++ for new projects in 2023.

> Also I think that Rust is a 'V1' version of a borrow checker and I can't wait for newer iterations which I think will be better.

This is the literal definition of vaporware, without a specific plan for how "newer iterations" will do it better. People have been searching for silver bullets for years in this space and nobody has really found a way to improve on the balance Rust has found without introducing garbage collection of some kind. I personally don't believe a "better borrow checker" can exist without GC (which is not such a bad thing, by the way--in my experience, C++ and Rust developers tend to be unfairly dismissive of garbage collection).

Swift is memory safe. It’s the better C++ I want, just out of reach because Apple. There is at least one memory safe alternative to Rust that doesn’t require a GC.

I’ve made this argument before but here we go again. GC is great and works better and faster than reference counting in most cases, but there are degenerate cases and they matter on phones. One degenerate case is memory pressure. A GC running out of memory will perform terribly. Another case is bounded latency. Most obvious with hard real-time, but also a problem for any system where a long GC pause will lead to failure modes or user dissatisfaction. RC allows for predictable (albeit slower) performance.

So if we can agree that “no GC” is preferable in a constrained environment like a phone, but you still want memory safety, then you are left with “is Swift or Rust better for productivity?” It’s pretty obvious that the answer is resoundingly “Swift”.

Ubiquitous ARC has even worse performance than tracing GC. Only Rust gives you complete memory safety with fine-grained control over memory management strategy.

Swift has some tricks to make things faster than naive ARC, but the point is that you trade a little speed for deterministic behavior. The post I was replying to was making the argument I see frequently. That if not Rust, you should go GC. This is simply wrong. The degenerate GC cases can be avoided with Swift. It’s better for a phone application in nearly every case. If it wasn’t bound to Apple, I’d say it’d be a better choice than Rust in 90% of the places Rust is used.

Rust has its place, but the idea that it’s the obvious and only replacement for C++ is overblown. A language like Swift seems like a better path forward.

Rust isn't the only one with affine types, only the one that has managed more mindshare.

None of the other languages you're thinking of are particularly usable as industrial strength languages for general purpose programming, for reasons that go way beyond mindshare.

Mind reader?

I don't need to be a mind reader because I know which languages other than Rust support sound affine types. They broadly fall into three categories:

* Languages with comprehensive support for affine types, but that are otherwise too limited to be really useful for general purpose programming. Usually this is due to a lack of industry support.

* Languages with bolted on support for affine types where you can't get consistent performance benefits out of code written in that style and it's very difficult to write and compose code written in that style.

* Complex languages with advanced type systems that can emulate affine types, and are extremely powerful, but are borderline unusable for any purpose.

Like I said, whichever of those three language categories you're thinking of, my reasoning applies. No mind reading necessary! I understand though that you believe safe concurrency has been solved since Modula 3 because you can just lock every object while it's in use (why didn't anyone else think of that?), so maybe you don't really appreciate the vast gulf in usability between affine types in these kinds of languages and in Rust.

See you don't know which languages I mean.

I never said such thing about Modula-3, but I do believe indeed that Rust doesn't solve the concurrency problem when accessing external resources in distributed computing.

It is nice it has an answer for data concurrency for internal in-memory data structures, that is a tiny slice of solving distributed computing access patterns.

Like those languages that you "know", Rust's place is being specialized on deployments where no form of automatic memory management is allowed.

Nice goal post moving. So which imaginary language with affine types are you referring to? Being specialized doesn't automatically mean being industrial strength or usable.

"Only Rust gives you complete memory safety with fine-grained control over memory management strategy."

Yes, and it comes at a cost. Pay that cost for those advantages if necessary. Otherwise, use something else.

Reference counting is a form of garbage collection, and therefore Swift is a GC'd language.

Most C++ apps are mostly memory safe and that's just fine. It's ridiculous to suggest that this secondary artifact concern is raised to primacy for all projects.

Rust V1 is a vastly complicated and verbose language, slow to make, slow to write, difficult to integrate, which offers really only one glorious feature that's not important to such a degree for most projects. To suggest wanting something better has nothing to do with vapourware.

Hypersensitivity over a compiler might be a sure sign in a cult!

> Most C++ apps are mostly memory safe and that's just fine. It's ridiculous to suggest that this secondary artifact concern is raised to primacy for all projects.

It's demonstrably not "just fine", as the steady stream of security issues that hurt real people will attest to. It's also important to remember that C++ is an extreme outlier here: the majority of programs written in 2023 are in memory-safe languages. Memory safety is not some weird new thing; it's the norm everywhere but in C and C++, usage of which declines every year.

I think Jasmer has a good point about c++ users wanting a safe enforced subset. I jave suggested a cpp23{} to denote code where the compiler is free to break anything older and enforce best modern practices. Its like a version of safe{} vs unsafe{}

I don't agree that rust is particularly difficult to use, and certainly not verbose. My productivity level is not as high as pytorch or matlab, but it is already on par with c++17 and I've been using that for ~5yrs (c++ for 30yrs) and I've only been using rust for work projects for a year.

Lastly I agree that memory safety isn't a small thing. 70% of security vulnerabilities MS and google find they say are memory safety related. 70% of the financial losses due to security vulnerabilities is... A really big number. And rust, unlike a GC language like java, go, swift, or c#, isn't just memory safe, the borrow checker adds thread safety and more generally safe access to any resource, like file or network io. That is a huge benefit in any domain, and the cognitive overhead just isn't that high.

Swift has better C integration than Rust does.

After using Rust for my own personal tryouts, I liked it more than expected, and though I see the value in the borrow-checker don't work in areas where it's warranted.

In most of my uses, I would be fine always using Rc/Arc which would make Rust equivalent to using Swift.

As a language though, I much prefer Rust to Swift.

indeed. RC isn't universally faster than GC - it depends on workload

If reference counting was faster, Java would do it. It’s better for UIs and lower latency, but a modern, generational GC can beat C in throughput (because allocations get a lot faster).

Genuine question, but if that were true then why does High Frequency Trading and Performance critical applications use C if GCs can beat it?

The two biggest languages I'm aware of in that space are Java and C++. I don't think I've heard of any shop using C. Java seems to be keeping up with C++ there as far as I know. Do you have evidence to the contrary?

Yeah I guess I used C and C++ interchangeably, but I believe C++ is the language of HFT.

Do you have evidence to the contrary?

"Why we chose Java for our High-Frequency Trading application"

https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-...

I don’t think your article makes the claim Java keeps up with C++. That article seems to be about getting latency low and consistent so Java can compete with C++.

It keeps enough when the measurement is delivering products into production, that is what matters to business owners, not winning language benchmarks.

Fair enough, although is Java specifically the only language that could do this?

It surprises me that people turn to Java instead of say Go or Elixir or (keeping on topic with the article) Swift?

There is a long tail of other languages. JaneStreet uses Ocaml. I wouldn't be surprised if there was some usage of Go out there. I'm familiar with at least one trading house that uses Elixir. The bulk of it is Java or C++ though.

Due to language features, ecosystem and tooling, neither Go nor Elixir are even close, in what Java has improved upon since 1996.

Swift is mostly Apple platforms.

HFT often does use languages that run on GCs.

Because that is _very_ latency sensitive, not throughput sensitive.

GC has worse p99 latency, even if it may have better throughout.

Also, with manual memory management, you can do all your allocs and frees on other threads that are not executing your latency sensitive logic.

With GC, you have to at least execute a stack scan on every thread, and possibly a few extra stw passes. The highest performance gcs also have a lot of peanut butter costs from read barriers.

If Java cared about being fast it'd have value types.

That is the whole point of Valhala, which is a big engineering effort to achieve keeping running those old world JARs without doing a Python 2/3, we already have enough with Java 8 stagnation.

reference counting is not necessarily faster.

It’s not faster in the normal case, it’s generally quite a bit slower. It is more predictable however (you can actually use it with real-time constraints!), and performs better under memory pressure. Whether this is a net benefit depends on what hardware you’re running on and what the app is supposed to be doing.

That's certainly a reason, but Go doesn't have the adoption issues that Swift has despite Google's reputation. Go's GC may be fast, and on some workloads maybe even competitive against ARC - But, I really don't think that has anything to do with why Swift isn't seeing widespread adoption outside of the Apple ecosystem.

Here's my personal opinion for why. Bear with me for a second.

I just searched "Swift programming language" on my search engine and the first result looks promising:

> https://developer.apple.com/swift/

OK. It's a language by Apple, so it's not surprising that it's on Apple's website, even though I think if you want people to get the idea that it's a serious independent project you probably should give it its own top-level site personally. (edit: Yes, I know it does. This is my honest first impression. Please keep reading.)

> Swift is a powerful and intuitive programming language for iOS, iPadOS, macOS, tvOS, and watchOS.

Alright, we're only talking about Apple platforms. Technically it doesn't say that it can't work outside of these OSes, but it's clear that Apple is not marketing Swift as a general purpose operating system. From Apple's marketing PoV, it's an operating system that is made for Apple platforms and anything else is incidental.

> Download Xcode and learn how to build apps using Swift with documentation and sample code.

No download links for users of other operating systems. But if you go to that link, all the way at the bottom, you get:

> Swift is developed in the open. To learn more about the open source Swift project and community, visit Swift.org.

Finally, you might notice that Swift is actually available outside of macOS. It's available for Windows and Linux, but not BSD as far as I can ascertain. The platform support of Swift is excellent when it comes to Apple devices, but it lags far behind other options when it comes to other platforms and architectures.

My perception is that Apple hasn't really made a serious enough investment into making Swift a general purpose programming language outside of its own ecosystem. That's honestly fair, as doing so is no doubt extremely expensive and time-consuming, and it's an on-going investment.

What they're doing now appears to kick it to the community, who has done a lot, including as far as I can tell, make Swift work on RISC-V. But Apple is literally the world's biggest technology company, so it's not exactly desirable to put a bunch of community effort into giving it the on-going support that it needs to feel "first-class" outside of Apple platforms.

Even just the optics here are quite bad, and I think the fact that it's still like this is going to haunt the long-term prospects of Swift outside of Apple platforms.

All of this is aside from its technical merits. Normally, I'd like to stick to purely just technical merits, but unfortunately this stuff does matter. It's part of the reason why Go is still a solid choice today even though Rust has a lot of technical advantages on paper.

> OK. It's a language by Apple, so it's not surprising that it's on Apple's website, even though I think if you want people to get the idea that it's a serious independent project you probably should give it its own top-level site personally.

You mean like it does have? https://www.swift.org/

You didn't finish reading the post.

I did. But why would you include a false claim only to contradict yourself? And when, at least for me in Google, swift.org was the top link. It wasn't like it was hard to find. People don't need to go to the bottom of Apple's page on Swift to discover it.

Just to be sure, I Google'd "Swift programming language" again in incognito mode and the first result is still https://developer.apple.com/swift/. Swift.org is listed, but it's so far down the page that I'd have to scroll.

It wasn't really a contradiction, I was giving you my honest first impressions as a not-Swift user. I had no reason to scroll down the result page when the first result is clearly the same Swift I'm looking for. Why wouldn't the first SEO'd result/marketing page be the right thing? I don't have this problem searching for "Go programming language" or "Rust programming language", those both point to their official top-level sites on both Duck Duck Go and Google.

Swift will always have to contend with this problem.

Apple's goal may be is to create a SW ecosystem that mostly only works on Macs. If a Swift application could be easily compiled to run on Windows, it would be much easier for Apple users to switch to Windows or Linux.

And if Swift apps would run happily on all platforms Apple would still have an incentive to make them run fastest on Macs. Therefore it is not a good idea to rely on a computer manufacturer to provide you with a programming language.

Microsoft has plenty of conflicts of interest to contend with, but that hasn't stopped them from being able to make some inroads towards appealing to other platforms. Perhaps it would be unwise to trust that they've "changed" and invest in Microsoft tools or ecosystems, but it's beside the point: I think it's fair to say that Visual Studio Code and TypeScript have achieved widespread success across the board.

I think that Apple could still make Swift a success outside of their own ecosystem if they wanted to. It would probably have a lot of benefits for them to do so too, but they're all pretty long-game gambles (not to mention quite large investments, too.)

Yeah, but if you want top tooling for .NET, the answer is still pretty much Visual Studio on Windows.

The cross platform version of .NET and VS4Mac/VSCode only support a subset of the whole development experience.

Many libraries on the ecosystem are still stuck in .NET Framework, wrappers for COM libraries, or plain Windows APIs, given its Windows focus between 2001 - 2016.

If you want a Visual Studio like experience without everything that is still missing from VS4Mac/VSCode then you need to shell out for a JetBrains Rider license.

Mostly because of the Windows/Visual Studio interests versus Azure folks interests.

Exactly! Microsoft has basically been stifling .NET adoption across platforms. The community reception was really poor when they took away live reload from the CLI, and it was equally bad when they restricted debugging functionality to only the Visual Studio of family products. These things have contributed to fairly limited adoption of .NET outside of the Microsoft ecosystem.

What's crazy is that in .NET's case, Microsoft has it a lot more "free" because the community is willing to go great lengths to just do it themselves. Like for example, the entire Mono ecosystem: MonoDevelop, Xamarin, Unity, etc. has proven quite successful. Now that Roslyn is open source, it should easily overtake Mono... but it hasn't really.

.NET is basically a cautionary tale. It's pretty amusing that the same company that made TypeScript and VSCode popular across platforms is having strategic trouble doing the same for their wildly sought after CLR/.NET ecosystem.

Reply on news.ycombinator.com