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

291–300 of 318 posts

Re: Swift is a more convenient Rust

#291

Post by afdbcreid »

consteval wrote: post #264
neonsunset wrote: post #254

Earlier quoted context omitted.

The assessment on C# does not match language spec at all. Not only instance methods on C# structs are implicitly byref, you can easily pass structs by reference via ref, out and in keywords. On top of that, ref structs can hold `byref` pointers aka 'ref' keyword which can point to arbitrary memory, or have references to other structs/variables/anything. There is also regular C syntax with &T and T* for unmanaged refe…

Wow, I was not aware of the monomorphization of structs in C#. That's very interesting, I wonder how you're able to mix generic structs and generic classes seamlessly. > you can easily pass structs by reference via ref, out and in keywords. On top of that, ref structs can hold `byref` pointers aka 'ref' keyword which can point to arbitrary memory These are not features I've encountered. I wonder how you solve danglin…

> I wonder how you solve dangling references when those references could point to automatic stack variables.

By restricting them, to, essentially, disallow storing `ref`s on the heap.

Re: Swift is a more convenient Rust

#292

Post by afdbcreid »

Klonoar wrote: post #116
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.

I've said it in other comments on HN over the years, but yes - I agree. That `.variant` syntax is annoying as hell to dig through when you don't have an IDE to rely on for jumping around. Rust (or your choice of other more explicit language) is just generally way more clear about what's being used. The way I usually settle on describing it is that this feature solved for people writing code, but code is read more tha…

You will probably be sad to hear that allowing to omit the type in Rust is considered, and has been proposed many times.

Re: Swift is a more convenient Rust

#293

Post by tialaramex »

jpc0 wrote: post #285
tialaramex wrote: post #284

Earlier quoted context omitted.

The Vec itself carries four items, a unique pointer to T, a capacity, an Allocator A, and a current length. It is a generic type, generic over the type T and the allocator A. 1) lets dispense with the Allocator, for a typical Vec the global Allocator is used, so this type has no size, every Vec is talking about the same global Allocator, its state is tracked internally to itself. We need not consider this object furt…

So from what I've played with Option in rust would be directly equivalent to std::nullopt_t and has similar semantics in vectors, ie it just increments length. There seems to be slightly more compile time work done in Rust but using the use case you described the concept of a Vec > can just as easily be represented as std::vector with very similar semantics although possibly slightly less optimisation, although I wou…

How do you get to the idea that std::vector "just increments length" ?

I spent some time trying this out in Godbolt†, and then by hand, and then reading the Microsoft STL, and exactly as I'd assumed before I read your comment it was a growable array of one byte objects, with the type std::nullopt_t, 400 objects? 400 bytes. 4 million objects? 4 million bytes.

† Including longer than I'd like to admit forgetting that C++ silently copies large objects without telling you and so my diagnostic was actually making a new std::vector because I forgot to write an ampersand to make it a reference...

It is still possible I missed something and so I invite you to tell me what that was. But overall my thought is that you've missed the whole point and are in the same place as when C++ programmers get confused and think Empty types (like Infallible) and Zero Size Types (like Option) are somehow the same, which is like confusing zero (The additive identity) with one (the multiplicative identity).

Re: Swift is a more convenient Rust

#294

Post by naman34 »

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…

I added a new section to the post with links and information to dispel this myth that Swift is only for Apple platforms.

Re: Swift is a more convenient Rust

#295

Post by naman34 »

lukeh wrote: post #130
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…

Well, that article also presents a pure Swift (non-Foundation) solution, WeakRef.

And that article is from 2020. A lot has changed since.

Re: Swift is a more convenient Rust

#296

Post by j-pb »

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

It looks complicated but if you think about it as a series of property descriptions it becomes much easier.

I'm gonna make it worse first by substituting the `BoxFuture` type alias with its definition but that makes it easier to explain.

  future: Mutex + Send + 'static>>>>,
What this means is that the future field stores something that is a:

- Dynamically dispatched object (with a V-Table) that implements methods from the Future trait, and returns nothing () = void. (dyn Future)

- That thing needs to be sendable between Threads (+ Send)

