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

151–160 of 318 posts

Re: Swift is a more convenient Rust

#151

Post by [deleted] »

XorNot wrote: post #57
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 >, }

Honestly that one I can read (I am just now in earnest trying to learn Rust). What I've been banging my head into is trying to get a suite of boilerplate libraries together to make basic things happen. Got directed from slog to tokio-tracing for logging, so dove into setting up my basic "--log-level", "--log-format" CLI options I add to every non-trivial program in Rust and ran into...whatever is going on with config…

[deleted]

Re: Swift is a more convenient Rust

#152

Post by robjwells »

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.

Fortunately in Rust you can have it both ways, as in `Type::Variant` most of the time and `use Type::Variant; … Variant …` in cases where the type name just causes noise.

Example in the playground: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Re: Swift is a more convenient Rust

#153

Post by pornel »

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.

Rust is its own thing, but use of algebraic data types + pattern matching and type inference makes it feel closer to OCaml than C++. The original Rust compiler has been written in OCaml, so that's definitely an influence.

Re: Swift is a more convenient Rust

#154

Post by knighthack »

zer0zzz wrote: post #66
K0nserv wrote: post #32

I love both Rust and Swift, they have their respective strengths. I would say Swift has a less noisy surface syntax, but instead uses more dedicated keywords and compiler magic. This is nicer, but means some areas are "compiler only territory". In many cases Swift would be a better choice than Rust, when the convenience and developer experience is worth trading for some performance. However, Swift's biggest problem i…

> However, Swift's biggest problem is that any usage outside of the Apple ecosystem is a second(or third) class citizen. Until this is solved, Swift will remain mostly an Apple only language, regardless of how nice it is. I think a time goes on this is more and more only a perception and not a reality. However perception is really important because it’ll mean even if it’s a great language with a great set of tools an…

The issue is not "as time goes on".

The issue is now - the use of Swift outside of the Apple ecosystem is remarkably stifled, given the lack of Apple support.

A language truly acquires mainstream mindshare and community, only if it can extend its use beyond Apple's OSes.

Re: Swift is a more convenient Rust

#155

Post by kenmacd »

nurettin wrote: post #74
swiftcoder wrote: post #22

Earlier quoted context omitted.

I'll grant you that is probably too complicated an example to appear early in the docs, but how often are you actually building multithreaded job dispatch systems from scratch (which appears to be what this example is doing), and how simple would it be in other languages?

It would be ridiculously simple in go with channels.

Would it though? Just running things 'async' is simple, but it's also simple in Rust. I wouldn't figure writing an Executor would be any easier in Go than the Rust example at https://rust-lang.github.io/async-book/02_execution/04_execu...

Re: Swift is a more convenient Rust

#156

Post by kenmacd »

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

They run in to async, but do they run in to the internals of how that code is executed?

The chapter that example is from includes the disclaimer:

> In this section, we'll cover the underlying structure of how Futures and asynchronous tasks are scheduled. If you're only interested in learning how to write higher-level code that uses existing Future types and aren't interested in the details of how Future types work, you can skip ahead to the async/await chapter.

Re: Swift is a more convenient Rust

#157

Post by mogoh »

Always, when I read those postings that praise Swift, I wonder how good is the developer experience is if you don't use any of the Apple/MacOS ecosystem (except Swift, of course). I have not met any Swift developer who is not developing on macOS, usually for macOS. That makes me very skeptical that non-Mac devs are treated as second-class citizens. I am not only talking about the standard library, but also about the tooling, LSP, libraries, tutorials and so on. I totally believe that Swift is a good language, but I guess it is only good if you are on macOS.

If you are developing with Swift but not using a Mac at all, I would love to hear how your experience has been.

Re: Swift is a more convenient Rust

#158

Post by bryancoxwell »

lolinder wrote: post #136
est31 wrote: post #27

Earlier quoted context omitted.

> Rust is the first language to bring non-GC automatic memory management to the mainstream. It won't be the last and it might well be the worst. Other languages in this space include Swift Rust's memory management is not automatic, you have to explicitly manage memory. It's just made extremely easy for you by the language thanks to stuff like RAII, and there is checks that prevent memory safety violations like double…

> Rust's memory management is not automatic, you have to explicitly manage memory. It's just made extremely easy for you by the language thanks to stuff like RAII, and there is checks that prevent memory safety violations like double free. But those checks won't prevent leaks, although the many lints do make it harder to forget about a value. By this logic no language on earth has automatic memory management. I've sp…

Pointers in JavaScript? I’m far from a JS expert, but didn’t think the language had pointers. Could you explain what you mean here?

Re: Swift is a more convenient Rust

#159

Post by twoodfin »

rcruzeiro wrote: post #144
bad_user wrote: post #125

Earlier quoted context omitted.

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

https://courses.cs.washington.edu/courses/cse590p/05au/p50-b...

This paper makes a strong argument that “pure” tracing garbage collection and “rote” reference counting are effectively duals at the opposite ends of a spectrum of implementation choices.

For example, GC’s often optimize differently for young vs. old objects. How do they distinguish these? By “counting” (one bit) their references across one or more traces in a series of sweeps.

Re: Swift is a more convenient Rust

#160

Post by BiteCode_dev »

lukeh wrote: post #133
BiteCode_dev wrote: post #18

Swift won't be able to compete with rust until it has a great scripting story. Rust is currently the defactor choice if you want to make something with js/python bindings, of id you want to speed up a dynamic bottleneck because it makes it super easy. Swift doesn't even have a good ffi.

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 effect, and how we have uv and ruff.

The scripting community is the most active, if you got them on your side, you get access to a huge pool of devs.

Post reply on HN