Hacker News Reader

Comment by jchw | Hacker News Reader

A lot of people who are invested in the Apple ecosystem have been trying to present Swift as a general competitor to Rust, but no matter how many bullet points you list, as far as I can tell, it hasn't made any progress at all on that front, and I haven't been convinced that it will change to become closer to that any time soon, either.

As far as I can tell, there's really nothing wrong with Swift, and it probably has a lot to offer, but at some point someone's going to need to point out the obvious: basically nobody outside of the Apple ecosystem is considering using Swift for anything. That doesn't mean it's bad, but it's not a competitor to Rust today, and it's not trending in that direction.

View on HN

It's a bummer because I feel like I'd really like Swift if I felt it were a real, durable cross-platform language to spend time learning and using. Some of the trade-offs it makes seem really nice

But I don't feel like Swift on non-Apple platforms will ever be more than a hobby for the Apple org

What's stopping you from using it on Linux, or your platform of choice?

It seems to be supported well enough, and Vapor is a decent toolkit for building a webapp with it.

Speaking as someone with similar feelings… “Well enough” and “decent” are not how I would describe something I’m thinking of investing significant mental time and effort learning and familiarisation building on. I’ve done the basic tutorials and generally like the language ergonomics, it’s not bad, and I kinda like it for the little bit of Apple platform dev I’ve done with it. But it’s basically a different language on any non Apple platform.

