'Swift is the better rust' inspired by the why-ruby-is-an-acceptable-lisp debate:
http://www.randomhacks.net/2005/12/03/why-ruby-is-an-accepta...
Swift is a more convenient Rust
181–190 of 318 posts
Re: Swift is a more convenient Rust
#182Earlier quoted context omitted.
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?
I'm not aware of any mainstream language that doesn't have pointers, the question is whether they expose pointers as a first-class language construct (i.e. you can choose to not dereference them or to do pointer arithmetic) or use them as an implementation detail. In JavaScript's case it's an implementation detail, but one that is extremely relevant when maintaining something in production.
Correction about JavaScript: All non-primitive data types are pass by reference. So not just implementation detail as no valid js interpreter will pass those by value.
Re: Swift is a more convenient Rust
#183I 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 >, }
Something I like about Rust is that it gets very specific and explicit.
On first glance you're like wtf is going on, but you can derive backwards what is happening without having to look for a discussion on language behavior under the hood. Automagic is nice sometimes but I'm the kind of person that needs to say the each word of an acronym to process it.
Rust is like that in a way. You have a mutex on an option type, the option has a heap allocated future that contains data that can live for the lifetime of the program.
This is clear to me because I don't need to fill in blanks. My memory is terrible, I've forgotten so many things I've learned in the past. I could pick them back up quite quickly but I don't have the little facts ready to go. If i wanted to use that future, I know I need to check the mutex lock, check if the option contains a Some(), etc.
Sure this isn't for everyone, but I'm glad we have a tool like this gaining popularity. I have little interest in studying the arcane knowledge of C++ and sorting out what is current and what is obsolete, then arguing with a 30 year veteran that their technique is 20 years stale.
Re: Swift is a more convenient Rust
#184Earlier quoted context omitted.
Swift is in its .NET Framework stage. I’m looking forward to Swift Core!
It might be too late. IMHO Microsoft also did transition too late and these days .NET is less relevant today than it used to be - even many microsoft apps are build using React Native or Electron.
> even many microsoft apps are build using React Native or Electron.
I doubt that .NET has much to do with it. There are just many more JavaScript developers who know how to make UIs.
Re: Swift is a more convenient Rust
#185> it gives you utilities such as Rc, Arc and Cow to do reference counting and “clone-on-right” Not quite right: [1] https://en.wikipedia.org/wiki/Copy-on-write
Cow in Rust does mean “Clone on write,” because Copy is a term of art in Rust (as is Clone).
Re: Swift is a more convenient Rust
#186I 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…
In my toy usage of swift I found it to run dramatically slower than rust. To even get something close to go or java speeds I had to compile with unchecked losing a lot of safety. Other than developing for an apple product, I don't know why I would ever pick swift and I wouldn't ever find myself deciding between rust and swift. It would be swift vs go. When considering rust it would be vs c++ or zig.
In my limited experiences in both languages, it is easier to write inefficient programs in swift. With rust, follow your instinct. As long as it compiles, the performance is usually close to your expectation. With swift, the result may surprise you more often.
Re: Swift is a more convenient Rust
#187Earlier 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…
I've found it's kinda helpful to think of Rust/modern C++ style management as semi-automatic memory management. You control when things are allocated and freed, but you don't bother with the minutia of it unless you're writing a low-level container type.
This is contrast to something like C/Zig, where things are fully manual, or something like Python or Javascript where things are fully handled for you.
Re: Swift is a more convenient Rust
#188Earlier 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?
This is how simple it would be in Clojure, for comparison: (defrecord Task [future task-sender]) Probably used something like this: (defn create-task [] (let [future (atom nil) task-sender (async/chan)] (->Task future task-sender))) Not sure it makes sense but a pretty much direct translation as far as it goes.
So it's the same but without type annotations? Meaning that the clojure IDE has a much harder time providing completion and that you need to write all sorts of tests to get the same guarantees as the rust compiler provides for free. Type systems aren't just about memory representation, they also tell the next programmer about the intent and performance characteristics of the code at hand.
Re: Swift is a more convenient Rust
#189Earlier quoted context omitted.
I'm not aware of any mainstream language that doesn't have pointers, the question is whether they expose pointers as a first-class language construct (i.e. you can choose to not dereference them or to do pointer arithmetic) or use them as an implementation detail. In JavaScript's case it's an implementation detail, but one that is extremely relevant when maintaining something in production.
Correction about JavaScript: All non-primitive data types are pass by reference. So not just implementation detail as no valid js interpreter will pass those by value.
It's not up to the implementation to decide whether to pass by reference or not, but it is up to the implementation whether to use pointers under the hood to model passing by reference. Since there's no pointer arithmetic, other models could theoretically be used to accomplish the same semantics [0], it just happens to be that pointers are by far the most logical choice.
[0] As a silly example: a JavaScript implementation could technically store object references as a URL of an API that allows interacting with the object, as long as this is transparent to the user and the program behaves the same as a pointer implementation (minus non-functional characteristics like performance).
Re: Swift is a more convenient Rust
#190Earlier quoted context omitted.
I don't see why would anybody complain that the tools they bought 10 years ago don't magically do the things that the new tools are doing. It's not like the old tools stopped doing the things they do, right? Anyway, you sel the old machine and get the new one is pretty normal as the Apple devices tend to hold value.
We are talking about Software though. It's not really sustainable to throw buy new stuff all the time when there's not a technical reason for it
That still doesn't mean that the tooling is bad