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 Foundation dependencies.
Swift is a more convenient Rust
11–20 of 318 posts
Re: Swift is a more convenient Rust
#12Re: Swift is a more convenient Rust
#131. 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 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 (as in OP's post), OCaml[1], and Scala[2]. These alternatives take the approach that tracking ownership is not the default, which is fine for the majority of programs and far more ergonomic.
There's also a corollary
3. The age of Smalltalk is over. It's now the age of ML. (Amusingly, going backwards in time, from 1983 to 1975). The languages that dominated the 2000s (Ruby, Python, Javscript, PHP) were all more or less derived from Smalltalk (everything is an object! dynamic types! runtime metaprogramming!) The new languages (Rust, Scala, Swift, Kotlin, etc.) are ML family languages. Similarly, back in the day you could learn, say, Ruby, and still be reasonably proficient in Python or JS. Now you can learn, say, Scala, and pick up Rust or Swift reasonably easily.
Re: Swift is a more convenient Rust
#14One way that Swift is certainly not more convenient than Rust is the tooling. I use a 2018 MacBook Air, using macOS 12, which is now unsupported by Xcode. Meanwhile SourceKit-LSP is treated as very much a second-class citizen. But Rust 1.81 and rust-analyzer build and run just fine.
You can install Swift on Linux if you want and code away, just like with Rust - but as it hasn't really caught on for anything other than building apps for the Apple ecosystem, it's not a particularly normal thing to do.
Re: Swift is a more convenient Rust
#15Yes! And C# is just more convenient C.
Re: Swift is a more convenient Rust
#16 struct Task {
future: Mutex>>,
task_sender: SyncSender>,
}Re: Swift is a more convenient Rust
#17One way that Swift is certainly not more convenient than Rust is the tooling. I use a 2018 MacBook Air, using macOS 12, which is now unsupported by Xcode. Meanwhile SourceKit-LSP is treated as very much a second-class citizen. But Rust 1.81 and rust-analyzer build and run just fine.
Not to praise Swift, but Swift and Xcode are unrelated projects. Saying that Swift is inconvenient because of Xcode issues is like saying C++/C# is inconvenient because of Visual Studio. You can install Swift on Linux if you want and code away, just like with Rust - but as it hasn't really caught on for anything other than building apps for the Apple ecosystem, it's not a particularly normal thing to do.
Re: Swift is a more convenient Rust
#18Rust 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.
Re: Swift is a more convenient Rust
#19Re: Swift is a more convenient Rust
#20Hmmm...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…
Scala is quite a bit older than the others, I'd put it in a previous generation.
I always saw Kotlin as a more convenient Java, without Scalas heavy tilt towards FP.
Java also added the equivalent of sum types with sealed interfaces and exhaustive pattern matching, does that make Java an ML language?
Many older languages by now have incorporated valuable parts of FP/ML (including Javascript, Java, C++, ...)
Borrowing some concepts from ML doesn't put these languages in the ML family.