My understanding is that it's got second-class Linux support, for now. What happens when Apple loses interest? What about Windows? I don't get a sense of commitment from them outside of their own platforms, and that doesn't make me want to commit to learning or starting major projects in the language (outside of their platforms). If I can't have faith my project's foundation will continue to be solid, then I don't want to build it there; if I know I'll never have an employer who wants to let me use Swift (again, outside of Apple apps) then I don't really want to invest the time to deeply learn it (unless I'm going all-in on Apple apps)

I could do a toy project or an iOS app with it, and maybe I will some day, but it's hard for me to feel like it's worth going past that while this is the feeling I'm getting from Apple

(And I'm not really even blaming/judging them here; it makes total sense they would want to have a modern in-house language that's perfectly integrated with their systems and now their chipsets, and lets them ship more effectively. They don't owe anyone more than that. It's just a shame, for me personally, to think about what else could have been)

Foundation (Swift's stdlib so to speak) is being rewritten as OSS [0] which will unify it between Linux and macOS. Right now, they use a different implementation on each platform

[0]: https://www.swift.org/blog/future-of-foundation/

And that's well and good, it's clear there are some engineers at Apple who would really like to see Swift become something more than just The Apple Language, but at the end of the day they aren't the ones getting to set the priorities. And my (very subjective/anecdotal/external) impression is that the business is just sort of humoring them - maybe Linux support helps a little with internal CI or something - without actually prioritizing multi-platform Swift. If a company with Apple's resources cared about multi-platform Swift, at the business level, we would've seen sterling support yesterday.

For comparison, look at what Microsoft's done with .NET since they started to prioritize multi-platform support.

This is all very hand-wavey. Are you just describing a chicken-and-egg scenario?

Also, Swift probably can compete with Rust, especially when they finish adding Rust-style lifetimes. But the real advantage of Swift is it has a much more "high-level" feel than Rust – it's much more familiar to use than Rust by virtue of having classes and things. Swift also doesn't instantly force you into weeds of dealing with memory management complexity. I think I'm going to enjoy the "drop into manual memory management for hot paths" approach Swift is taking.

I think swift competes more with go than rust.

From an aestethic pov, swift is taking the exact opposite direction than go: it keeps piling on more language features, with much less concerns on keeping the language simple.

As a developer currently working in both, it feels like jumping to another civilisation every time i switch.

I'm particularly interested in this line of thinking, and I'd probably lean the same way. Would love to hear more, why do you think it's a better approach to default to more high-level, with the ability to drop down into manual memory management for hot paths?

Simply because hot paths are less common for a "typical" workload. So you'd want it to be more ergonomic by default. Where possible, jam all optimizations into the compiler so nobody has to think about it. If you can't do that, then allow developers to give the compiler more information even if it's more complex.

Relatedly, it allows the language to help you "first make it work, then make it good".

Not really no. It's not a matter of convincing other people to do support, it's a matter of Apple making a long-term on-going large investment into other platforms. They've definitely made some investments and are still making some more, but they're not enough if their goal is to promote Swift as a general programming language for any platform.

I can make some concrete examples: If Apple wants Swift to be successful in the open source world, it needs to at least get basic "passes test" level of support for the BSDs, and some other less common architectures. Look at the architectures supported by the "golang" package in Debian:

> amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x

Now compare to the list of architectures supported by the Swift package in Debian: ... Oh. There's not one!

If this isn't getting the point across, I don't know what will.

(Side note: There are "official" Swift packages for Ubuntu, even if they're not upstreamed, but they only exist for amd64 and arm64. I know there is "community" support for riscv, which is pretty cool. Still... This is definitely a problem for Swift use in the open source community. Without Swift packages in Debian upstream, for example, I don't even think software based on Swift can be packaged for upstream inclusion.)

I'd say that Swift is more of a general competitor to the likes of C# and Java. The lack of JIT-compiling VM is the obvious difference, but if you set that aside and look at the language itself, I'd say that it's on a similar level of abstraction - a fair bit higher than either Rust or C++.

I would say it is the reverse on what concerns Apple platforms, Rust isn't a competitor to Swift.

It will never have tooling parity with Swift.

Trying to use Rust instead of Swift on Apple platforms is only for those that enjoy the pain of creating ecosystems from scratch.

Definitely! There's only one enormous issue with this outlook: the rest of the world is bigger. Much bigger. Exactly how much bigger depends on who you ask, but it's a lot bigger. Just on the consumer side...

https://gs.statcounter.com/os-market-share

Maybe it doesn't matter because developers prefer macOS, so the rest can be treated as a secondary case? Not even close.

https://survey.stackoverflow.co/2022/#section-most-popular-t...

What about servers? Network services and SaaS are a huge industry, of course. Admittedly, I can't even find a good source for what marketshare macOS has: most "server marketshare" counts seem to exclude it or just merge it in with "UNIX-likes". The number appears to be extremely small. There's definitely some exceptions; I think Imgix has been deploying Macs to the datacenter. However, in order to do so, they essentially had to build custom rack mount equipment for desktop machines... I think it's very safe to say that macOS deployments for services are extremely in the minority, and the majority of macOS data center deployments aren't even for general network services specifically but mainly just for CI.

OTOH, macOS Server and any "server" SKUs of Macs have been discontinued as far as I know.

"Rust isn't a competitor to Swift" is not the zinger in Apple's favor that you think it to be. In fact, Apple would be best to support making Rust work better on Apple platforms if it can't support making Swift work better on other platforms in a much more significant way than it has in the past few years.

And this all makes sense. Apple developers had been extolling the virtues of Objective C for a long time, including how it is superior to C++. I'm not even arguing for or against that PoV, but Objective C had at least pretty good compiler support on platforms outside of macOS and it did nothing for its adoption. The main place you'd see Objective C on other platforms were in software originally written for macOS, like `unar` on Linux. That's mainly it...

Unless you want Swift to fail in the long term, I think this PoV is a very badly losing position.

Your argument seems to contradict itself. On the one hand you say “objective c failed because it was available on multiple platforms, but no one cared” but you also infer “Apple is failing because it hasn’t made Swift available on multiple platforms”.

Is it possible that it just doesn’t matter (for Apple) whether Swift is Apple ecosystem only?

It makes me sad, because I really like Swift. Not enough to become an Apple dev though.

I'm saying Objective C was further along in some regards and it still wasn't enough; the investment that Apple would need to make to make Swift popular across platforms is very non-trivial, and just simply nowhere near where they're at today. That's basically it. They're doing some things with Swift that they never did for Objective C, like making a cross-platform version of Foundation. That helps... but it's not good to start out behind on other aspects.

I'm sure they invested tons into devrel on macOS and that family of operating systems. It's weird to think that they could get away with doing less on other platforms where they're already on a much more competitive and less favorable landscape and still have it work out.

Maybe accounting-wise, it's difficult to justify putting all of this effort into something that will ultimately make it easier to leave your ecosystem. That's fair enough but that makes Swift's cross-platform strategy broken.

Ultimately, they're competing with programming languages that have the level of support they do not, but as far as I can tell they're treating it as more of a tool for developers who are primarily Apple-oriented but wish to deploy software across platforms.

What you are saying makes a good deal of sense. It’s a shame though, as Swift seems a really great language with an interesting value proposition. If it were properly cross platform, you could see it being a real competitor to Rust in luring away C++ devs as opposed to traditional GC (deterministic destruction! Can do RAII! Better handling of real-time constraints! Easy learning curve!). Ahh well.

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.

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

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.

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.

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.

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.

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.

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.

People are busy using Swift rather than trying to religiously advocate for Rust on various websites

One example:

Arc is a webkit powered browser written in swift and is crossplatform: https://twitter.com/hursh/status/1612472691747090432

Don’t think it is yet, and it uses Chromium

No doubt people are busy using Swift, but Apple technology advocates are about as "religious advocates" as they come. And frankly, I'm not trying to say that as some kind of negative. It can be annoying, but clearly Apple users are genuine enthusiasts, even if I can't really see eye-to-eye with them. I do think that this genuine enthusiasm creates some distorted images of the reality of the world, though. The thing is, Apple users are likely so used to having more enthusiasm than competing communities of higher marketshare products and services that it's not surprising at all that the perception is that Rust is all hype. I'm more a Go coder than Rust by SLoC, and Rust has to be one of the most enthusiastically supported languages I've ever seen.

Still, it'd be silly to discredit Rust on the basis of its enthusiastic userbase: it's successful by any measure. It's invading the Linux kernel, the campuses of Amazon, Google, Microsoft, it's going to be in both Firefox and Chromium, and that's really just the beginning. Even if Swift had more collective SLoC than Rust, Rust is clearly on its way to solidifying its place as one of the most impactful programming languages of the past 20 years. That impact is even going to be felt in Swift: when talking about Swift, it is very common to advertise it in terms of Rust. I mean hell, that's basically what this blog post title does: "Look, Swift did something even Rust couldn't!" -- If Rust wasn't so influential, I do not think anyone would bother to compare the two in this way.

for 1 article like this, you get 1000000 ones from "rust evangelists from the Rust Evangelism Strike Force"

both can coexist, yet for the rust crowd only one must prevail

that's what's annoying about rust and its religious community

my previous comment's score is (-1), that speaks for itself don't you think ;)

All that says is that people decided to downvote the comment. I honestly think that's mainly because people feel it is an unfair or flippant characterization; obviously, plenty of people DO write Rust. Even despite the position Apple is able to hold Swift in with iOS, that has not stopped Rust from being similarly popular among professional developers; in Stack Overflow's last survey, double the professional respondents claimed to use Rust than Swift:

https://survey.stackoverflow.co/2022/#section-most-popular-t...

Even if you consider some of the respondents to be lying on purpose to skew the stats, I'm of a mind to believe that failing any real incentive, a majority of the correspondents are likely telling the truth. (The numbers don't show anything too wild, after all: JS on top, and C/C++ having a commanding lead on "modern" alternatives.)

