They’ve been used for more than SwiftUI by now. The Regex support since 5.7 uses them: https://www.hackingwithswift.com/swift/5.7/regexes
I thought maybe that was all fixed by now, but guess not?
AppKit on the other hand seems to be pretty intrinsically slow and the controls are looking increasingly dated.
UIKit is the iOS counterpart to MacOS’s AppKit and both are implemented as convenience wrappers around CALayers. They are also infinitely customizable. You can overload UI/NSView and draw vector-pen style on a blank canvas or render whatever you want on a GPU frame buffer. This is how MapKit, Safari, and the Camera view is implemented.
There’s decades of accumulated cruft in Cocoa that Apple discarded when implementing iOS.
The work the Flutter team did on Impeller seems to have paid off.
Yeah it’s not the language or the SDK that’s slow. Rather it’s inexperienced, lazy, or overworked developers that can’t/won’t write performant software.
Now try that in SwiftUI. You’ll be forced back to UICollectionView.
I’m not defending SwiftUI. I mostly use it as a wrapper around NS/UIKit because it’s still buggy and not as flexible.
By the way, SwiftUI is also implemented on top of CALayers just like NS/UIKit. It can be fast in theory, but you have to know exactly where the pain points are and most developers don’t know how to do that.
In this way, yeah, it's pretty fast. Any other way it's blank square galore.
React Native took a while to mature, but with the right tooling you can ship amazing UX now.
I don’t doubt there’s a ton of crap out there.
But you’re wrong if you think you can’t make seriously great stuff with it. It’s matured quite a lot.
And the React programming model is untouched, hot reloading and dev tools far ahead, and code share is worth it with something like Tamagui that actually optimizes to each platform. If I never had to touch an ObservableObject again that would be great.
In fact at this very moment I’m helping a team fix a memory leak/crash in the “react-native-permissions” dependency. It’s obvious this package was not written by someone with experience. All it does is request permissions in a paragraph of code and it’s totally broken! Give me a break
Btw, sometimes I think about how much I've been paid by various people to move a backend from SQL to NoSQL then from NoSQL to SQL, despite me telling them not to.
In one way you centralise as much logic as you can and are encouraged to write clean code that doen't depend on platfrom quirks. In the other way you... give up and just do whatever.
I can see how some devs find it hard to not give up and just write the same logic in multiple languages, great job security!
But it's very true that the state of the language can be felt in their native apps, that tend to suck pretty bad recently. I still can't get over the nightmare that is the split up of iTunes; at least we knew that it was clunky because of old age, the new stuff is just bad.
https://anthony.noided.media/blog/haskell/programming/2020/0...
Something like Idris or Coq would have even more complex messages, though I don't have an example on hand.
Many of the other languages in the formally verified/dependent type space are academic, but there's government interest in things like Ada too because they don't want their planes to crash. Couldn't say how good its error messages are though.
A little search-engining didn’t surface info about this, could you point me in the right direction?
It would certainly take a while, but could be done if Swift is aiming to be a mainstream, long-term, cross-platform language - unless this kind of thing is just not done, or there is some technical aspect I am missing?
Can you think of any other languages that share a duality like Swift? I mainly play in the python ecosystem, but I am looking to branch out and really learn a compiled language. What you wrote about Swift makes sense and would be concerning if I had recently picked it up.
"Yadda, yadda..." regarding picking the right tool for the job aside, I don't want to waste time on a language that can be usurped by a giant corporate borg anytime they see fit.
But the reality is that many major languages already have very outsized corporate influence. Either at the language level or the compiler level.
Swift is open source and has been separating from Apple ownership as of this year.
Tip from a friend - just learn C++. It's not sexy, it's not new-fangled, but it's rock solid, runs half the world, and you will never struggle to find a job.
You'll also understand what it is that all of the new-langs are trying to improve upon, and will be able to made an educated judgment about whether they succeed or not.
A good resource for modern C++ (albeit it seems to be down rn?) is https://www.learncpp.com/. I'm not affiliated, it's just good.
I would also not use "rock solid" in comparison to how easy it is to hit undefined behavior.
Used all over and easy to find jobs, yes.
I find that a lot of the newlangs take the view that since most programming only uses 20% of the toolkit, they can just dispense with the remaining 80%. Which is great, until you discover that virtually every sophisticated project needed one of those things from that remaining 80%, and they all needed a different one. A nice language for writing 'Hello world's isn't going to cut it. And so either the language insists on its simplicity and stagnates, or it just reinvents all the complexity of C++.
At which point, you were better off just taking the garage full of tools that you already had, rather than going all in on some newlang, getting blocked, and stalking a github ticket for years waiting for the lang to get that feature you need. (If you spent the time in C++ instead, its full garage wouldn't look so imposing over time!)
What's the famous quote? 'There are only two kinds of languages: the ones people complain about and the ones nobody uses.' :P
Re generics, aren't C++'s virtually the same as Rust's? Especially now that C++ has 'concepts'?
> Re generics, aren't C++'s virtually the same as Rust's? Especially now that C++ has 'concepts'?
I'm not worried about generics when I talk about template nightmares, that's more about rvalue and const overloads and vararg templates and careful manipulation of SFINAE, all coming together.
This is just a symptom of its age. C# has this same problem, too, and it's only getting worse.
Actually, regarding sophisticated projects, there’s quite some complicated projects that succeed without C++ power, like Postgres and Python.
The question was about the first compiled language someone should learn, and for that, C++ is great. It's going to cover most of the use cases for compiled languages, while providing relatively familiar abstractions and semantics.
C is fantastic when you need to eke out every single cycle of performance, which is why it's a great choice for Python and Postgres. But you do this by effectively writing assembly instructions, which is why it's a terrible choice for someone coming to compiled languages for the first time.
C++ gives you equivalent performance to C, for a fraction of the effort, in about 90% of the use cases. For the remaining use cases, C is a better (and often only) choice, but no one who is only learning compiled languages for the first time is anywhere near being able to write that kind of C code. (After a few years of C++ they'll be in a much better place to do so!)
Just getting good and greasy with Python and JS with all the typical libs has been more rewarding for me. Nobody taught me, but it was useful.
Is that good advice for certain domains only? For example, you likely wouldn't want to use C++ for web server backend? You could, but may not want to.
But if you're looking to learn a compiled language - presumably because you want to write applications, games, or systems - then C++ is a great one to learn.
* https://stackoverflow.com/questions/34540185/how-to-convert-... https://stackoverflow.com/questions/32305891/index-of-a-subs... https://stackoverflow.com/questions/39677330/how-does-string... https://stackoverflow.com/questions/24250938/swift-pass-arra...
The top answer to your third question gives a pretty good explanation of why Swift string indices work the way they do (as well as showing nicer ways to spell a lot of the operations on them), which mostly addresses the first and third questions. It really seems that your last link is just asking for the `inout` modifier; I'm not sure why that one is especially confusing.
Obviously, there's always stuff that can be further improved, but none of these are especially onerous (once you get past the "string indices are not just integers" step, at least--for people who really just want to pretend the world uses ASCII or work with UTF8 bytes directly, string.utf8 may be an nicer interface to use).
The time I was doing a lot of string manipulation in a team Swift project, we had to write our own wrapper that basically stored strings as arrays of printable characters because the native one was too annoying. This also protected us from all the breaking changes Apple made to strings across Swift versions.
The inout one is different. It's confusing that arrays and dicts are structs, which have different rules from regular objects, and the syntax takes some getting used to:
func addItem(_ localArr: inout [Int]) {
localArr.append(4)
}As a long-time assembly and C programmer and now Swift programmer, I would say that structs _are_ regular objects, and things with reference semantics are weird. It all depends on your point of view!
The philosophy of making code look "clean" at the cost of hiding critical information in some far away place is the biggest mistake in programming language design. If code happens to look clean it should be the result of being simple rather than being cleansed for effect.
Other bad ideas in the same vein are computed properties and function builders.
Type definitions are usually further away from the call site than variable declarations. Also, in C, accessing a member of a struct through a pointer requires the -> operator providing yet another clue as to whether you're using a pointer or a value.
In my opinion, this distinction is absolutely key. It should always be obvious at the call site. I don't think there is anything that has caused more bugs in my Swift code than getting this wrong.
Change a type from class to struct or vice versa and chances are your code still compiles when it really shouldn't because it's now completely broken.
If you can’t change a struct’s field, only the whole struct, then I believe it’s fine - and the compiler may decide to copy it or change in-place depending on its available context, is it not the case?
It's not impossible to impose some sort of discipline to mitigate these issues, but why is it a good idea to make values and references indistinguishable at the call site? I don't get it.
But it's not surprising. I don't get a lot of decisions that language designers have been making. The entire drive towards more and more syntactical abstraction in order to make everything look like a DSL is a mistake in my opinion.
You can get a `utf8` or `utf16` "view" of a string, and index it like normal array (`myString.utf8[0]` gets the first utf8 character). But it's not going to work with complicated emoji, or different languages that may have representations into utf16, etc. Again, I think the vast majority of people don't care for complete correctness across all possible string representations, and possibly Swift has gone too far here — as noted by all the Stack Overflow posts and clunky API
On the array-pass-by-reference, I'd argue that it's valuable to learn those semantics and they aren't particularly complicated. They offer huge benefits relating to bugs caused by unintentionally shared state. Marking the parameter `inout` is a small price to pay, and really forces you to be explicit about your intentions
The weird thing about arrays is they're different from all other objects, including NSArray which is by reference. No other language does it this way. C++ has pass-by-value vectors, but that's because everything else is too.
Chris Lattner
"Oracle, IBM, Azul, AWS, Google..... this and that."
"Microsoft this and that."
Swift is caught between two clans: the Swift Working Group™ open-source community, and the Apple corporate entity who pays most of their salaries. Both have their own incentives and their own imperfections, but you guess who has the majority influence.
Ridiculous, permanent, tech debt such as hardcoded compiler exceptions are permanently living in the compiler codebase. Even worse, half-baked concepts such as result builders are pushed through without any real discussion because Apple wants the SwiftUI syntax to look pretty.
It's an amazing language still, but I can't see it surviving as nicely in the next 10 years if Apple doesn't learn to let go.