jakey_bakey
3 days ago
Swift would be perfect if it wasn't dying a death by 1000 cuts thanks to the inherent conflict in its governance.
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.
paperplatter
3 days ago
If I were new to Swift and saw how complicated and version-specific the Stackoverflow answers* are for things that are super simple in other languages, I wouldn't expect things to get much easier from there. And that instinct would be right.
* 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...
interpol_p
3 days ago
Three of those really are very specific to string manipulation, and doing it "right" (with all the possible representations of what a string can be) is inherently complex. I think Swift landed on the wrong side of defaults for this API, opting for "completely safe and correct" over "defaults to doing what I expect 99% of the time"
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
paperplatter
3 days ago
Swift was designed around emojis it seems. First page in the manual shows how you can use emojis as variable names. I get why Apple wants to be clear how there are different ways to index into strings (even if this is motivated 99% by emojis like "family: man woman boy boy skintone B"), but still, the API didn't have to be this confusing or have so many breaking changes after GA.
About structs and pointers, I'm familiar with them in C/C++ where the syntax is clear and consistent. It's not consistent in Swift. And arrays don't even act like regular structs, I forgot: https://stackoverflow.com/questions/24450284/conflicting-def...
kaba0
2 days ago
Or you know, the couple of languages people speak that are not using ASCII…
paperplatter
2 days ago
The issue here isn't ASCII vs unicode, it's specifically symbols that are composed of multiple unicode codepoints.
paperplatter
2 days ago
(Which btw isn't exclusive to emojis, there's also Hangul Jamo that the Unicode standard says is used for "archaic" Korean characters, but emojis are probably the main use case.)
stephencanon
3 days ago
FWIW, that answer (to the second link, after edit) is really old, and you can do string.firstRange(of: substring) since Swift 5.7.
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).
paperplatter
3 days ago
The thing is, each string-related answer ended up extending it with some methods that everyone wanted it to have in the first place, and the top-voted comments are like "why do we have to do this." It also shouldn't have required multiple updates to each answer.
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)
}
stephencanon
3 days ago
> It's confusing that arrays and dicts are structs, which have different rules from regular objects
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!
paperplatter
3 days ago
I'm fine with either approach as long as it's consistent. Practical Swift code will have a few "inout"s sprinkled around, wherever someone happened to pass in a struct (like array) instead of an object (like NSArray). And that's without bridging and stuff like UnsafePointer involved.
Edit: Just remembered that arrays still don't act like regular structs either! https://stackoverflow.com/questions/24450284/conflicting-def...
stephencanon
2 days ago
The answer you link to there is from the Swift 1 days in 2014. It was absolutely true then, but array has had true value semantics since shortly after that answer was written.
paperplatter
2 days ago
Ah, it's coming back to me now. I remember when they fixed that and I was relieved.
fauigerzigerk
2 days ago
I'm fine with either approach if it's easy to know which one I'm using at a any particular call site. C# started the tradition of moving this information to the type level, far away from the call site. Swift has adopted this terrible idea.
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.
paperplatter
2 days ago
Computed properties are annoying too. More importantly, they're one more inconsequential thing for SWEs to argue over in code review.
neonsunset
2 days ago
What do you mean by moving information to the type level?
fauigerzigerk
2 days ago
In C and C++ (and many other languages) the distinction between value and reference/pointer is part of the variable declaration. In C# and Swift that information belongs to type definitions (except for inout parameters). Structs are value types and classes are reference types.
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.
kaba0
2 days ago
If there are identity having classes (reference/pointer) that may be mutable, and value types that are always immutable, then I think it can be an “implementation detail”, part of the type, not changing semantics.
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?
fauigerzigerk
2 days ago
In a language without mutability (or perhaps with something like borrow checking?), it would not be a problem. But in Swift, the option of introducing mutability always exists.
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.
paperplatter
2 days ago
Refs in C++ go against this, right? At the call site, it's not clear that you're passing in a ref instead of a value. I don't mind it too much cause at least the rules are the same for everything, not different for structs vs classes.
fauigerzigerk
2 days ago
Yes. At least references are still part of the variable type and therefore likely to be closer to the call site.
riscy
3 days ago
Can you explain how result builders are half-baked?
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
cageface
3 days ago
Because they rely on variadic generics they can make type inference very slow or just fail completely, leading to the infamous and singularly unhelpful compiler error, "The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions".
paperplatter
3 days ago
Swift is the only language where I've had to fight the compiler to do its job. In earlier versions like 1.x and 2.x, it would often segfault. By 3.x it was still really slow to build. I regretted moving a project off ObjC back then.
I thought maybe that was all fixed by now, but guess not?
cageface
3 days ago
On paper Swift has a lot going for it. In practice it's easily the worst devx out of the modern languages. And SwiftUI is still so full of bugs and performance pitfalls I'm actually quite pessimistic about the future of native apps on Apple platforms.
seec
2 days ago
To be honest, the way they are damaging their brand/products/OS just to make a bit more money is enough to be pessimistic about Apple.
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.
paperplatter
3 days ago
Yeah there's a reason people go to all that effort with React Native to avoid writing Swift code or dealing with Apple's UI frameworks, and it's actually a reasonable approach for the majority of apps.
pjmlp
2 days ago
People go to React Native to stay on their cozy Web skills, it is exactly the same if we would be talking about Microsoft and Google platforms.
paperplatter
2 days ago
I started using RN when I had 0 web skills and didn't know JS. Everything from making a simple button to hooking up the model was easier to me in RN from day 1 than the native iOS way that I'd been using for years.
pjmlp
2 days ago
As someone that unfortunately has to deal with React ecosystem, and knows reasonably well native programming across Apple, Google and Microsoft ecosystems, I have some hard time believing that, but might be a knowledge issue.
riesinger
a day ago
The Google ecosystem? Isn’t that also just Web-based?
paperplatter
a day ago
Not Android
cageface
3 days ago
My main app is a cross platform Flutter app. I've considered rewriting it in Swift because most of my users are on macOS or iOS but all the prototypes I've written are actually slower even after extensive performance work and the development experience makes me want to tear my hair out.
felideon
3 days ago
Ironic, given Flutter's infamy regarding performance (jank).
paperplatter
3 days ago
I'm actually surprised at this because while UIKit is hard to use, at least it's fast. Though I remember the concurrency model being confusing, so you could accidentally block your UI thread.
cageface
3 days ago
UIKit is pretty fast although a major step down in dev velocity.
AppKit on the other hand seems to be pretty intrinsically slow and the controls are looking increasingly dated.
fingerlocks
2 days ago
Odd criticism.
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.
cageface
2 days ago
It’s a criticism from recent experience trying to build AppKit based UI. The examples you list barely use the stock widgets.
There’s decades of accumulated cruft in Cocoa that Apple discarded when implementing iOS.
cageface
3 days ago
Yeah I worried about that going in too but in fact I've found it much easier to get good performance with Flutter than SwiftUI, especially for large collection views and especially on the mac.
The work the Flutter team did on Impeller seems to have paid off.
fingerlocks
2 days ago
You should try to implement the iOS photos.app in flutter and see how that goes. This requires scrolling through gigabytes of photos as fast as your finger can swipe without a single hint of slowdown or a loading spinner. And it’s been that fast since.. iOS 7?
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.
cageface
2 days ago
I’ve been building iOS apps since before Swift existed. Sure like I said if you code directly to UIKit and take a little care performance is good. It’s also very fast in Flutter with even less care. Rendering images in a grid isn’t hard unless your core abstractions are all wrong.
Now try that in SwiftUI. You’ll be forced back to UICollectionView.
fingerlocks
2 days ago
That’s cool. I’ve been developing on Mac before Objective-C 2.0 and iOS since the AppStore was released. Millions of downloads, featured in the store, worked on dozens of projects from video games to MFi firmware, and have been invited to Cupertino to meet with teams.
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.
kaba0
2 days ago
I don’t think it’s impossible with proper caches to smaller dimension versions (that supposedly Apple already generates/has access to - like they are doing a bunch of processing, like object recognition, etc).
seec
a day ago
It's only that fast is the thumbnails are not too slow, the data is all there on device, the phone isn't RAM starved, and you largely have the latest iteration of iPhone for the current software, with the most powerful chip available.
In this way, yeah, it's pretty fast. Any other way it's blank square galore.
ameliaquining
3 days ago
I mean, I figure the more compelling reason to do that is so you can also ship an Android app without writing everything twice.
paperplatter
3 days ago
Sorta, but it's not as easy as they make it sound. And people will use RN even for iPhone-first stuff.
evilfred
3 days ago
except for the thousand times you end up having to dip down into native components
nwienert
3 days ago
I'd say most of the time it's a handful of times or less. Uniswap is a good example of a large OSS three-platform app that shares almost all the code, uses very few native dependencies, and has great UX. I maybe biased since I worked there and made the UI framework they use, though.
fingerlocks
2 days ago
I have made a lucrative career by porting fragile, slow, bug-ridden react-naive disasters to native code bases. There is a lot of demand for this from startups that took the cross-platform shortcut and the MVP became the product.
nwienert
2 days ago
You can make a disaster in any framework. SwiftUI is a mess, for example, and slow.
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.
paperplatter
2 days ago
It can get tough with the native dependencies involved.
fingerlocks
2 days ago
I have made a countless PRs to many of the most popular react-native dependencies because they were a buggy mess.
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
nwienert
2 days ago
I have plenty of nightmare stories to tell you about native deps.
paperplatter
2 days ago
For some apps, I can see this. Question is, did the startups regret taking the shortcut upfront, or were they fine paying later for the improved version?
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.
cageface
2 days ago
When I was still doing contract work I rescued a bunch of native code iOS app disasters. For most apps cross platform solutions are fine.
nsonha
3 days ago
Like you dont have to know native components anyway?
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!
astrange
3 days ago
I can think of a few others where you have to do that; most of them are the kind of languages whose fans say they're impossible to write bugs in.
cageface
3 days ago
Rust is hard but I've never had the compiler just throw up its hands and tell me it's up to me to figure out what's wrong.
astrange
3 days ago
That's not the one I was thinking of.
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.
cageface
3 days ago
Ok but these are mainly academic research languages. Swift has the backing of the most valuable company in the world and is what they're pushing as the right way to develop for their platform.
astrange
3 days ago
Haskell is definitely a real industrial language!
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.
paperplatter
3 days ago
I've seriously used Erlang for a while, and Haskell looks kinda similar. Ingenious ideas there, cool features, but in the end it's cumbersome to use. So I can see why these are niche and wouldn't consider them next to big ones like Swift or C++.
paperplatter
3 days ago
If Rust is one, yeah I have to fight that compiler but it's because it's doing its job and not letting me do invalid things. Not because the compiler has some feature "not yet implemented" or has bugs.
paperplatter
3 days ago
Also, is anyone familiar with the weirdness with tuples in Swift? All I remember is they never worked the way I expected, and for some reason something in our code specifically worked for tuples up to size 5.
plorkyeran
2 days ago
Swift only got variadic generics fairly recently, and before that you couldn’t write code which was generic over tuple size. Instead you had to codegen versions for each size of tuple you needed to support.
paperplatter
2 days ago
I think that was it. There was also something about tuples inside of dictionaries that Swift 1 or 2's compiler segfaulted on.
Vegenoid
3 days ago
> Ridiculous, permanent, tech debt such as hardcoded compiler exceptions are permanently living in the compiler codebase.
A little search-engining didn’t surface info about this, could you point me in the right direction?
jakey_bakey
2 days ago
Vegenoid
2 days ago
Thank you - yeah, that smells pretty bad. But, although it says "can't be changed", could it not be changed if SwiftUI were changed? An up-to-date compiler would no longer be able to compile projects using older versions of SwiftUI, but is there not a path to get there by updating SwiftUI to not require this exception, then some time later, deprecating the older versions of SwiftUI, either throwing a warning on compilation or putting it behind a compiler flag, and then finally removing it altogether?
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?
jordanmorgan10
3 days ago
I get what you’re saying and largely agree, but without result builders SwiftUI wouldn’t exist, let alone “look pretty”. You seem to be devaluing the syntactic sugar it brings, which in this case makes a massive difference.
monkmartinez
3 days ago
That is a fascinating take and approach to contemplating a language.
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.
troad
3 days ago
> I am looking to branch out and really learn a compiled language
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.
Dylan16807
3 days ago
C++ has a lot of things I would call new-fangled, in addition to many old ways of doing things, with no good ways to settle on which iteration to use so devs can avoid learning all of them. And some things simply require templating nightmares to work at all.
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.
troad
3 days ago
C++ gives you a garage full of tools and lets you decide what to do with them. Ultimately, it does this because the years have shown that different people need different tools for different use cases. Few people need or use them all at once. But when you do need a specific tool, C++ has it ready for you. Some consider that a con, I consider that a pro.
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'?
Dylan16807
3 days ago
There's a lot of redundancy and things you probably should never use in C++, though. It's not complexity that needs to exist other than for backwards compatibility.
> 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.
lenkite
21 hours ago
You don't have any template nightmares after C++ 20 concepts. The error messages improved so much that I thought I was using a different programming language.
consteval
2 days ago
> There's a lot of redundancy and things you probably should never use in C++, though
This is just a symptom of its age. C# has this same problem, too, and it's only getting worse.
neonsunset
2 days ago
C# does have C++-esque issues but the scale at which they affect the language is not comparable. There are really no popular patterns that have become "no, never do that", poorly written code is sort of version agnostic, and even old code, particularly one like in Mono applications from back in the day, plays really nicely with modern runtimes. And the difference in ways to achieve something is almost always of type "remember this required to take 4 steps? now it's one shorthand thing that makes sense in retrospect".
rand_r
3 days ago
Something I’ve been curious about recently, is how did Linux get away with straight C for so long, considering how complex of a project it is. Did they end up reimplementing a bunch of C++ features?
Actually, regarding sophisticated projects, there’s quite some complicated projects that succeed without C++ power, like Postgres and Python.
troad
3 days ago
I didn't mean to imply, if I have, that C++ is always and in all circumstances the best choice for any given software project.
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!)
6gvONxR4sf7o
3 days ago
I’ve been meaning to do this for years, and just played around with rust a bit (liked it, but the wrappers around some c++ stuff i wanted to use were half baked). Learning rust, there was this “rustlings” thing [0] that was a set of guided exercises to go alongside the rust book. Fastest I’ve ever picked up a language, thanks to that. Do you or anyone know anything similar for c++?
gtirloni
3 days ago
paperplatter
3 days ago
I use C++ at work but am glad I didn't learn it before. Yes it's a good language for what it's made for, but there are so many features that anywhere you work, you will use it differently from how you used it before. Better to learn it on the job imo.
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.
cheema33
3 days ago
> Tip from a friend - just learn C++.
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.
troad
3 days ago
Definitely. Use the right tool for the job.
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.
dagmx
3 days ago
C# for Microsoft and for a long time people were afraid of Amazons influence on Rust
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.
benoau
3 days ago
I can certainly think of a web browser that has that same conflict of interest... in fact we are actually right in the midst of a "leopards ate our face" moment with ad blocking becomes undesirable to Google in Chrome.
evilfred
3 days ago
Java has problems now that Oracle is in charge. upgrading Spring/Hibernate versions is really painful when you have to switch to Jakarta imports all over
pjmlp
2 days ago
Without Oracle in charge Java would have died in version 6.
pjmlp
2 days ago
You can apply the same complaint to Java and .NET ecosystems, both doing quite well, despite not everything being open source, or being managed by entities that FOSS folks rather not deal with.
"Oracle, IBM, Azul, AWS, Google..... this and that."
"Microsoft this and that."
msk-lywenn
2 days ago
I was always puzzled by the swiftUI syntax. Thanks for pointer me to result builders, I understand better now. I can't help but thinking the whole thing could be re-implemented with macros now? (result builders appeared in 5.4, macros in 5.7)
pbreit
3 days ago
Was Swift really necessary? Would it really not have been possible to build iOS apps on something like JavaScript?
Decabytes
3 days ago
Apple never set out to create Swift. Chris partner worked on it for fun in his spare time, and when he realized it could go somewhere he went through the channels to get it turned into an official project. With that being said it was tailor made to address important issues for Apple developed. For example, it has great interop with Objective-C which was a requirement to get it adopted, first at Apple, and then with the wider community. It is also built with safety and security in mind removing lots of undefined behavior and adding null safety. It is also statically typed while JavaScript isn’t. There are a whole host of other goodies that it has that make it better for Apple developers than just adopting JavaScript. Chris partner has lots of talks where he goes over the reasonings
tonyedgecombe
2 days ago
>Chris partner
Chris Lattner
astrange
3 days ago
It wouldn't be performant enough. Resist the urge to go as abstract as possible on a battery-powered device someone else is paying for.
xanth
3 days ago
A low level language that's ergonomically interoperable with objective-c was probably the best choice.