Hacker News Reader

Comment by stu2b50 | Hacker News Reader

I wouldn't give Rust or Elm the credit for that, though. Although it was not first, React is really what put the declarative method for UI programming on the map. Today, there's a solid argument that by usage numbers React is the most used UI framework today, and it's children like Vue are high up there too.

Swift also has a similar problem and unlike Rust has a powerful backer, so SwiftUI is in many ways already a vision of what a Rust native UI framework would look like.

View on HN

Swift is in a niche (I hope). Only useful in Apple's walled garden.

I recently spend two years with Swift: It is partly modern, but is slow, obtuse, opaque, and frustratingly archaic in places (its threading model is just awful).

Rust is hard, but is is beautiful, and it is mush more modern than Swift. Rust has an actual community (Swift has acres of astroturf). Rust does not wrap everything in a reference counted object.

If you are programming for iOS then Swift might be a good choice (but since it is not portable, you will regret it if you have success and want to port it - that is the voice of experience). For any other purpose avoid Swift. It has no reason to exist, we should let it go down with Apple wherever Apple is taking itself.

Except the borrow checker hinders the possibility to have components libraries, or a visual designer, unless it is RC all over the place.

Are you afraid of RC?

Everything in Swift is RC, but opaquely.

With the small difference that Swift compiler is RC aware and optimizes them away, unlike Rust, first point.

Second point, exactly because it is opaque, its ergonomics are way better than Rust code.

No Rc, Arc, RefCell, clone(), Pin, pollution across the source code.

Optimises what away exactly?

The reference counting code that can be proven to be unnecessary, given the execution flow of the code.

Rustc doesn't possess such knowledge about library types.

Rust is capable of eliminating unnecessary count increments and decrements for Rc fairly often. The compiler doesn't usually need specific knowledge -- if there is a +1 and then a -1 LLVM is smart enough to cancel that out on its own. I'd actually be curious to see examples where it doesn't.

Me too, because that is the usual hoping the compiler does the right thing, tied to LLVM, and not part of language semantics.

I mean, how often are you cloning an Rc? It’s not like c++ where passing a shared_ptr to a function is going to copy it. Most of the time you’re going to move it.

In GUI designers, everywhere.

Reply on news.ycombinator.com