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

231–240 of 318 posts

Re: Swift is a more convenient Rust

#231

Post by hollerith »

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…

You seem to assert that OCaml doesn't use a run-time garbage collector:

>Rust is the first language to bring non-GC automatic memory management to the mainstream. . . . Other languages in this space include . . . OCaml[1]

But your own link[1] says,

>The OCaml compiler does not statically track lifetimes. Instead, it relies on a garbage collector to figure out a suitable lifespan for each value at runtime. Values are collected only after they become unreferenced, so OCaml programs are memory-safe. To a first approximation, this model requires allocating all values on the heap. Fortunately, OCaml’s generational GC can efficiently handle . . .

Scala does run-time garbage collecting, too (or rather the JVM does, which Scala depends on at run-time) unless I'm very much mistaken.

Re: Swift is a more convenient Rust

#232

Post by plorkyeran »

noobr wrote: post #223
Loic wrote: post #129

Earlier quoted context omitted.

In this context, ML is Meta Language: https://en.wikipedia.org/wiki/ML_(programming_language)

thanks, i'm bad at abbreviations and don't like when people just throw them like this without first using the whole term at least once

Expanding this abbreviation conveys zero information. It’s a programming language named ML, and if you haven’t heard of it then giving the etymology of the name isn’t going to help.

Re: Swift is a more convenient Rust

#233

Post by StewardMcOy »

As someone who has worked on large projects in both Swift and Rust, I have to disagree with the author about error handling. It's not perfect, but Rust's use of Result and syntactic sugar is probably the best solution to error handling I've ever used. try/catch (or in Swift's case do/catch) is more disruptive to the program flow. And prior to Swift 6, throws in Swift were untyped.

(Yes, there's arguments that untyped throws are better for library code because it leaves you more room to add more errors as you become aware of the need for them without breaking the contract with your users, but really, client code is going to be written to the errors you're throwing anyway (i.e. Hyrum's Law). I much prefer my errors to be typed so that if an error is added, the library version has to be bumped to indicate the new incompatibility with old code. And for my own, non-library code, typed errors make sure I'm handling all the error cases.)

Re: Swift is a more convenient Rust

#234

Post by 01HNNWZ0MV43FF »

twoodfin wrote: post #159
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.

https://courses.cs.washington.edu/courses/cse590p/05au/p50-b... This paper makes a strong argument that “pure” tracing garbage collection and “rote” reference counting are effectively duals at the opposite ends of a spectrum of implementation choices. For example, GC’s often optimize differently for young vs. old objects. How do they distinguish these? By “counting” (one bit) their references across one or more trace…

And a hot wheels car is a car, but I would be perplexed to see one offered to me at a car dealership

Re: Swift is a more convenient Rust

#235

Post by [deleted] »

shakow wrote: post #122
arghwhat wrote: post #24

Earlier quoted context omitted.

> Rust is the first language to bring non-GC automatic memory management to the mainstream To nitpick, the first language to bring non-GC automatic memory management to the mainstream would be either Forth or C through stack memory. For heaps, we have reference counting, often handled automatically through the stack (e.g., C++ smart pointers). The thing Rust brought to mainstream is not automatic memory management -…

> C through stack memory. Stack memory is decades older than C.

[deleted]

Re: Swift is a more convenient Rust

#236

Post by arghwhat »

pjmlp wrote: post #36
arghwhat wrote: post #24

Earlier quoted context omitted.

> Rust is the first language to bring non-GC automatic memory management to the mainstream To nitpick, the first language to bring non-GC automatic memory management to the mainstream would be either Forth or C through stack memory. For heaps, we have reference counting, often handled automatically through the stack (e.g., C++ smart pointers). The thing Rust brought to mainstream is not automatic memory management -…

Not at all, considering the decade of high level systems programming languages that predated the very thought of C coming into life. All with stack allocation.

Keyword is mainstream, so it’s not when the idea was invented - I think Forth popularized it?

I can’t really comment on what counted as mainstream before C though. Not old enough for that.

Re: Swift is a more convenient Rust

#237

Post by arghwhat »

Ygg2 wrote: post #221
xolox wrote: post #197

Earlier quoted context omitted.

malloc/free are for heap based allocations. The grand parent explicitly mentioned he was referring to stack based allocations, which are kind of automatic (implicit).

Sure, however you still have to do them manually. That's what manual in manual memory management stands for. Stack based allocation are essentially registers, right?

The stack is fully automatic arbitrary memory and has nothing to do with registers. You can allocate as much as you want (including e.g. bytearrays), until you run into the allocated stack limit. That limit can be arbitrary, and some languages even dynamically scale the stack.

That you also have access to manual memory on the heap doesn’t matter. You can also do manual memory management in Rust if you want, as one has to do at times.

Re: Swift is a more convenient Rust

#238

Post by zer0zzz »

knighthack wrote: post #154
zer0zzz wrote: post #66

Earlier quoted context omitted.

> However, Swift's biggest problem is that any usage outside of the Apple ecosystem is a second(or third) class citizen. Until this is solved, Swift will remain mostly an Apple only language, regardless of how nice it is. I think a time goes on this is more and more only a perception and not a reality. However perception is really important because it’ll mean even if it’s a great language with a great set of tools an…

The issue is not "as time goes on". The issue is now - the use of Swift outside of the Apple ecosystem is remarkably stifled, given the lack of Apple support. A language truly acquires mainstream mindshare and community, only if it can extend its use beyond Apple's OSes.

> given the lack of Apple support.

It’s an open source project that’s more and more detached from Apple itself every release, with lots of contributors making it better and better on Android and windows all the time.

It is possible to get a vscode ide environment working for cross platform development and debugging today, which was not that easy or possible even a few years ago.

There is at least one pretty sizable software project that has shipped a product on Android and windows using swift.

I think swift 6 is going to be great for cross platform uses, but convincing folks to try it still won’t be easy.

Re: Swift is a more convenient Rust

#239

Post by 112233 »

zozbot234 wrote: post #217
112233 wrote: post #191

Earlier quoted context omitted.

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"

I'm not sure that collecting a large hierarchy of objects requires pausing all threads. What can definitely require pausing threads (other than in specialized concurrent collectors) is the tracing step, which relies on some invariants that in simple GC implementations (not the more specialized concurrent ones mentioned earlier) are only ensured at very specific points in the program (known as GC "safepoints").

My bad, thanks for correcting! Of course single thread freeing a lot of heap allocations will not pause other threads by itsel. What I had to write was: calling destructor of an object that in turn calls destructors of other objects (because a large tree of reference counted objects loses last reference to it's root) stops that thread, until all deallocation is done.

Re: Swift is a more convenient Rust

#240

Post by est31 »

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…

> Rust's memory management is automatic in that you can write entire Rust programs without once calling `free` manually.

Personally I'd put the bar around not requiring people to distinguish different pointer types (owned vs shared). Languages like Java, JS, Python, Swift, Go, etc all have this "everything is a smart pointer" paradigm, (or at least the strong and widely used default). I'd say Rust is manually managed because you need to think about which pointer type to use and using gc'd pointer types like Arc has a syntax overhead (like say when a pointer is cloned).

Post reply on HN