Believe me though, some of my comments in this thread also got downvoted before recovering. The sad thing is, I don't really harbor any ill intent, I'm being blunt because I genuinely want things to be better; after all, if Swift is so good for developers, then I definitely would like to be able to consider it an option, especially considering that Rust is, frankly, a pain in the ass to code in sometimes. Today I do not, and what I need is a louder and clearer signal from Apple, not assurance from a community.

All in all, I am not really disagreeing that Rust has an extremely enthusiastic userbase. But what I am definitely disagreeing with is the idea that it's just hype. From my PoV, I 100% understand the value proposition of Rust. As an alternative to C and C++ it's extremely compelling, and in practice it's being integrated into large and complex applications like web browsers today in core components like the rendering engine, video codecs, etc.

As a closing note, to see why Rust and Swift are different ball games entirely, I feel you only need to ask just one simple question: "Why can't Swift serve the purpose Rust is serving in the Linux kernel, Firefox, Chromium, etc?"—each one has its own answers: insufficient control over memory allocations, interoperability issues, missing support for platforms or CPU architectures, lack of alternative toolchains (believe it or not, both Go and Rust have multiple complete toolchains; see gccgo, rust-gcc, mrustc, and even more if you count less complete implementations), and probably more things that I lack knowledge of. Finally, Rust just simply has more outreach: I can install it from my distribution's own packaging in virtually any Linux distro, it supports a lot of architectures and platforms even if they're not all tier-1, the rustup and cargo tools make it extremely fast and easy to get started, and more. Apple could totally close the gap here, but until they do, I don't feel like investing time into this language is a good idea for me personally. Like I said, I genuinely consider this to be a shame.

Reply on news.ycombinator.com