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

141–150 of 318 posts

Re: Swift is a more convenient Rust

#141

Post by mrtksn »

gr__or wrote: post #107
mrtksn wrote: post #69

Earlier quoted context omitted.

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.

let the record show that we're talking about 6 years

Which is about the same time it takes a high school student to get his masters degree in computer science, get into a FAANG and get promoted.

6 years is a lot. It runs about 14$ a month if you throw away you tool at the end. It's probably more like 10$ since you are likely to be able to sell that tool at reasonable price since its Apple.

Re: Swift is a more convenient Rust

#142

Post by benreesman »

zozbot234 wrote: post #121
benreesman wrote: post #101

Earlier quoted context omitted.

I think Rust is cool! If it wasn’t actively seeking world domination I’d be like, cool let’s use that sometimes. Rust is so hell bent on a Rust monoculture ranging from stuff like TRACTOR to actively opposing interop that a few of us who know our shit have to be like “easy now” once in a while. I’m trying to decide between tiktoken and sentencepiece for a new vocabulary at the moment, and it would be easier in some w…

> to actively opposing interop Rust just uses the C ABI for interop (including interop with Rust code that might not be part of the same build, such as dynamically-linked program objects). So you just have to come up with a plain C API for the interface and write wrappers on both sides of the divide that reference the C API. There are crates that will help with this, even achieving something like a "stable ABI" for R…

It’s doable!

But bindgen/cbindgen/cxx/etc exist for a reason: it hurts like a root canal.

In my particular case, tiktoken is substantially like 600 lines of Rust. If I have a deadline do I fuck with the linker or just write it again? I’m marshaling std::string here, fuck let’s just write it.

What I’m not going to re-write because I’m not a magnificent maniac like geohotz? I’m not going to rewrite libtorch. Which is written in C++ like all the software you can’t really live without.

Re: Swift is a more convenient Rust

#143

Post by pjmlp »

junon wrote: post #61
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.

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.

Re: Swift is a more convenient Rust

#144

Post by rcruzeiro »

bad_user wrote: post #125
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…

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

Re: Swift is a more convenient Rust

#145

Post by zozbot234 »

benreesman wrote: post #131
bananapub wrote: post #117

Earlier quoted context omitted.

ah, right, laziness can cause the control flow to become extremely complicated - makes sense, thanks!

Also true! And in very real sense literally what I meant. But not so much in the conditional branch sense of the phrase “control flow”. More like, I’ve got a bunch of references and one of them is a reference to a function I might evaluate, damn, I need that reference and the transitive closure of everything it knows about, all of which are probably on the heap.

The proper name for this is a "space leak". Also known as: "you wanted a banana, but what you got was a gorilla holding the banana and the entire jungle". This is of course pretty much the opposite of low-level "performance" - and it's also the kind of problem that tracing garbage collection was actually designed to address when first developed.

Re: Swift is a more convenient Rust

#146

Post by afavour »

369548684892826 wrote: post #114
afavour wrote: post #111

As someone that’s recently been working on integrating Rust into an iOS Swift app I do agree with a lot of this. I love Rust but the more I’ve used Swift the more I find myself wishing I was just using Swift all the time. That said , the difference between the two has a lot less to do with the language itself than the world surrounding it. You can use Swift cross platform but it’s very obvious that Apple platforms ar…

Swift is in its .NET Framework stage. I’m looking forward to Swift Core!

I like that comparison! But it might require Apple’s perspective as a company to shift in the same way Microsoft’s did. We’ll see, I guess…

Re: Swift is a more convenient Rust

#147

Post by Sharlin »

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.

But honestly only for a very short time. It took me two weeks of learning for Clojure to start looking completely natural to me. Surface syntax is such a trivially minor thing, which is why it seems ridiculous to me that the OP author even mentions things like "Swift uses switch rather than match, such familiarity" among other much more solid points.

Re: Swift is a more convenient Rust

#148

Post by IsTom »

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…

> (Ruby, Python, Javscript, PHP) were all more or less derived from Smalltalk

I'd argue that Erlang (with gen_servers being "objects") has more in common with Smalltalk than these.

Re: Swift is a more convenient Rust

#149

Post by tialaramex »

tgv wrote: post #80
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.

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 represented, the type system blows up long before we get there.

Re: Swift is a more convenient Rust

#150

Post by pjmlp »

neonsunset wrote: post #140
pjmlp wrote: post #132

Earlier quoted context omitted.

As you are well aware, I know .NET since it was "partners only beta software", so dealing with "dotnet publish" plus csproj configuration, is still way easier than something like NGEN. However this is somehow cumbersome versus doing a plain "aot-lang-compiler source -o binary". Which is the experience I think the team should strive on as goal, especially for newcomers. More so when comparing IDE experience of somethi…

> However this is somehow cumbersome versus doing a plain "aot-lang-compiler source -o binary". But...it works in this exact way? dotnet publish -o folder -p:PublishAot=true Does not need -p argument either, as noted in the previous comment, if `PublishAot` is specified in .csproj, like with any AOT template (e.g. dotnet new console --aot or dotnet new webapiaot). On Visual Studio, I have started to recommend to newc…

Publish versus build, yet another step, another concept to learn.

CLI only isn't the answer, if you want better adoption.

Post reply on HN