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

211–220 of 318 posts

Re: Swift is a more convenient Rust

#211

Post by Ontonator »

pessimizer wrote: post #202
bad_user wrote: post #125

Earlier quoted context omitted.

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

In the context of Swift, ARC is automatic reference counting: https://docs.swift.org/swift-book/documentation/the-swift-pr...

Re: Swift is a more convenient Rust

#212

Post by pessimizer »

robertkrahn01 wrote: post #113
alex_smart wrote: post #106

Earlier quoted context omitted.

> 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

Did you link his biography? The claim is that he used Self as an inspiration, not that there was once a man named Brendan Eich.

Re: Swift is a more convenient Rust

#213

Post by zozbot234 »

koverstreet wrote: post #201
tialaramex wrote: post #149

Earlier quoted context omitted.

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.

Infallible is a clunky name for the Never type in Rust, i.e. a type that has no values and cannot be instantiated. Thus, Option only has a single value, viz. None. Then Vec> is isomorphic to Vec which reduces to a length field - there's no other data associated with it.

Re: Swift is a more convenient Rust

#214

Post by lolinder »

pessimizer wrote: post #207
lolinder wrote: post #136

Earlier quoted context omitted.

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

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

I meant `free` because I'm contrasting with C.

> It feels like people are equating "manual memory management" with "onerous memory management."

Manual memory management is onerous, but I'm very specifically talking about manual. If I can write a whole program without thinking about memory, the language does not require manual memory management. It may support it, but it doesn't require it the way that C or Zig do. You do not "have to explicitly manage memory" as OP claimed.

Re: Swift is a more convenient Rust

#215

Post by noelwelsh »

lucideer wrote: post #161
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 age of Smalltalk is over. It's now the age of ML [...] The languages that dominated the 2000s (Ruby, Python, Javscript, PHP) were all more or less derived from Smalltalk [...] The new languages (Rust, Scala, Swift, Kotlin, etc.) are ML family languages. What drew people to a lot of your examples (Javascript, PHP especially) was the runtimes rather than the language features. Your example sets aren't just demarc…

Good point.

The nitpicky take: a lot of these languages come with a repl / console. E.g. the most recent version of Scala builds Scala CLI[1] into the language. You can run `scala repl` and just type code into it, or run `scala SomeFile.scala` and it will compile and run `SomeFile.scala`. There is special syntax for writing dependencies so that a single file can pull in the libraries it needs.

The 5head thought leader take: the traditional model for typed languages has two phases: compile time and run time. Types exist at compile time. This is inadequate for many applications, particularly interactive ones. E.g. a data scientist doesn't know the shape (type) of the data until it is loaded. It should be possible to infer the type from the data once it is loaded and make that type available to the rest of the program. We know how to do this (it's called staging) but it's just not available in the vast majority of languages. Staging, and metaprogramming in general, is perhaps the next great innovation in programming languages (which will take us from ML to Lisp).

In general, the challenge for these new languages is to reach "down" into the simpler scriptier applications, instead of the "serious" programming they are usually built for.

[1]: https://scala-cli.virtuslab.org/

Re: Swift is a more convenient Rust

#216

Post by tialaramex »

secondcoming wrote: post #128
tialaramex wrote: post #108

Earlier quoted context omitted.

Also they probably have their understanding upside down. What's going on here isn't that either Swift or Rust treats the enum types as "more than just types" but that they are indeed first class types, whereas in C and C++ what you get isn't a type at all, it's just a strange way to spell an integer. I don't think Swift has union types, but Rust does and so does C++ and in both languages the unions, just like their m…

C++'s scoped enums are strict types.

Scoped enums ("enum class") are a very small improvement on the previous enum, the main thing they deliver is that they don't pollute your namespace as badly thanks to the scoping.

Their notional status as "strict types" means nothing in a language which doesn't really care anyway, that's why memory_order::relaxed In Rust if you write nonsense like that it doesn't compile, these aren't comparable things. In C++ they're just integers, so of course you can see that relaxed (the integer zero) is less than timeout (the integer one) ...

They are just integers wearing funny hats.

Re: Swift is a more convenient Rust

#217

Post by zozbot234 »

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"

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").

Re: Swift is a more convenient Rust

#218

Post by jppittma »

swiftcoder wrote: post #22
seanalltogether wrote: post #16

I keep trying to get into rust but I always hit a brick wall when looking at examples and the code looks so complicated. Examples like this straight from the rust website just make my eyes glaze over struct Task { future: Mutex >>, task_sender: SyncSender >, }

I'll grant you that is probably too complicated an example to appear early in the docs, but how often are you actually building multithreaded job dispatch systems from scratch (which appears to be what this example is doing), and how simple would it be in other languages?

In golang I think just

    type Task struct {
        Sender chan Task
    }
no?

Re: Swift is a more convenient Rust

#219

Post by MarcusE1W »

benreesman wrote: post #70
mananaysiempre wrote: post #52

Earlier quoted context omitted.

GHC Haskell is a fairly large language with a considerable legacy already, so integrating linear or affine types into it may well be a very different question from making a language centered around them. That language exists in the form of Clean[1,2]. Admittedly it’s not really well-known. [1] https://clean.cs.ru.nl/ [2] https://clean-lang.org/

Thank you for making me aware of Clean, on quick glance it looks cool. I like a lot of things about Rust: it’s got compiler checked exhaustive pattern match and a good initialization syntax and Either baked in and fucking correct package management and a ton of other things. I’ll look at Clean to see if linear-only memory management can be done gracefully. Rust is a lot of cool things but not the language that demons…

There is also Austral, which has linear types as a main capability: https://austral-lang.org/

Re: Swift is a more convenient Rust

#220

Post by tmtvl »

speed_spread wrote: post #188
diggan wrote: post #39

Earlier quoted context omitted.

This is how simple it would be in Clojure, for comparison: (defrecord Task [future task-sender]) Probably used something like this: (defn create-task [] (let [future (atom nil) task-sender (async/chan)] (->Task future task-sender))) Not sure it makes sense but a pretty much direct translation as far as it goes.

So it's the same but without type annotations? Meaning that the clojure IDE has a much harder time providing completion and that you need to write all sorts of tests to get the same guarantees as the rust compiler provides for free. Type systems aren't just about memory representation, they also tell the next programmer about the intent and performance characteristics of the code at hand.

That's why I moved from Scheme to Common Lisp, it's nice being able to do...

  (defstruct Task
    (future :type Future)
    (task-sender :type Sender))
And have SBCL warn me when I try to jam the wrong type in.
Post reply on HN