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

61–70 of 318 posts

Re: Swift is a more convenient Rust

#61

Post by junon »

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 >, }

Yeah this is a bad example for introductions for rust - namely that async rust is something I'd consider advanced.

However the type explicitness is, IMO, one of its strengths. It lets you build up types that e.g. in C++ we're not a given, had properties about the behavior buried in docs, etc.

Re: Swift is a more convenient Rust

#62

Post by timeon »

sgt wrote: post #54
homebrewer wrote: post #37

Earlier quoted context omitted.

Is upgrading every 5-6 years to be able to write code considered normal in the Apple world? I'd been comfortably writing code in several languages using latest toolchains on a decade-old Intel machine just a few months ago, and was forced to upgrade because one of the components died. Otherwise I'd be using it for at least five more years.

I mean.. upgrading every 5-6 years is pretty normal outside the Apple world too, if you are a professional programmer. I don't expect my mom to upgrade her computer that much (she's happy with her 2011 (!) model iMac). But for those of us who use a computer every day, surely it makes sense to stay a bit cutting edge and it won't break the bank either since it is literally our income.

Is it sustainable?

Re: Swift is a more convenient Rust

#63

Post by bitexploder »

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 >, }

The only tricky thing there is the BoxFuture and ‘static lifetime. Arc is pretty simple. Option is simple. Rust is just forcing you to acknowledge certain things and understand lifetimes explicitly before you can move data around. And static is close to a “plz make this lifetime error go away” thing cause it means it can live forever. But they are also fine, and often the right choice. This may seem contradictory but it will make sense if the Rust compiler hurts you enough times :)

Re: Swift is a more convenient Rust

#64

Post by nextaccountic »

SSLy wrote: post #43
the_duke wrote: post #20

Earlier quoted context omitted.

Ad 3) Scala is quite a bit older than the others, I'd put it in a previous generation. I always saw Kotlin as a more convenient Java, without Scalas heavy tilt towards FP. Java also added the equivalent of sum types with sealed interfaces and exhaustive pattern matching, does that make Java an ML language? Many older languages by now have incorporated valuable parts of FP/ML (including Javascript, Java, C++, ...) Bor…

> does that make Java an ML language? not really, the type-system-sublanguage is still modelled like classy OOP, not more like MLy modules.

But Kotlin is like this too.

Re: Swift is a more convenient Rust

#66

Post by zer0zzz »

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…

> 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 and libraries for all platforms it will not have a community of developers outside of the Apple ecosystem.

Re: Swift is a more convenient Rust

#67

Post by zozbot234 »

benreesman wrote: post #38
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…

I think if Linear/Affine typing was a default anyone wanted, Haskell hackers (who are usually pretty concerned with performance) would regard it as more than a research oddity. When people bitch about the borrow checker, what they usually mean is “std::move is a great wristwatch but god damn does it chafe as a chastity belt”.

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

Re: Swift is a more convenient Rust

#68

Post by galangalalgol »

diggan wrote: post #39
swiftcoder wrote: post #22

Earlier quoted context omitted.

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?

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.

Having never used a lisp outside an AI class a quarter century ago, that isn't comprehensible to me, and I don't think it is just my lack of caffeine. The rust example makes more sense, but I've used rust for almost a decade at this point and c++ for over three. Familiarity matters.

Re: Swift is a more convenient Rust

#69

Post by mrtksn »

homebrewer wrote: post #37
mrtksn wrote: post #31

Earlier quoted context omitted.

[flagged]

Is upgrading every 5-6 years to be able to write code considered normal in the Apple world? I'd been comfortably writing code in several languages using latest toolchains on a decade-old Intel machine just a few months ago, and was forced to upgrade because one of the components died. Otherwise I'd be using it for at least five more years.

I don't see why would anybody complain that the tools they bought 10 years ago don't magically do the things that the new tools are doing. It's not like the old tools stopped doing the things they do, right?

Anyway, you sel the old machine and get the new one is pretty normal as the Apple devices tend to hold value.

Re: Swift is a more convenient Rust

#70

Post by benreesman »

mananaysiempre wrote: post #52
benreesman wrote: post #38

Earlier quoted context omitted.

I think if Linear/Affine typing was a default anyone wanted, Haskell hackers (who are usually pretty concerned with performance) would regard it as more than a research oddity. When people bitch about the borrow checker, what they usually mean is “std::move is a great wristwatch but god damn does it chafe as a chastity belt”.

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

Post reply on HN