Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift is a more convenient Rust

blog.namangoel.com

Post reply on HN
Print view View original

111–120 of 318 posts

Re: Swift is a more convenient Rust

#111

Post by afavour »

As someone that’s recently been working on integrating Rust into an iOS Swift app I do agree with a lot of this. I love Rust but the more I’ve used Swift the more I find myself wishing I was just using Swift all the time.

That said, the difference between the two has a lot less to do with the language itself than the world surrounding it. You can use Swift cross platform but it’s very obvious that Apple platforms are the primary target. Rust has a rich and varied package system, about the only assumption most packages make is that you’re using the Rust standard library. By comparison lot of Swift packages (which is a much smaller ecosystem anyway that’s slowly transitioning away from Cocapods, Carthage etc) will lean on OS APIs that won’t work if you compile for Linux or WASM[1].

I want Swift to be a more convenient Rust but it just isn’t there. e.g look at IBM abandoning Swift on the server not that long ago.

[1] for example, this blog post:

https://swiftrocks.com/weak-dictionary-values-in-swift

Discusses making a dictionary with weak values in Swift. It has a homegrown Swift version then discusses using NSMapTable… which isn’t available on Linux. But you wouldn’t know that reading the article because the assumption is that you’re running on an Apple platform.

Re: Swift is a more convenient Rust

#112

Post by panzi »

alex_smart wrote: post #106
noelwelsh wrote: post #13

Hmmm...I disagree with a number of statements in the post but I think the following two hypotheses will make for more interesting discussion than some nitpicks: 1. A large part of why many people love Rust is that it's the first time they've used an ML family language. One of the innovations of Rust was to create a community that felt like home to Unix hackers who weren't programming language nerds. 2. Rust is the fi…

> The languages that dominated the 2000s (Ruby, Python, Javscript, PHP) were all more or less derived from Smalltalk One of these is not like the others. Javascript derives from Lisp (first-class functions, lambdas, closures), not Smalltalk.

Python has those too, although with less convenient syntax (multiline functions (closures) can only be at statement locations).

Re: Swift is a more convenient Rust

#113

Post by robertkrahn01 »

alex_smart wrote: post #106
noelwelsh wrote: post #13

Hmmm...I disagree with a number of statements in the post but I think the following two hypotheses will make for more interesting discussion than some nitpicks: 1. A large part of why many people love Rust is that it's the first time they've used an ML family language. One of the innovations of Rust was to create a community that felt like home to Unix hackers who weren't programming language nerds. 2. Rust is the fi…

> The languages that dominated the 2000s (Ruby, Python, Javscript, PHP) were all more or less derived from Smalltalk One of these is not like the others. Javascript derives from Lisp (first-class functions, lambdas, closures), not Smalltalk.

Brendan Eich used both Scheme and Self as inspirations. Self is a dialect of Smalltalk.

https://en.wikipedia.org/wiki/Brendan_Eich

Re: Swift is a more convenient Rust

#114

Post by 369548684892826 »

afavour wrote: post #111

As someone that’s recently been working on integrating Rust into an iOS Swift app I do agree with a lot of this. I love Rust but the more I’ve used Swift the more I find myself wishing I was just using Swift all the time. That said , the difference between the two has a lot less to do with the language itself than the world surrounding it. You can use Swift cross platform but it’s very obvious that Apple platforms ar…

Swift is in its .NET Framework stage. I’m looking forward to Swift Core!

Re: Swift is a more convenient Rust

#115

Post by benreesman »

the_duke wrote: post #103
benreesman wrote: post #81

Earlier quoted context omitted.

A dramatic over-simplification is that a lazy value referenced by some continuation/thunk is hard to stack allocate in-situ. Now GHC does stack allocate, but it’s hard to count on without really aggressive hinting.

Funnily enough Rust supports exactly that pretty well with async. An `async {}` block is not evaluated, but converted into a generator/state machine that lives on the stack, and that has to be advanced by calling a poll method. You can move it to the heap , but that does not happen automatically. Sharing of values is obviously much more awkward due to mutability and no automatic cloning though.

I know how it works though I remain unconvinced that rustc is dealing with the same scope of problem as GHC in the general case.

But to be clear, anyone with the username the_duke is probably really cool, and you clearly know your stuff as well as having style, so count me as a fan.

