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 is a more convenient Rust
51–60 of 318 posts
Re: Swift is a more convenient Rust
#52Hmmm...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…
I think if Linear/Affine typing was a default anyone wanted, Haskell hackers (who are usually pretty concerned with performance) would regard it as more than a research oddity. When people bitch about the borrow checker, what they usually mean is “std::move is a great wristwatch but god damn does it chafe as a chastity belt”.
Re: Swift is a more convenient Rust
#53You can do the exact same thing in Rust:
impl Coin {
fn valueInCents(&self) -> u8 {
match self {
Self::Penny => 1,
Self::Nickel => 5,
Self::Dime => 10,
Self::Quarter => 25,
}
}
}Re: Swift is a more convenient Rust
#54Earlier quoted context omitted.
[flagged]
Is upgrading every 5-6 years to be able to write code considered normal in the Apple world? I'd been comfortably writing code in several languages using latest toolchains on a decade-old Intel machine just a few months ago, and was forced to upgrade because one of the components died. Otherwise I'd be using it for at least five more years.
But for those of us who use a computer every day, surely it makes sense to stay a bit cutting edge and it won't break the bank either since it is literally our income.
Re: Swift is a more convenient Rust
#55Re: Swift is a more convenient Rust
#56I 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 >, }
Re: Swift is a more convenient Rust
#57I 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 >, }
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 configuring it (namely, tokio-subscriber seems to encode all the configuration information into types, so you can't just return a Subscriber or Subscriber builder from a function and then add it as a logger...the documentation gives no hint on what trait or type I'm meant to return here).
Re: Swift is a more convenient Rust
#58Swift 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.
Try to make Rust interop with C++, C and Objective-C as easy as Swift does it.
Re: Swift is a more convenient Rust
#59Re: Swift is a more convenient Rust
#60Hmmm...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…
Ad 3) 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++, ...) Bor…
> Java also added the equivalent of sum types with sealed interfaces and exhaustive pattern matching, does that make Java an ML language?
I don't think so. Java heavily relies on mutation and you can see this throughout the whole ecosystem and even the JVM whereas OCaml doesn't. Kotlin also relies on mutation (it relies on Java's stdlib after all) whereas Scala has its own stdlib with both mutable and immutable classes but defaulting to immutability almost everywhere.
So if anything, Scala can be called an ML language imho.