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

201–210 of 318 posts

Re: Swift is a more convenient Rust

#201

Post by koverstreet »

tialaramex wrote: post #149
tgv wrote: post #80

Earlier quoted context omitted.

Rust is not really an ML language, is it? &mut is a very noticeable difference. Calling Rust, Scala, Swift and Kotlin ML seems to be taking it too far. Scala and Kotlin even have all the traditional OOP features. You might just as well put C++ in the ML list.

It's not the Standard ML of New Jersey of course, like I was taught last century, but it looks like an ML to me. Rust has a sound type system, whereas a language like C++ inherits C's YOLO approach to typing. In Rust Vec > is just a counter. Really, that's not theory that'll just happen by default because of how type arithmetic works. In C++ you can't even write down an equivalent type, let alone say how it would be…

Could you elaborate? I would think Vec> would have to be a bit vector.

Re: Swift is a more convenient Rust

#202

Post by pessimizer »

bad_user wrote: post #125
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…

> first language to bring non-GC automatic memory management to the mainstream ... Other languages in this space include Swift Ugh, “Arc”, aka (automatic) reference counting, is an implementation of GC as well. It may have certain characteristics, like having worse throughput, corner cases, and better predictability/latency characteristics, but it's GC nonetheless. That's not manual memory management. Swift is not a…

It's not "automatic" reference counting, it's "atomic" reference counting. And it's not automatic, it's entirely manual and implemented with traits as a fat pointer. Reference counting types in Rust are just defaults that give certain guarantees.

This feels like people arguing that atheism is a kind of religion. Borrow checking and a library of safe default primitives make it so you don't really have to think about memory management; except to the extent that you generally stick to those primitives, and that you have to install the borrow checker into your own head to write Rust comfortably (although the compiler will help.)

Rust doesn't have any garbage collection, but it can just assume how you would want to deal with memory by forcing you to be very specific about when values should be created or destroyed.

Re: Swift is a more convenient Rust

#203

Post by mogoh »

bryancoxwell wrote: post #165
mogoh wrote: post #157

Always, when I read those postings that praise Swift, I wonder how good is the developer experience is if you don't use any of the Apple/MacOS ecosystem (except Swift, of course). I have not met any Swift developer who is not developing on macOS, usually for macOS. That makes me very skeptical that non-Mac devs are treated as second-class citizens. I am not only talking about the standard library, but also about the…

I recently went through the Swift tutorial for building a REST API using Vapor[0]. I used VSCode, compiled and run on Ubuntu. It’s the only Swift I’ve ever written, and obviously far from a production app, but I did enjoy it enough that it made me want to continue playing with Swift outside of the XCode/Mac ecosystem. [0]: https://www.swift.org/getting-started/vapor-web-server/

It's not much, but it's something. Thanks

Re: Swift is a more convenient Rust

#204

Post by pessimizer »

112233 wrote: post #191
rcruzeiro wrote: post #144

Earlier quoted context omitted.

Both ARC and garbage collection are memory management techniques. ARC does not equal garbage collection though. Garbage collection runs at intervals and is triggered by certain signals (memory pressure, etc), pauses all threads and scans for objects that can be deallocated. It is a very different concept than ARC.

Deleting large hierarchy of objects when the last reference gets decremented also is triggered by a certain signal (reference decrement) and pauses all threads while it collects garbage. There are even tunable GC that become ARC if you set particular parameter to "N=1"

> There are even tunable GC that become ARC if you set particular parameter to "N=1"

You can call a pointer to a value a "one-element static array."

Re: Swift is a more convenient Rust

#205

Post by throwaway17_17 »

bananapub wrote: post #76
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 .)

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'?

I seem to be missing the implication as well. I am under the impression that Haskell relies on boxed values primarily due to its parametric polymorphism. There is a Simon Peyton Jones talk somewhere discussing the acrobatic GHC requires for the type theory to deal with unboxed types and their implicit requirement for an alternative Kind at the type level.

The laziness as a default just makes boxing closure values a sensible default, when the type system requires the boxing of everything in general.

Re: Swift is a more convenient Rust

#207

Post by pessimizer »

lolinder wrote: post #136
est31 wrote: post #27

Earlier quoted context omitted.

> 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…

> 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 free. But those checks won't prevent leaks, although the many lints do make it harder to forget about a value. By this logic no language on earth has automatic memory management. I've sp…

> you can write entire Rust programs without once calling `free` manually.

If you mean "drop," it's just syntactic sugar for calling a trait that manually deallocates the memory and that you're free to reimplement.

It feels like people are equating "manual memory management" with "onerous memory management." People are usually going to want to do the boring thing with memory, and everything in the standard library by default does the boring thing with memory. If you write boring structs and enums, you'll derive boring memory management. But it's not part of the language, it's part of the library.

Re: Swift is a more convenient Rust

#208

Post by zerr »

dgellow wrote: post #33
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…

Swift does have garbage collection via reference counting

Yes, usually GC vs non-GC discussion is actually about deterministic vs non-deterministic memory management. Swift's ref-counting is deterministic.

Re: Swift is a more convenient Rust

#209

Post by Measter »

neonsunset wrote: post #86
pjmlp wrote: post #45

Earlier quoted context omitted.

Native AOT needs to get better tooling ergonomics though, the whole publish process is a bit convoluted versus toolchains that have AOT compilation as their default. Not counting having to learn about IL trimming, and the whole AOT compatible libraries.

What kind of issues did you have with the build process? (as in, if you had a specific case, it might be worth submitting an issue or updating documentation) It's a very straightforward process - you pass a single flag, maybe specify optimization preference and instruction set target, and it gives you the binary upon 'dotnet publish'ing the project. The process of static linking (if you care about this scenario), wit…

How are build times for AOT these days? Last time I tried it (~2019) it was slower than Rust at building the same project.

Re: Swift is a more convenient Rust

#210

Post by nicce »

lame-lexem wrote: post #199

Rust's `Vec` already allocate values on the heap, so there is no need for another inderection with `Box`. this works: enum TreeNode { Leaf(T), Branch(Vec >), } https://play.rust-lang.org/?version=stable&mode=debug&editio... otherwise if it was just tuple of `TreeNode` there would be E0072 https://doc.rust-lang.org/stable/error_codes/E0072.html

Box takes less space in stack, and you can use Box to move pointer to Vec contents easier, without mem::take. So if you want to min-max things, you could still use Box.
Post reply on HN