Swift is a more convenient Rust • Hacker News Board

Re: Swift is a more convenient Rust

#301

Post by jpc0 » Sun, Sep 08, 2024, 8:35 PM UTC

tialaramex wrote: post #293

jpc0 wrote: post #285

Earlier quoted context omitted.

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…

[dead]

Re: Swift is a more convenient Rust

#302

Post by Klonoar » Sun, Sep 08, 2024, 9:58 PM UTC

afdbcreid wrote: post #292

Klonoar wrote: post #116

Earlier quoted context omitted.

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.

I can only hope that it's been proposed many times and not actioned on before means there's been enough pushback, considering one of the entire points of the language is the explicit nature of it.

Do you have a link for an RFC or GitHub issue or anything? Would be curious to see.

Re: Swift is a more convenient Rust

#303

Post by w10-1 » Sun, Sep 08, 2024, 11:19 PM UTC

BiteCode_dev wrote: post #160

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

I'm not sure scripting-language interop is holding back Swift, but ...

> call a swift compiled extension from Python/JS/Ruby/PHP

The story there is excellent.

Here's a Swift function callable from C

    @cdecl("myfunc")
    public static func f(){...}

C/C++ types are mostly handled automatically (including sharing memory management), but it can be tricky.

To build a library to load and call from any language:

    swiftc mine.swift -emit-library -o libmine.dylib

E.g., calling from java 22 FFI:

https://foojay.io/today/java-panama-polyglot-swift-part-2/

But most people instead use a slower json server network interface because (sadly) json is the lingua franca for scripting and Swift Codable makes it trivial to map the json to a swift type.

Re: Swift is a more convenient Rust

#304

Post by arghwhat » Mon, Sep 09, 2024, 7:57 AM UTC

pjmlp wrote: post #277

arghwhat wrote: post #245

Earlier quoted context omitted.

What people could use is not at all what mainstream is. You can use D, OCaml, F# and brainfuck, but they are not mainstream. To define what was mainstream we'd need to talk to people coding at the time and ask them about popularity, adoption, tooling availability, etc. and what languages people were likely to use rather than what was available. And no, I have no need for researching that as I have no use of the infor…

Then you should not have mentioned Forth or C at all, only to show not having a clue about programming languages history. Besides, any Assembly programmer is well aware of what stack memory is all about, bring us even further back than 1958.

> Then you should not have mentioned Forth or C at all, only to show not having a clue about programming languages history.

The whole point was that these well-known mainstream languages provided the feature claimed to first have arrived in Rust, to make it clear that it was not just theoretical or some obscure language.

It's not my fault that you misunderstood the topic or the idea of what makes something mainstream, and instead read this as an elaborate history class stating the absolute first discovery of the idea.

> Besides, any Assembly programmer is well aware of what stack memory is all about, bring us even further back than 1958.

The instructions you refer to were designed to support stack-based languages, not the other way around.

Re: Swift is a more convenient Rust

#305

Post by arghwhat » Mon, Sep 09, 2024, 8:18 AM UTC

Ygg2 wrote: post #276

arghwhat wrote: post #268

Earlier quoted context omitted.

> It's not rocket science. If you are calling malloc/free to maintain your memory you're doing manual memory management. Sure, and when I do the same in Rust I'm also doing manual memory management. So by your definition, both Rust and C are manual memory languages. > You're confusing default memory management with what's possible. Ah, so we care about the default, which I pressume is what the language semantics them…

> Sure, and when I do the same in Rust I'm also doing manual memory management. So by your definition, both Rust and C are manual memory languages. You're being very thick on purpose. In Rust you need to reach for foreign functions to implement malloc/free. > So by your definition, both Rust and C are manual memory languages. No. By my definition what is the default semantics determines if it's manual or automatic. I…

> You're being very thick on purpose. In Rust you need to reach for foreign functions to implement malloc/free.

I think you're mistakenly thinking of calling out to the (rust-lang maintained) libc crate's malloc/free functions. That's not the case - the standard library provides `std::alloc`, which is the allocator also backing Box and Vec.

> No. By my definition what is the default semantics determines if it's manual or automatic. It's CS 101.

Your definition of default semantics - "in C it's not what the language does but what happens when you call random library functions, while in Rust it's the opposite" - makes no sense at all.

C isn't considered a manual language because of default semantics, but because people have chosen to mainly rely on such paradigm.

> No, no you aren't. At least not explicitly. I assume you mean GC, if it has or doesn't have arenas is implementation detail.

Yes, whether any allocator has an arena is an implementation detail.

Whether you call `malloc` or `new`, or you have Go or Java do a heap allocation for you (which, to nitpick, is not actually the job of the garbage collector), the use of an arena is an implementation detail. In case of GC, the availability of optimizations also depend heavily on whether it's a moving GC.

