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

71–80 of 318 posts

Re: Swift is a more convenient Rust

#71

Post by diggan »

galangalalgol wrote: post #68
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.

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.

Yeah, of course. If you show me Brainfuck or APL code I won't be able to make head or tails of it either. But familiarity should never stop one from learning new things, otherwise we miss out on a lot of simple, interesting and useful stuff :)

Re: Swift is a more convenient Rust

#72

Post by mrtksn »

dannersy wrote: post #46
mrtksn wrote: post #31

Earlier quoted context omitted.

[flagged]

Buying a computer is not a reasonable response to a comment about bad tooling.

The comment says that the old tool doesn't do this new thing. The new tools do the new things.

How is it that buying the new tool to do the new thing is unreasonable and expecting the old tool to do the new thing is reasonable?

IMHO if the new tools are good and the tool you have is not good it doesn't mean that the tooling is bad, it means that the tool you have is bad and the solution for this is to obtain a new tool.

Re: Swift is a more convenient Rust

#73

Post by zer0zzz »

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 thought this was pretty normal for anyone writing code in larger code bases in these slow to compile languages in the first place…

Re: Swift is a more convenient Rust

#74

Post by nurettin »

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?

It would be ridiculously simple in go with channels.

Re: Swift is a more convenient Rust

#75

Post by benreesman »

zozbot234 wrote: post #67
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”.

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

I’m aware of how boxing works in GHC, I learned it from Simon Marlowe.

I don’t mean to be obtuse but I don’t see what that has to do with linear typing as a fucking weird mandatory default?

Re: Swift is a more convenient Rust

#76

Post by bananapub »

zozbot234 wrote: post #67
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”.

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

Re: Swift is a more convenient Rust

#79

Post by SSLy »

nextaccountic wrote: post #64
SSLy wrote: post #43

Earlier quoted context omitted.

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

Indeed, and Scala (at least the version I've tried 10 years ago) tries to do both, somewhat poorly. shrug

Re: Swift is a more convenient Rust

#80

Post by tgv »

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 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.
Post reply on HN