- And must potentially live forever (+ 'static)

- The dynamic dispatch stuff only works with heap allocations because the V-Table pointer is stored in the double wide smart-pointer. In this case we use a Box which means only one thing/thread can hold it at a time (unlike reference counted Rc/Arc).

- That allocation of the Heap allocation must not be moved around in memory. (Pin)

- that thing might not be there (it can be Null), but replacing/taking/putting the thing will be secured by the mutex so that's a nice guarantee for multithreading (Option)

- access to a thing is synchronised via a mutex (Mutex)

So while it looks horrible at first sight, it is simply telling you a lot about the guarantees of that particular type.

Re: Swift is a more convenient Rust

#297

Post by pjmlp »

lispm wrote: post #286
pjmlp wrote: post #279

Earlier quoted context omitted.

Prototype-based OOP came first in SELF, a Smalltalk dialect. CLOS is an evolution from Flavors and similar Lisp packages, and outside Lisp, Julia would be the closest to it, in modern times, not counting Dylan.

> Prototype-based OOP came first in SELF Isn't prototype-based OOP roughly a decade older? -> for example "Director" from Ken Kahn is from 1976.

Maybe, I never heard of "Director", its documentation seems hard to come by in digital world.

Although Wikipedia also points out that, https://en.wikipedia.org/wiki/Prototype-based_programming

Actually your remark has made me dive into alternative prototype based languages.

Re: Swift is a more convenient Rust

#298

Post by lispm »

pjmlp wrote: post #297
lispm wrote: post #286

Earlier quoted context omitted.

> Prototype-based OOP came first in SELF Isn't prototype-based OOP roughly a decade older? -> for example "Director" from Ken Kahn is from 1976.

Maybe, I never heard of "Director", its documentation seems hard to come by in digital world. Although Wikipedia also points out that, https://en.wikipedia.org/wiki/Prototype-based_programming Actually your remark has made me dive into alternative prototype based languages.

Check the resume of Ken Kahn: http://toontalk.com/resume.pdf

Director Guide: https://dspace.mit.edu/bitstream/handle/1721.1/6302/AIM-482b...

Creation of Computer Animation from Story Descriptions: https://dspace.mit.edu/bitstream/handle/1721.1/16012/0720063...

The other mentioned tool was Thinglab, by Alan Borning

https://www.ijcai.org/Proceedings/77-1/Papers/085.pdf

"The Smalltalk notion of an object has been modified and extended in a number of ways. In ThingLab, objects are constructed interactively by editing and making descendants of prototypes. An abstraction hierarchy is used that allows arbitrarily many levels of both parents and descendants, with the problem of objects with several parents being handled by the technique of merging. There is no distinction between classes and instances."

"The Programming Language Aspects of ThingLab, a Constraint-Oriented Simulation Laboratory" https://dl.acm.org/doi/pdf/10.1145/357146.357147

"CLASSES VERSUS PROTOTYPES IN OBJECT-ORIENTED LANGUAGES" https://dl.acm.org/doi/pdf/10.5555/324493.324538

Available in the Browser, running in Smalltalk: https://constraints.cs.washington.edu/thinglab/

Re: Swift is a more convenient Rust

#299

Post by pjmlp »

BiteCode_dev wrote: post #289
pjmlp wrote: post #281

Earlier quoted context omitted.

What Python needs is to catch up to SELF, Smalltalk, Common Lisp, and either embrace PyPy, or finally get a mature JIT into CPython. Thankfully, Facebook and Microsoft are making it happen.

Yes, but it's a completely unrelated matter: even with a JIT you'll want compiled extensions since you can't beat hand crafted SIMD for the scientific stacks or machine learning.

Ever heard of intrinsics?

Maybe spend some time reading about other JIT languages expose SIMD to developers, without requiring folks to go down to C.

Which incidentally is what all those Python DSLs for GPGPU APIs also do, with the caveat of not being that useful for general purpose programming outside machine learning algorithms.

Re: Swift is a more convenient Rust

#300

Post by pjmlp »

lispm wrote: post #298
pjmlp wrote: post #297

Earlier quoted context omitted.

Maybe, I never heard of "Director", its documentation seems hard to come by in digital world. Although Wikipedia also points out that, https://en.wikipedia.org/wiki/Prototype-based_programming Actually your remark has made me dive into alternative prototype based languages.

Check the resume of Ken Kahn: http://toontalk.com/resume.pdf Director Guide: https://dspace.mit.edu/bitstream/handle/1721.1/6302/AIM-482b... Creation of Computer Animation from Story Descriptions: https://dspace.mit.edu/bitstream/handle/1721.1/16012/0720063... The other mentioned tool was Thinglab, by Alan Borning https://www.ijcai.org/Proceedings/77-1/Papers/085.pdf "The Smalltalk notion of an object has been modifi…

Thanks for the overview.
Post reply on HN