Live data from Hacker News

Swift is a more convenient Rust

blog.namangoel.com

281–290 of 318 posts

Re: Swift is a more convenient Rust

#281
post #133

Earlier quoted context omitted.

Swift can import C (and C++) modules directly, and it's fairly straightforward to wrap existing C APIs with callbacks to be usable from structured concurrency. Here's an example I just worked on. [1] [1] https://github.com/PADL/NetLinkSwift

This is not what holding swift. What's holding swift is not having a good story to call a swift compiled extension from Python/JS/Ruby/PHP. Python's community is huge, very active, Python is everywhere, and it needs compiled extensions. And tooling to make them BFF, like pyo3 and maturin, is great And that's how we got cryptography, pydantic core, polar... Which motives even tooling to be written in rust as a side ef…

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.

Re: Swift is a more convenient Rust

#282

And C# is a cross-platform and faster Swift :)

Unfortunely, without any mobile OS to call its own, and if only WinDev was so found of adopting .NET, as Apple keeps embracing and pushing Swift, or Google with Java/Kotlin on Android.

With the recent C# focus given to WinUI and WinAppSDK, despite C++/WinRT underpinnings, maybe caused by failure to deliver VS tooling for C++/WinRT after almost a decade, or ongoing cybersecurity considerations, maybe WinDev attitute will change, although I see them more eager to adopt Rust than C#, across the Microsoftshpere blogs and technical notes.

Re: Swift is a more convenient Rust

#283
post #143
post #61

Earlier quoted context omitted.

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.

Depends on the use case. Rust has more explicit types, yes. It's kind of a weak argument against the language though, in my opinion.

Re: Swift is a more convenient Rust

#284
post #269

Earlier quoted context omitted.

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…

Could you explain the semantics of Vec >? What would exist in the memory pointed to by the Vec? What would be the use case for this type?

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 further†

2) now lets dispense with that unique pointer. Its semantics are crucial if T had non zero size because this is why Rust knows the associated memory which is pointed to is "owned" by the Vec. However, for a zero size T this pointer is entirely unused.

3) Capacity at last actually is used, it's a machine word sized integer, so on a modern computer that's 64-bits, 8 bytes to store the capacity of the Vec, which will be the maximum possible unsigned integer of that kind, usize::MAX. It is set to this value when the Vec is created (because the size of T was zero) and never changes.

4) Length is also used, despite not needing to store any data for T the Vec is finite and this tracks how many of the zero size item are in the Vec. Thus, it's a counter.

† In C++ they use the "Empty Base Optimisation" to avoid needing space for such things, in Rust their size is just Zero and so they won't be stored.

What is the use case? Vec is a generic type (Rust's generic growable array of T) so although Vec> seems somewhat useless as a concrete type, it is likely to sometimes occur in generic code.

Example: generic code to do a bunch of potentially fallible operations and remember whether and how they failed for later summarisation may make a type Vec> where E is the failure type. When the operation wasn't actually fallible E is Infallible and instead of an actual growable array type we're just making a trivial counter, our summary is going to inevitably say that all N operations were successful, any code for the "List of failures" summary should even get trimmed as dead code in this case since it depends on an Infallible object and the compiler knows Infallible cannot exist.

Re: Swift is a more convenient Rust

#285
post #269

Earlier quoted context omitted.

Could you explain the semantics of Vec >? What would exist in the memory pointed to by the Vec? What would be the use case for this type?

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 would think if it was actually used in the language extensively I would see library implementors makeing it entirely compile time just like in rust.

I don't disagree that algebraic data types are nice and that Rust has an interesting implementation of them, however this specific example doesn't seem unrepresentable in C++ using std::option and std::variant although the actual semantics relating to usage is easier in Rust.

Re: Swift is a more convenient Rust

#286
post #279

Earlier quoted context omitted.

More than features, JS derives from Lisp because its author was a Scheme implementor. Otherwise function pointers are trivially done even in assembly language, and Smalltalk does have closures. Or maybe you think of the fact that JS uses prototype-based OOP, which makes it closer to what one would do with Scheme (something inspired from CLOS I guess) than Smalltalk ?

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.

Re: Swift is a more convenient Rust

#287
post #285

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…

Bear in mind that the optimization on `Option` isn't specific to that type; it applies to anything that results in one possible value. For example, `Foo` in this example is also zero-sized:

    pub enum Foo {
        Foo,
        Bar(A),
        Baz(B),
        Qux(C),
    }

    pub enum A {}
    pub enum B {}
    pub enum C {}
The optimization applied to Vec also applies to any zero-sized type.

Re: Swift is a more convenient Rust

#288

The article is outright wrong at times (like the need for Box or special status of enums), and is missing 80% reason to use Rust: it helps to ensure correctness of multi threaded synchronization at compile time. So no, Swift is not a "more convenient Rust". It is not Rust at all. It is more of a variant of C#/Java. And I haven't seen any indication that it is an improvement over either. The only reason to use Swift i…

> missing 80% reason to use Rust: it helps to ensure correctness of multi threaded synchronization at compile time Article may have overlooked this since it's been available in recent 5.x and becomes default in 6: Swift 6 brings complete concurrency enabled by default By far the biggest change is that complete concurrency checking is enabled by default. Unless you're very fortunate indeed, there's a very good chance…

Is there a better description of this change? How does it work internally? Is thread safety guaranteed or best effort warning?

How does it work with immutable objects?

Re: Swift is a more convenient Rust

#289
post #281

Earlier quoted context omitted.

This is not what holding swift. What's holding swift is not having a good story to call a swift compiled extension from Python/JS/Ruby/PHP. Python's community is huge, very active, Python is everywhere, and it needs compiled extensions. And tooling to make them BFF, like pyo3 and maturin, is great And that's how we got cryptography, pydantic core, polar... Which motives even tooling to be written in rust as a side ef…

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.

Re: Swift is a more convenient Rust

#290
post #129

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…

In this context, ML is Meta Language: https://en.wikipedia.org/wiki/ML_(programming_language)

ML is such an overloaded acronym in software that people really need to stop using it or ALWAYS clarify it.

ML = Machine Learning

ML = Machine Language

ML = Markup Language

ML = Meta Language

And I always see ML in the Meta Language sense to be the biggest culprit where writers assume the reader knows it, even though it's probably the least widely known.

Post reply on HN