3 ms·

Swift doesn't have memory ownership because your supposed to use DispatchQueues for that. The end. People asking for this are the people not familiar with App

Swift doesn't have memory ownership because your supposed to use DispatchQueues for that. The end. People asking for this are the people not familiar with Apple's SDK. And btw, DispatchQueues are also available in Linux, GCD has been ported to Linux since the beginning, but neckbeards have been trying to avoid it at all costs because it's Apple, and now they are complaining because Swift has been taking the spotlight from Rust.

mememachine 10y ago
Neckbeards?
solidsnack9000 10y ago
Many of us who like Rust also like Swift, and there are many Swift team members who have contributed to Rust. What I do wonder about it is Swift's plan for things like tiny binaries (no runtime), no standard library, zero-cost (or predictable cost) abstractions...
- Tanegashima 10y ago
  Swift is an Applications programming language first, digging its way down to the system. Rust on the other hand tries to be a system programming language, but with no success at that. And it's not a popular Applications programming language because there's no support from any major software platform vendor. Swift doesn't have a runtime, a linked library isn't a runtime, if you think it is, then you don't have the qualifications to discuss this. It is not a problem to store one 50meg file on my 32GB iPhone or 128GB server, it would be in a 32KB microcontroller, but nobody is trying to ship Swift as a language for those.
  - solidsnack9000 10y ago
    > Swift doesn't have a runtime, a linked library isn't a runtime, if you think it is, then you don't have the qualifications to discuss this. My understanding is that it's called "the Objective-C runtime". I don't need any qualifications to call it that! I'm not sure what distinction you're trying to draw.
bsaul 10y ago
I think this argument is the real justification : "Memory ownership model: an (opt-in) Cyclone/Rust-inspired memory ownership model is highly desired by systems programmers and for other high-performance applications that want predictable and deterministic performance" I think it could be used to implement mechanism such as dispatch queues, which are for now implemented in C.
- Tanegashima 10y ago
  And what's the problem of being implemented in C?
  - bsaul 10y ago
    swift ambitions to become a system programming language. That means to replace C.
    - Tanegashima 10y ago
      Yes, let's rush the development of the language, just to say you can do X. /s
  - coldtea 10y ago
    What's your problem with it being implemented in Swift? Because you phrased your answer in an adversary tone (what with neckbeards, people jealous of Swift "taking the spotlight" etc) as if there was some war going on. Plus the whole, "It will always only be dispatch queues, deal with them, period" vibe I don't really care for. I gather you are not an official spokesperson for the Swift team, and thus qualified to make such a call? If you read TFA, it's an Apple engineer that says: "Memory ownership is a topic that keeps poking its head up here. Core team members have mentioned several times that it's something we're interested in working on. "
    - Tanegashima 10y ago
      Because 99% of the interest in this is people who don't have a life (or a job, or a girlfriend, or...) just to say "see, APPLE COPIED this from the open source community, those bastards" like we constantly see from the Rust guys since Swift debuted. Swift doesn't have not one, but MANY MILLIONS of things necessary to be a systems language before memory ownership. It will be one day, but it's only at it's infancy at 2 years old. Right now, Swift works well for Apps, and it's stupid that low level of memory management when you have GCD.
Gankro 10y ago
The Swift memory model is current incoherent; this is an attempt to fix that. (defining accesses properly, properly preventing conflicting accesses in single threaded ways) Boring single-threaded swift code can currently be incredibly slow for no clear reason; this is an attempt to fix that.(addressors++) The details this manifesto covers need to be settled for ABI-stability, which is still one of the primary goals for Swift. (because it enables making it a part of Apple's OSes)
- Tanegashima 10y ago
  No, it's not.

mememachine 10y ago

Neckbeards?

solidsnack9000 10y ago

Many of us who like Rust also like Swift, and there are many Swift team members who have contributed to Rust. What I do wonder about it is Swift's plan for things like tiny binaries (no runtime), no standard library, zero-cost (or predictable cost) abstractions...

Tanegashima 10y ago
Swift is an Applications programming language first, digging its way down to the system. Rust on the other hand tries to be a system programming language, but with no success at that. And it's not a popular Applications programming language because there's no support from any major software platform vendor. Swift doesn't have a runtime, a linked library isn't a runtime, if you think it is, then you don't have the qualifications to discuss this. It is not a problem to store one 50meg file on my 32GB iPhone or 128GB server, it would be in a 32KB microcontroller, but nobody is trying to ship Swift as a language for those.
- solidsnack9000 10y ago
  > Swift doesn't have a runtime, a linked library isn't a runtime, if you think it is, then you don't have the qualifications to discuss this. My understanding is that it's called "the Objective-C runtime". I don't need any qualifications to call it that! I'm not sure what distinction you're trying to draw.

bsaul 10y ago

I think this argument is the real justification : "Memory ownership model: an (opt-in) Cyclone/Rust-inspired memory ownership model is highly desired by systems programmers and for other high-performance applications that want predictable and deterministic performance" I think it could be used to implement mechanism such as dispatch queues, which are for now implemented in C.

Tanegashima 10y ago
And what's the problem of being implemented in C?
- bsaul 10y ago
  swift ambitions to become a system programming language. That means to replace C.
  - Tanegashima 10y ago
    Yes, let's rush the development of the language, just to say you can do X. /s
- coldtea 10y ago
  What's your problem with it being implemented in Swift? Because you phrased your answer in an adversary tone (what with neckbeards, people jealous of Swift "taking the spotlight" etc) as if there was some war going on. Plus the whole, "It will always only be dispatch queues, deal with them, period" vibe I don't really care for. I gather you are not an official spokesperson for the Swift team, and thus qualified to make such a call? If you read TFA, it's an Apple engineer that says: "Memory ownership is a topic that keeps poking its head up here. Core team members have mentioned several times that it's something we're interested in working on. "
  - Tanegashima 10y ago
    Because 99% of the interest in this is people who don't have a life (or a job, or a girlfriend, or...) just to say "see, APPLE COPIED this from the open source community, those bastards" like we constantly see from the Rust guys since Swift debuted. Swift doesn't have not one, but MANY MILLIONS of things necessary to be a systems language before memory ownership. It will be one day, but it's only at it's infancy at 2 years old. Right now, Swift works well for Apps, and it's stupid that low level of memory management when you have GCD.

Gankro 10y ago

The Swift memory model is current incoherent; this is an attempt to fix that. (defining accesses properly, properly preventing conflicting accesses in single threaded ways) Boring single-threaded swift code can currently be incredibly slow for no clear reason; this is an attempt to fix that.(addressors++) The details this manifesto covers need to be settled for ABI-stability, which is still one of the primary goals for Swift. (because it enables making it a part of Apple's OSes)

Tanegashima 10y ago
No, it's not.