Hacker News Reader

Comment by prmph | Hacker News Reader

Well, I guess the response to Rust just means people are still waiting for a language that:

- has a very expressive and sound type system

- provides a good mix of paradigms (functional, imperative, object oriented, etc.)

- uses modern techniques to address the warts of many existing languages (nulls, exceptions, optionality, unsafe memory access, async, etc.)

- is (reasonably) fast

- comes with great tooling and docs

- is mainstream, general, open, and not tied to any particular vendor

Whether they are right to pin these hopes on Rust is one thing, but there's no denying there is still an un-addressed hunger for a next-gen open language that generally addresses many pain points with modern software development.

View on HN

Now that Swift is on other platforms, I think it’s a good fit, especially as Foundation is being rewritten in pure Swift .

Really good ergonomics, safe by default for many cases and getting more of rusts safety for others.

Easy interop with C/ObjC/C++, which is a big deal for me because it’s what’s caused me to write less Rust/C++/Zig at all lately and focus on Swift.

I really, really hope that the energy cross platform Swift has been seeing lately continues and accelerates. It’s not perfect, but I find it productive and enjoyable to write. It strikes a nice balance between being strict and getting out of your way and doesn’t come off as pedantic as some languages with similar syntax.

I think the new C++ interop might help the momentum. Swift is now the easiest language IMHO to bind C++ automatically with.

I really feel like easy interop in languages is the missing key to moving people into more safe languages.

Tooling is also a factor I think. Last time I was playing with writing Swift on Linux, the official LSP with VS Code was alright (surprisingly even supporting debugging) but I found myself wanting a proper IDE.

I doubt it, what makes Swift, just like Objective-C, it is the frameworks and IDE tooling.

GNUStep went nowhere.

Swift on its own is already much more usable than Obj-C is and will only become moreso with the Foundation rewrite. It has a way to go but it’s possible to write useful software with it without Cocoa/GNUStep (especially if one is willing to lean on C or C++ libraries via interop), which was never true of Obj-C.

It was definitely true for Objective-C with GNUStep, or during the time Microsoft had their porting framework into Windows Store (Windows Bridge for iOS).

That extreme dependency on a supporting framework (Obj-C doesn’t even have its own allocator) was a massive weakness though, as has been proven by GNUStep’s stagnation and MS’ abandonment of WinObjC.

Swift has no such issues. It’s weaker without AppKit/UIKit yes, but at least has most of the basics covered. The only real threat is Apple deciding they don’t want cross platform compatibility any more in which case Swift can simply be forked.

Not even Apple is fully supportive of it outside their ecosystem, besides CLI tools and Linux based servers, as stated on Swift's open source website.

Seeing how much engagement Microsoft is having with .NET outside Windows and still failing in many fronts in regards to adoption by non-Microsoft shops, versus the little Apple has invested, I doubt it will really be any different than Objective-C.

But the framework dependency is exactly why I mention the C++ interop and Foundation rewrites.

Swift prior to the interop didn’t interest me as much for cross platform use, primarily due to ecosystem .

That has changed significantly because the ecosystem just magically expanded. I can use most C++ libraries I throw at it. Foundations rewrite means I can use a more comprehensive stdlib everywhere.

IDE tooling is definitely a weak point but I think that’s easier to rectify than ecosystem. The biggest loss has really been the Swift plugin for CLion and the entirety of AppCode for me. But when they were around, they worked very well and so the foundation for it is already there along with the Swift LSP to improve on.

From my experience dual language approach always adds some atriction across the board, in tooling, building infrastructure and debugging layers.

Hence why while I could use C++/CLI on my hobby coding to stay on the confort of .NET, with a couple of bindings being used from C#/F#, I end up using straight C++ instead.

In my experience, it’s the opposite. Most people tend towards the easier language unless they need to be maintaining the bindings or something on the other end.

Perhaps you’re considering mixed language projects. I’m talking about primarily Swift where I can just import C++ libs over. The fact that it’s C++ is easily hidden, especially with the use of SPM.

I think Python is a big example. So many people stay on the Python side for things like Qt.

I tried out Swift on Windows and really enjoyed it. The experience was 100x better than I expected.

Looks like they're looking for OCaml, but sadly it's not as popular as most languages. Dart might fit as well.

JVM and CLR tick all the boxes.

Historically, there were performance complaints, but a lot of these were mitigated (AOT, heavily improved GC..., faster hardware). They are fast enough for a large majority of apps.

And if one feels like using a Rust like type system, there is enough to chose from between Kotlin, Scala, F#, and even Haskell dialects.

There are many people, like me, who dislike anything Java: the language, the runtime/SDK, and anything built on top of these. I even refuse to install anything that requires the JRE. Might be an irrational stance, but my early experience of JRE hogging my machine turned off it forever.

The CLR is supposed to be open now, but in practice, the ecosystem around it is still basically Microsoft.

So more confortable with Apple practices, or happy PinePhone user?

I think Zig is a step in the right direction. The simple syntax feels as pleasant as Go and the manual management allows for very performant software. It makes it easier to write safe programs but definitely isn’t as memory safe as Rust. The day we have a language as simple as Go/Zig and as safe as Rust will be the day we have a perfect language.

IMHO, if you stick to just unsafe rust, it’s got similar ergonomics to Zig. And the lack of safety in Zig to me is a move in the wrong direction for a language created so recently.

The safety is the added complexity because so much of what we regularly do can fail in ways we don’t think about.

The alternative so far has been to introduce some kind of automated memory management like reference counting or a GC.

Rust in fact gets much simpler (but slightly verbose) if you wrap everything in an Arc.

That’s why I say in another comment that Swift is the closest to a more accessible Rust. Granted, until Swift 6, it won’t go as far as Rust for thread safety. But for everything else, it is Rust without having to think about as much while writing.

Reply on news.ycombinator.com