Re: Swift is a more convenient Rust

#306

Post by Ygg2 » Mon, Sep 09, 2024, 9:26 AM UTC

arghwhat wrote: post #305

Ygg2 wrote: post #276

Earlier quoted context omitted.

> Sure, and when I do the same in Rust I'm also doing manual memory management. So by your definition, both Rust and C are manual memory languages. You're being very thick on purpose. In Rust you need to reach for foreign functions to implement malloc/free. > So by your definition, both Rust and C are manual memory languages. No. By my definition what is the default semantics determines if it's manual or automatic. I…

> You're being very thick on purpose. In Rust you need to reach for foreign functions to implement malloc/free. I think you're mistakenly thinking of calling out to the (rust-lang maintained) libc crate's malloc/free functions. That's not the case - the standard library provides `std::alloc`, which is the allocator also backing Box and Vec. > No. By my definition what is the default semantics determines if it's manua…

> That's not the case - the standard library provides `std::alloc`, which is the allocator also backing Box and Vec.

Again, emphasis on the word, default. How are you using Box and Vec. Are you by default encouraged to drop them manually via Allocator?

No, you aren't. You're heavily discouraged via usage of `unsafe`, you are discouraged because the compiler does automatic `alloc`/`drop`.

You have to go out of your way to do manual memory management.

> Your definition of default semantics

I showed you what happens when you apply the non-default semantics of a language to C. You end up with nonsensical statements like C is a GC language. Just because a style is possible in language X doesn't mean language X is of that style.

> C isn't considered a manual language because of default semantics, but because people have chosen to mainly rely on such paradigm.

And why is that? Because the default affordance of the language makes it so that way of usage is the most natural to most users. You could put everything in the stack, but that would be extremely torturous for most users, so they use malloc/free.

You give people a knife, of course they will grab it by the handle.

Re: Swift is a more convenient Rust

#307

Post by eptcyka » Mon, Sep 09, 2024, 10:49 AM UTC

arghwhat wrote: post #118

x3ro wrote: post #21

Earlier quoted context omitted.

The defacto standard matters. The vast majority of Swift programmers will be using Xcode, and I definitely immediately think of the pains I've had with Xcode when I hear Swift. For example, I don't know of any other good IDE environment for Swift, though maybe there is one. You could also argue that e.g. Rust is not cargo, but almost every Rust programmer will be using cargo. Sure I could use something else, but why…

You don't use Xcode to write Swift, you use Xcode to write Apple apps which you happen to do in Swift. No matter the language, you need Xcode to write those apps. Equalling Xcode and Cargo makes no sense. A similar situation to Xcode and Swift would be like Visual Studio and C# on Windows. Many developers use these tools, but they are not the language ecosystem, and the Cargo equivalents are entirely separate (Nuget,…

If you argue about nomenclature, yes, Xcode and cargo fit into entirely different categories. However, they are still comparable you can't feasibly escape either to develop Swift or Rust apps the way most people develop them.

Re: Swift is a more convenient Rust

#308

Post by jnrk » Mon, Sep 09, 2024, 4:43 PM UTC

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…

> look at IBM abandoning Swift on the server not that long ago

That was back in 2019..

Re: Swift is a more convenient Rust

#309

Post by naman34 » Tue, Sep 10, 2024, 11:08 PM UTC

SneakerXZ wrote: post #99

> Swift use value-types by default with copy-on-write semantics. This isn't true. Copy-on-write semantics are implemented only for arrays, dictionaries, and strings. Swift value-types are copied immediately. https://docs.swift.org/swift-book/documentation/the-swift-pr...

The documentation uses “copied” for value types that are copy-on-write.

The documentation has oversimplified a bunch of the mental model and it causes incorrect understanding.

Swift’s documentation is quite bad TBH. The biggest thing that still needs to be improved a lot.

Re: Swift is a more convenient Rust

#310

Post by naman34 » Tue, Sep 10, 2024, 11:12 PM UTC

ahlCVA wrote: post #252

lukeh wrote: post #11

I don’t know Rust, but I’m loving Swift for systems programming. Most recent project was an 802.1Q SRP implementation and I couldn’t imagine going back to C. Higher up the stack, I’ve also used it with a custom runner to build the business logic for an embedded Flutter app. My only beef is that the binaries are quite large. I’m hoping the new Foundation will improve things, in the interim I’m trying to eliminate my F…

Fascinating that somebody is using Swift "in production" for that! I work on small-ish embedded Linux systems and I've been looking for an alternative to C for a long time. Rust does not fit the bill, both because I don't enjoy the ergonomics of it (but I could get over that were it not for the other issues) and because the binaries are huge, so unless you go for a busybox-style multicall binary (and even then) you'l…

Sadly, Swift also produces large binaries unless you use Embedded Swift which is still early.