Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
It’s safe compared to most other languages.
I have a decent knowledge about it and if you like we can talk about the topics that you mentioned.
1. unwrapping is explicit and safer than implicit in java and c# for example.
2. this is uikit and storyboard, remnant of objc, not swift's fault.
3. fair. Reason is to avoid performance penalties.
4. that‘s not possible. Where did you get this one from?
5. not really sure about that but afaik not a problem of swift but the host runtime.
6. seriously? Swift has the best and most safe threading stuff. Other languages don’t even have actors.
7. well, what should happen on invalid type casts? Fatal error is the most safe approach. And you can do safe type conversions which evaluate to nil.
8. huh? Like what?
Also not sure what you mean with failed allocations. Swift has RAII and even failable initializers, which makes it more safe than any other language that I know in therms of allocation. -
@Lensflare how about the basics. When Swift fails to allocate memory, there is nothing to check, not like a null pointer to check or even a 1984 (OSError) MemError(void) function to call… things just go sideways; software crashes.
Accordingly it doesn’t sound like a good idea to use Swift in things like automobile software, medical ventilators, X-ray machines, CT scanners, aircraft software, navy ship software, nuclear missile software, drones, SpaceX rockets, and so on. -
@xcodesucks I literally never have encountered such a case. Can you give me an example? Does it happen when there is not enough space available?
-
@Lensflare
Ok, show me how to do this in Swift:
int *ptr =NULL;
ptr = ( int * ) malloc( sizeof( int ) );
if ( ptr != NULL ) {
// Allocation succeeded, use ptr
}
else {
// Allocation failed, handle error
printf( "Memory allocation failed.\n" );
}
Because god knows that memory is tight in a Thunderbolt connector head... -
@xcodesucks this is a weird example for multiple reasons.
You know that in swift we cannot allocate int on the heap. So I will use a class wrapper:
class IntWrap {
var i: Int
init?() {
i = 42
}
}
let a = IntWrap()
a is an optional and will be nil if the initializer fails.
But I don’t know if it will fail in the same when the allocation fails due to memory constraints.
It never happened to me.
I don‘t know if there is a way to check for that.
Maybe RawPointer api is the way to go. -
@12bitfloat @12bitfloat, I firmly believe that crashing a program is never acceptable or safe.
Imagine your steering column is drive-by-wire, a common feature in many cars today, and it’s written in Swift within the car’s firmware. Now, imagine if the software crashes.
Consider the scenario where your mother is on a ventilator, and its firmware is written in Swift.
What if the code for the predator drone was written in Swift?
I'm not sure when it became "ok" for an app to crash but I'm not likely to ever be "ok" with it. Crashing app means shit-code, just that simple. -
@xcodesucks By that definition there aren't any safe languages, so safety as a concept can only apply to end-user software. Software that can't crash can be written in Swift relatively easily like any other by-value language, by avoiding the heap.
-
@xcodesucks For the purpose of language development though, it's more useful to state that "some software can never crash", which opens the gate for really interesting languages that allow you to prove the maximal size of heap structures, and force you to handle trivial failures like a division by zero (an optionally handled error in nearly all languages), without burdening these languages with the expectations of convenience levied against those you use to build clients for your favorite dying dev bulletin for smartphones.
-
@xcodesucks I don't disagree with you that crashing the program is bad
But that's just not what "unsafe" or "memory safety" means. Crashing IS memory safe
The reality is that "crash safety" is an NP hard problem. It's not solvable. And using this as an argument against languages (like rust) which improve on robustness in so many other ways is kinda ignorant -
@Lensflare Kudos to you for going literal and noticing the 'int'. I suspect my cranky side put 'int"' into the malloc().
I just listened to another WWDC25 session, the one on Improve Memory Usage and Performance with Swift. It feels like the problems I pointed out are known to the team but they may be in denial. -
@lorentz
Re: By that definition there aren't any safe languages
Yep, nailed it. No such thing as a "safe car" either. Safety is always the responsibility of the driver. Discipline is key.
Re: so safety as a concept can only apply to end-user software.
Nope, not at all. My shit has been running for over a decade, no crashes.
RE: Software that can't crash can be written in Swift relatively easily like any other by-value language, by avoiding the heap
Beg to differ. Avoiding the heap has nothing to do with no-crash software or firmware. You can blow out a stack easy enough. There is no such thing as "infinite memory". Managing your memory like a BOSS has everything to do with no-crash software. -
@Lensflare Re: give me an example? ... not enough space available?
small memory models in any firmware force disciplined use of resources. Firmware in your TV, in your refrigerator, in your smart lightbulb, your ring doorbell, your AirTag, your USB-C or Thunderbolt cable.
Most of the computers out there have tiny memory models. (just count your cables, subtract your laptops, desktops, phones and iPads, there's your minimal "most")
Apple just advertised Swift Embedded last year for the ESP32C6 system: https://developer.apple.com/videos/... and then doubled down this year telling us they are using it in Secure Enclave Processor found in their devices (this could be a major fuckup). Be aware that the ESP32C6 is fairly bloated for an "embedded" system; try to fit that into the lightening cable head! (LMAO) -
@xcodesucks If you agree with me that by your definition no language can be safe, why would you interpret my claim about heapless Swift as if I said that it is safe by your definition? Clearly, I meant that avoiding the heap saves you from this specific error, while other techniques (such as avoiding recursion) save you from other specific errors, never completely eliminating the possibility of a crash.
-
@xcodesucks I didn’t say or meant to say that out of memory is unlikely to happen or is not an issue. Of course it is. All I‘m saying is that I don’t have experience with it and I don‘t know how to deal with it in Swift.
Related Rants
Swift 😐
Oh Swift why
Swift: Have you ever noticed...
How many times the word "Safe" is used when describing Swift, yet there is no way to programmatically determine if a memory allocation failed?
How many ways this "Safe" system has a way of crashing:
1. Unwrapping a Nil Optional
2. Disconnected Outlets
3. Out-of-Range Array Access
4. Accessing Uninitialized Variables
5. EXC_BAD_ACCESS (Memory Access Errors)
6. Threading and Actor Isolation Issues
7. Type Casting Errors
8. Uncaught Language Exceptions
9. (fill in the blank?)
What frustrates me is that Swift lacks a language-level way to check if heap memory allocation succeeded. When you create an object like MyClass(), Swift assumes success—if allocation fails, the process dies instead of allowing your code to gracefully handle the failure.
And to avoid having pointers, it creates this horrendously random undocumenting syntax salad that is worse than ADA.
Swift, when you wanted a liter-bike and you get something else
rant
swift