Re: Swift is a more convenient Rust

#116

Post by Klonoar »

hardwaresofton wrote: post #83

Am I the only one that dislikes the dot syntax for variants? Zig and Swift do it and I feel like it makes things harder to read, not easier. `.variant` vs `Type::Variant` IIRC the syntax is optional (you can include the type name) but it seems obvious that in any sufficiently long or complex code, not having the type name close would be annoying, especially if you didn’t have IDE like capabilities in your editor.

I've said it in other comments on HN over the years, but yes - I agree.

That `.variant` syntax is annoying as hell to dig through when you don't have an IDE to rely on for jumping around. Rust (or your choice of other more explicit language) is just generally way more clear about what's being used.

The way I usually settle on describing it is that this feature solved for people writing code, but code is read more than it's written, and thus I don't believe this tradeoff was worthwhile.

Re: Swift is a more convenient Rust

#117

Post by bananapub »

benreesman wrote: post #81
bananapub wrote: post #76

Earlier quoted context omitted.

perhaps a dumb question, but why does laziness imply boxing? or does 'boxing' in haskell mean something other than 'embed a simple bit of data in a fancy thing on the heap'?

A dramatic over-simplification is that a lazy value referenced by some continuation/thunk is hard to stack allocate in-situ. Now GHC does stack allocate, but it’s hard to count on without really aggressive hinting.

ah, right, laziness can cause the control flow to become extremely complicated - makes sense, thanks!

Re: Swift is a more convenient Rust

#118

Post by arghwhat »

x3ro wrote: post #21
arghwhat wrote: post #14

Earlier quoted context omitted.

Not to praise Swift, but Swift and Xcode are unrelated projects. Saying that Swift is inconvenient because of Xcode issues is like saying C++/C# is inconvenient because of Visual Studio. You can install Swift on Linux if you want and code away, just like with Rust - but as it hasn't really caught on for anything other than building apps for the Apple ecosystem, it's not a particularly normal thing to do.

The defacto standard matters. The vast majority of Swift programmers will be using Xcode, and I definitely immediately think of the pains I've had with Xcode when I hear Swift. For example, I don't know of any other good IDE environment for Swift, though maybe there is one. You could also argue that e.g. Rust is not cargo, but almost every Rust programmer will be using cargo. Sure I could use something else, but why…

You don't use Xcode to write Swift, you use Xcode to write Apple apps which you happen to do in Swift. No matter the language, you need Xcode to write those apps.

Equalling Xcode and Cargo makes no sense. A similar situation to Xcode and Swift would be like Visual Studio and C# on Windows. Many developers use these tools, but they are not the language ecosystem, and the Cargo equivalents are entirely separate (Nuget, Cocoapods).

Re: Swift is a more convenient Rust

#119

Post by astrobe_ »

alex_smart wrote: post #106
noelwelsh wrote: post #13

Hmmm...I disagree with a number of statements in the post but I think the following two hypotheses will make for more interesting discussion than some nitpicks: 1. A large part of why many people love Rust is that it's the first time they've used an ML family language. One of the innovations of Rust was to create a community that felt like home to Unix hackers who weren't programming language nerds. 2. Rust is the fi…

> The languages that dominated the 2000s (Ruby, Python, Javscript, PHP) were all more or less derived from Smalltalk One of these is not like the others. Javascript derives from Lisp (first-class functions, lambdas, closures), not Smalltalk.

More than features, JS derives from Lisp because its author was a Scheme implementor. Otherwise function pointers are trivially done even in assembly language, and Smalltalk does have closures.

Or maybe you think of the fact that JS uses prototype-based OOP, which makes it closer to what one would do with Scheme (something inspired from CLOS I guess) than Smalltalk ?

Re: Swift is a more convenient Rust

#120

Post by [deleted] »

benreesman wrote: post #92
zozbot234 wrote: post #87

Earlier quoted context omitted.

I'm not sure what's supposed to be especially weird about linear typing (or rather, uniqueness typing which is what Rust ultimately relies on). If you want to see the use of such types in a language that's clearly even less "convenient" and more principled than Rust, you can look at Austral https://austral-lang.org/

I think I’m going to be a hard pass on a language more militant about BDSM type system level memory management than Rust.

[deleted]
Post reply on HN