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

91–100 of 318 posts

Re: Swift is a more convenient Rust

#91

Post by kaba0 »

est31 wrote: post #27
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…

> Rust is the first language to bring non-GC automatic memory management to the mainstream. It won't be the last and it might well be the worst. Other languages in this space include Swift Rust's memory management is not automatic, you have to explicitly manage memory. It's just made extremely easy for you by the language thanks to stuff like RAII, and there is checks that prevent memory safety violations like double…

Yeah, the correct statement would be ‘Rust is the first mainstream language without GC, that guarantees memory safety’ (with obviously the caveat of unsafe blocks, but than you can also sun.misc.unsafe yourself into segfault in java).

Re: Swift is a more convenient Rust

#92

Post by benreesman »

zozbot234 wrote: post #87
benreesman wrote: post #75

Earlier quoted context omitted.

I’m aware of how boxing works in GHC, I learned it from Simon Marlowe. I don’t mean to be obtuse but I don’t see what that has to do with linear typing as a fucking weird mandatory default?

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.

Re: Swift is a more convenient Rust

#93

Post by galangalalgol »

K0nserv wrote: post #32

I love both Rust and Swift, they have their respective strengths. I would say Swift has a less noisy surface syntax, but instead uses more dedicated keywords and compiler magic. This is nicer, but means some areas are "compiler only territory". In many cases Swift would be a better choice than Rust, when the convenience and developer experience is worth trading for some performance. However, Swift's biggest problem i…

In my toy usage of swift I found it to run dramatically slower than rust. To even get something close to go or java speeds I had to compile with unchecked losing a lot of safety. Other than developing for an apple product, I don't know why I would ever pick swift and I wouldn't ever find myself deciding between rust and swift. It would be swift vs go. When considering rust it would be vs c++ or zig.

Re: Swift is a more convenient Rust

#94

Post by zozbot234 »

timeon wrote: post #42
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…

> These alternatives take the approach that tracking ownership is not the default, which is fine for the majority of programs and far more ergonomic. If you want non-default safety you do not need to leave C++. That is why unlike all these new languages, Rust makes difference.

Swift 6 is expected to be memory safe, including for concurrent programs. That's a lot more than you can say about C/C++. (This is achieved by tracking ownership at runtime when required. Rust allows for this via library types such as Rc and RefCell, which is more principled but obviously adds some boilerplate compared to Swift.)

Re: Swift is a more convenient Rust

#95

Post by SSLy »

valenterry wrote: post #88
SSLy wrote: post #79

Earlier quoted context omitted.

Indeed, and Scala (at least the version I've tried 10 years ago) tries to do both, somewhat poorly. shrug

Personally I found Scala's module/import system to be really really good. There are some annoying things with it, but they mostly come from JVM/Java compatibility.

Yeah, it's the compat that I vaguely recall being kludgy.

Re: Swift is a more convenient Rust

#96

Post by DasIch »

pjmlp wrote: post #34

What Rust did great was bringing affine type systems into mainstream culture. However outside very specific use cases, where no kind of automatic resource management is allowed, no matter what, like in high integrity computing, or critical kernel code, approaches that mix and match both solutions are much more ergonomic. Swift isn't the only one going down this route, we see it as well in D, Chapel, Linear Haskell, O…

Rust is more popular than all of these languages except swift combined. So it seems empirically that ergonomics and expressiveness don't matter that much or these languages don't manage to do significantly better than rust.

Re: Swift is a more convenient Rust

#97

Post by _mlbt »

robjwells wrote: post #12

One way that Swift is certainly not more convenient than Rust is the tooling. I use a 2018 MacBook Air, using macOS 12, which is now unsupported by Xcode. Meanwhile SourceKit-LSP is treated as very much a second-class citizen. But Rust 1.81 and rust-analyzer build and run just fine.

It looks like MacOS Sonoma (and the latest Xcode) should work on your Mac.

https://support.apple.com/en-us/105113

Re: Swift is a more convenient Rust

#98

Post by the_duke »

benreesman wrote: post #75
zozbot234 wrote: post #67

Earlier quoted context omitted.

The whole point of Haskell as a programming language is to have lazy evaluation be the default. This comes with boxing data objects everywhere, which is the opposite of a focus on low-level performance. Haskell does support using strict, unboxed data but it's clunky and not the default. (Also, recent versions of Rust have now added support for "plug-in" laziness via the type constructors LazyCell and LazyLock .)

I’m aware of how boxing works in GHC, I learned it from Simon Marlowe. I don’t mean to be obtuse but I don’t see what that has to do with linear typing as a fucking weird mandatory default?

Why should every language occupy the same design space?

Rust was shaped by Mozilla wanting a language to replace parts of Firefox with. A language that is low-level enough to give very high performance, enforces correctness through the type system, and yet has many abstractions so it feels modern and convenient to use.

Rust doesn't have any automatic allocations. You can wrap every type in `Arc>` and treat it like a very verbose Python, but that's the programmers choice.

The design decisions have been validated by the success of Rust in certain domains.

There is a reason why more than one programming language exists...

Re: Swift is a more convenient Rust

#100

Post by K0nserv »

galangalalgol wrote: post #93
K0nserv wrote: post #32

I love both Rust and Swift, they have their respective strengths. I would say Swift has a less noisy surface syntax, but instead uses more dedicated keywords and compiler magic. This is nicer, but means some areas are "compiler only territory". In many cases Swift would be a better choice than Rust, when the convenience and developer experience is worth trading for some performance. However, Swift's biggest problem i…

In my toy usage of swift I found it to run dramatically slower than rust. To even get something close to go or java speeds I had to compile with unchecked losing a lot of safety. Other than developing for an apple product, I don't know why I would ever pick swift and I wouldn't ever find myself deciding between rust and swift. It would be swift vs go. When considering rust it would be vs c++ or zig.

It depends on the axis you are considering. Swift might be slower than Rust, but it has an equally powerful type system. Swift and Go are much less similar than Swift and Rust in this regard.
Post reply on HN