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

191–200 of 318 posts

Re: Swift is a more convenient Rust

#191

Post by 112233 »

rcruzeiro wrote: post #144
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…

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"

Re: Swift is a more convenient Rust

#192

Post by Ygg2 »

arghwhat wrote: post #24
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 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 -…

> non-GC *automatic memory* management to the mainstream would be either Forth or C

Emphasis mine.

It's not C. You do manual memory management there. You have to call malloc/free.

Didn't use Forth, so I can't say anything about it.

Re: Swift is a more convenient Rust

#193

Post by kingofthehill98 »

Loic wrote: post #129
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…

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

Thank you!

The whole time I was like "what in the absolute hell is a ML language".

Re: Swift is a more convenient Rust

#194

Post by diggan »

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.

If you really badly want types, you'd slap something like this below it:

    (s/def ::future atom?))
    (s/def ::task-sender async/chan?)
    (s/def ::task
      (s/keys :req-un [::future ::task-sender]))

    (s/fdef create-task
      :ret ::task)

    (stest/instrument `create-task)
But then I don't think you'd reach for something like Clojure if static typing is something that you require.

Re: Swift is a more convenient Rust

#196

Post by pjmlp »

kenmacd wrote: post #156
pjmlp wrote: post #143

Earlier quoted context omitted.

It would be, if there wasn't a trend to expose async all over the place on the Rust ecosystem. Thus even newbies get to bump into it quite fast.

They run in to async, but do they run in to the internals of how that code is executed? The chapter that example is from includes the disclaimer: > In this section, we'll cover the underlying structure of how Futures and asynchronous tasks are scheduled. If you're only interested in learning how to write higher-level code that uses existing Future types and aren't interested in the details of how Future types work, y…

Naturally, as soon as they get some kind of async related compilation error.

Re: Swift is a more convenient Rust

#197

Post by xolox »

Ygg2 wrote: post #192
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 -…

> non-GC *automatic memory* management to the mainstream would be either Forth or C Emphasis mine. It's not C. You do manual memory management there. You have to call malloc/free. Didn't use Forth, so I can't say anything about it.

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

Re: Swift is a more convenient Rust

#198

Post by nurettin »

kenmacd wrote: post #155
nurettin wrote: post #74

Earlier quoted context omitted.

It would be ridiculously simple in go with channels.

Would it though? Just running things 'async' is simple, but it's also simple in Rust. I wouldn't figure writing an Executor would be any easier in Go than the Rust example at https://rust-lang.github.io/async-book/02_execution/04_execu...

As I understand, the idea an executor is to emulate an event queue using threadsafe (hopefully lock-free) queues. Since the language already has goroutines, channels and group waits, I don't think this is something that needs to be built in Go. I mean you can do your rate limiting and retry handling logic outside the language primitives. If you do have to make a task spawning executor, you can do that with channels as well. But it would just be a very thin wrapper.

Re: Swift is a more convenient Rust

#199

Post by lame-lexem »

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

Re: Swift is a more convenient Rust

#200

Post by hardwaresofton »

robjwells wrote: post #152
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.

Fortunately in Rust you can have it both ways, as in `Type::Variant` most of the time and `use Type::Variant; … Variant …` in cases where the type name just causes noise. Example in the playground: https://play.rust-lang.org/?version=stable&mode=debug&editio...

I’ve never done this but this is a great point. I think I’d avoid doing this though because variants often have really short, reusable/general names (leaning into the overall type name being close)
Post reply on HN