191–200 of 263 posts
The Swift feature I miss in other languages is `enum` cases with parameters and `switch` blocks having to cover all cases, it's so convenient.
I believe Swift takes the switch farther than match in Rust, because it tries to deal with API stability (e.g. a system library adding new possible cases)
Earlier quoted context omitted.
It could catch them before that using ownership, at the cost of lower performance. Though Swift concurrency is mostly about "concurrency" not "parallelism", which is the one that has data races.
Ownership hasn’t shipped yet.
Earlier quoted context omitted.
Yet another chrome wrapper, but with VC funding.
And? Brave (VC funded) is also a Chromium wrapper and Edge (Microsoft owned) is also one as well and both of the somehow managed to beat Firefox in usage. So what is you point? Chrome and its derivatives is the reason why browsers like Firefox is failing to keep up and continues to lose users. Using anything other than Chrome for a modern web browser is a losing battle. (Brave already tried that with Firefox and quic…
I was answering a question asking what it was. Are you saying my answer was wrong?
> Brave (VC funded) is also a Chromium wrapper and Edge (Microsoft owned) is also one as well and both of the somehow managed to beat Firefox in usage.
Well that's just false.
Firefox has 7.7% marketshare.
Brave comes in at less than 1 tenth of a percent.
Edge, does better after all it is the _default_ browser on the most popular desktop OS by a massive margin. It gets So Firefox has greater market share than both of those combined.
> Chrome and its derivatives is the reason why browsers like Firefox is failing to keep up and continues to lose users.
You mean Chrome. None of the "derivatives" other than Edge (due to default browser syndrome) and Opera (which gets 2%) have any marketshare, and neither does anything to prevent Google from doing whatever it wants.
> Using anything other than Chrome for a modern web browser is a losing battle.
The reason is very very simple: Chrome is the modern IE, and making content that only works in Chrome (or wrappers) is considered acceptable by the same mediocre developers that made IE only sites a decade ago.
On the other hand, I get where you are coming from: people also said the same thing about using anything other than IE.
Earlier quoted context omitted.
> upgrade to OO programming with use of protocols How exactly are protocols a Swift "upgrade" to OO programming? They were in Objective-C since the mid 90s, adopted by Java as interfaces, copied by C# etc. Also, protocols in Swift have a huge performance downside, because they decided to have them work across structs and classes: if you use a protocol in a function argument, the compiler doesn't even know the size of…
Strange comment. I never said that Swift invented these language features; not sure what the relevance is that many of its features have existed for a long time and some other languages also offer them. Swift ties together a lot of features that in combination make it quite enjoyable to use. It's fine if you prefer other languages, there is certainly plenty of choice. Speaking of protocols, they offer some significan…
Hmm...not sure how else to interpret "upgrade to OO programming with use of protocols" other than that there was an upgrade to OO, and that upgrade was with the use of protocols. Now it looks like you meant an upgrade of the way protocols are used in OO, but you won't say how they Swift's protocols actually constitute an upgrade.
OK. ¯\_(ツ)_/¯
Earlier quoted context omitted.
Swift's refcounting is atomic (as is objc's). As long as you're not under contention most benchmarks I've seen show negligible overhead (from the addition of atomicity, the refcount overhead is still there) for uncontended access. But IME if you do have many threads walking the same data structure you end up spending stupid amounts of time fighting the refcounting. This applies even if the data structure is immutable…
> Swift's refcounting is atomic (as is objc's) Most of the time it’s possible to avoid atomic instructions and still be thread-safe. https://dl.acm.org/doi/10.1145/3243176.3243195 : “BRC is based on the observation that most objects are only accessed by a single thread, which allows most RC operations to be performed non-atomically. BRC leverages this by biasing each object towards a specific thread, and keeping two…
I might be in the minority here (though, reading the comments, it seems others have the same opinion), but I find Swift to be a step back compared to Objective-C. I really like the verbosity of Objective-C - this makes the code more readable and easier to understand, even (or especially) when reading a program the first time. Being a superset of C (and C++ with Objective-C++) means that, when necessary, one can easil…
I think you are in the minority there, even among Objective-C programmers.
In any case, Objective-C ARC is there for those who want it.
Earlier quoted context omitted.
IBM briefly did a "swift on the server" though at the beginning of 2020 IBM was no longer interested, but the page is still up. https://developer.ibm.com/languages/swift/ 2016: https://9to5mac.com/2016/02/22/ibm-swift-cloud-kitura/ 2016: https://www.infoq.com/presentations/swift-server/ 2020: https://www.infoq.com/news/2020/01/ibm-stop-work-swift-serve... You can run it in docker: https://hub.docker.com/_/swift
> but the page is still up. for now just saw an article about IBM deleting most of their website because its a mess. It was some linkedin developer's post.
Earlier quoted context omitted.
> without a big performance hit. You might be surprised (I was). Most of the benchmarks I’ve seen place it more in the neighborhood of golang and v8, rather than the C, C++, rust neighborhood you might expect. Another commenter in this thread highlighted that the ref-counting GC is what keeps it out of the C / Rust performance neighborhood.
Swift doesn't have a GC. The automatic reference counting is a feature that just inserts retain/release statements at compile time, so there is no additional process that handles that. I would suspect that the performance hits originate from other things.
Earlier quoted context omitted.
> The standard library is becoming cross-platform as we discuss it here. I'd argue that it's too late already, the ship has sailed, Swift is heading the same way as C#.
Is there an alternative with similar features and ergonomics? I am def. not aware of one.
I might be in the minority here (though, reading the comments, it seems others have the same opinion), but I find Swift to be a step back compared to Objective-C. I really like the verbosity of Objective-C - this makes the code more readable and easier to understand, even (or especially) when reading a program the first time. Being a superset of C (and C++ with Objective-C++) means that, when necessary, one can easil…
I think for sure you're in the minority here. Swift was really a breath of fresh air for my iOS dev work -- it's just so modern and easy to read. That said -- I'm still reluctant on SwiftUI though. Seems like one of those technologies that works great for small apps and tutorials but falls apart at scale but admittedly have little experience with it so perhaps I'd be wise to reserve judgement.