tolmasky

There's good reasons for all of this of course, but from an end user perspective, it's pretty confusing that URL is not part of JS but encodeURIComponent is. And Uint8Array is part of JS but TextEncoder isn't. But the cool thing is that increasingly no one needs to worry about that because the non-browser JS runtimes have settled on the idea that they should implement the Web Platform APIs. So as a developer, you can just act as if WebSockets is part of JavaScript.

But there's no good name for this “collection" of standards that are together commonly accepted to be "JavaScript". No one says "JavaScript with browser-compliant modules and WebWorker additions…”, and even saying “ECMAScript with the Web Platform Additions” is a mouthful. But you know what does convey “ECMAScript, the way you're used to it in browsers”? WebScript.

This very much makes the case for not using ECMAScript, since ECMAScript still has a separate meaning. It is the pure language spec. Useful as a term for spec writers, pedantic everywhere else. Meanwhile, "WebScript" formalizes what people were sometimes (but not always) bending "JavaScript" to do before, and thus actually does add "new utility" to the terminology, vs. just being a replacement synonym that avoid legal issues.

This is of course speculation, but I think people would interpret us trying to switch to "ECMAScript" as a sort of sulky defeat "wait so we're just going to let Oracle have JavaScript and just use the soulless spec name? No way, we should fight for JavaScript!" It feels like we're "settling" for the SKU number since we lost the name (again, due to the uniquely bizarre, but understandable in context, spec name).

In other words, besides the "consistency" that WebScript offers (WebWorkers, WebGPU, etc.), the other thing it brings to the table is just being something new and different. "Hey! Let's move on from this whole debacle, here is a symbolic thing that represents a new chapter, with zero associated baggage." I am largely basing this off of the experience of "html5," which arguably addressed a similar non-technical debacle in the form of the W3C/WHATWG drama. It is surprising how effective a new name can be at putting a positive spin on things.

Again, I personally have no issue with ECMAScript, I just think the boat has sailed on getting people to switch to that, and if we switch to anything, the goal should be to make sure to get everyone onboard.

But this is especially so given that JavaScript isn't even a good name. It would be one thing to fight this on principle if the name was great, but it isn't. In fact, the name was specifically originally chosen due to its confusion-causing powers -- the unfortunate reality is that JavaScript was chosen precisely to ride the coattails of the then hot new technology Java. This was a horrible idea from day one. No one would suggest I name a new unrelated programming language "SwiftScript" or "RustScript" today to benefit from the popularity of those languages. It would be both tacky and shortsighted. Is it tacky enough to change in isolation? No, it would just be yet another unfortunate part of tech culture, like "referer" only having 3 r's instead of 4. But it absolutely is tacky enough to give up if we are facing some huge case against an actor that is quite literally infamous for their stubbornness in court. No one at Oracle is thinking about this for longer than 5 minutes, while it is causing tremendous grief to Ryan and half the JavaScript community. Why give them that? Let Oracle own all the shitty Java-related trademarks. We're not even handing them a win. The JS trademark will become worthless once we all switch to WebScript, and as an added bonus it won't even accidentally provide even a tiny bit of free marketing for any other their technologies like JavaScript maybe does today. Their reward can be a step further toward of obscurity, self-excising themselves from their current unearned appearance in the history of the web whenever JavaScript is mentioned.

The “Java” prefix still confuses new users, not to mention "bizdev" people, and probably leads to legal issues beyond just the trademark. "JavaScript" has always sucked as a name, we're just used to it now. Why are we fighting so hard for it? Let's just take this as an opportunity to name it something that actually makes sense. It will maybe be sort of annoying for a few years, but I'm certain one day we'll look back and not believe we used to call it "JAVA Script".

I will however say that I think my comment was not just an appeal to authority. Again, I think the fact that using public domain works was critical to Disney's early success is a fairly important data point, especially considering some of those works would not have allowed to be used with the current lifespans (e.g. Pinocchio's copyright would have lasted until 1960, 20 years after the film premiered).

But again, the most important thing I want taken away from this is that we the "consumers" of the content should not consider ourselves bystanders, but understand that we do have an active stake here as well. You're first sentence is perhaps more important than you realize, making up the rules wasn't something one-off incidental property of being first to the table, we could choose to make up the rules too, so we should act like it, as opposed to trying to "deduce" the ownership of a sentence. This is unique, we don't have that ability with physical property. We can't simply declare that everyone gets Ferrari tomorrow and then have them magically appear in everyone's garage. But we could declare that everyone can have the rights to Superman tomorrow, and they would "magically just have them".

There's no real baseline here. We should just weigh the pros and cons. The fashion industry operates more or less copyright-free. The infrastructure to enforce copyright has real costs. Not to mention there is all the collateral damage from the abuse of copyright takedowns this system brings along with it. And any sort of appeal to authorship is also highly suspicious given that authors rarely end up owning these rights. Every time one of these Marvel movies comes out there's a mini outcry when people see the guy whose comic the movie is based on is just some dude who gets nothing from the making of the movie. On the flip side we take for granted that every public domain character was of course at one point created. Robin Hood, Zorro, Dracula, Sherlock Holmes. Are we unhappy with the diversity of adaptations we've gotten from these? Would it be that Earth shattering if Harry Potter joined that list? As things stand right now no one on this website will likely ever get to legally publish "their take Harry Potter". The clock doesn't start ticking until after JK Rowling dies. It would have entered the public domain 2011 under the original rules. In case you're curious, her net worth in 2011 was $500M, if you want to factor that into whether you think that would have been "fair" (and its not like she stops making money at that point, its just other people start to be able to do stuff with the first book). I think it is worthwhile to imagine a different approach to this.

But either way, I think the point that immediately follows that is even more important, right? The fact that the nature of the ownership, even in a "successful" transaction, is incredibly more complicated with the drawing. How the we don't even properly understand how much "ownership" you have of the drawing without a contract. How that transaction potentially puts you in direct competition with Alice in the future. Etc. etc. Again, the entirety of my position is the fairly narrow statements that: 1) intellectual property is fundamentally different from physical property, 2) you thus cannot simply model intellectual property transactions by merely pretending you're dealing with physical objects (since there's fundamentally more dimensionality and ambiguity without explicitly outlining and agreeing to way more terms and details), and 3) intellectual property thus naturally requires significant infrastructure in order to create an environment that gets anywhere close to simulating the same "physical-like" properties for intellectual property. I don't think that's controversial.

> Copyright duration is too long. But the fundamental difference between rivalrous possession of physical artifacts and infinitely reproducible ideas really needs to stay the hell out of these debates. It's a tired, empty talking point that doesn't actually address the substance of what IP laws are really about.

I would argue that it is perhaps the opposite of tired: ironically less relevant in the past and more relevant as technology advances and mere thought experiments become practical reality. I think many of these issues weren't dealt with in the past because these edge cases existed as mere hypotheticals. Kind of like a mathematician saying that copyright doesn't make any sense because he could write a program that iterates through all books. Lawyers just roll their eyes not because they have a counter-argument, but because they don't think that scenario exists as something they'd ever have to deal with. I think the idea of a computer that reads all the text in the world and learns from it is definitely tied to the questions of unresolved issues with the nature of data, but would have until very recently been considered an annoying hypothetical in a serious discussion about copyright, allowing us to actual dismiss it and continue not addressing it.

We all agree that copyright is too long. And I also think this would just become a non-issue if we had a reasonable duration for copyrights. Even if you philosophically disagreed with it, it wouldn't be worth arguing over vs. just waiting it out.

> This is a stupid argument, no matter how often it comes up.

I knew bringing this up would rekindle these arguments from 20 years ago, but it was necessary for a later point, so I was hoping I was making it value-neutral enough that it wouldn't trigger this, but I guess I was wrong.

To be clear, I am not making the same argument you have seen several times before. I am making a strictly weaker argument. The only goal of this distinction is to demonstrate that these properties are "different", and that the law aims to make "intellectual property" behave like physical property. Notice for example that I didn't then assert that IP thus doesn't exist. I didn't even argue whether this goal of matching the behavior was good or bad. I am simply stating that it doesn't by default behave the way we seem to want it to, and, people don't seem to intuitively ascribe the same morality to it either. My only intention is to make the point that this goal thus requires work, and (as I'll explain in more detail below), more work than in the physical case. So far I don't think there is anything necessarily unreasonable about this as a set of premise conditions for establishing the terms under which the public at large agrees to take on the costs of maintaining said system.

> A bunch of stuff about Alice making sandwiches and drawing pictures

Disclaimer: I don't think we're really in disagreement about the important points, and I don't think this section is relevant to the important points which I return to below, however I find it intellectually interesting to talk about, so I have a retort here, which I believe is just an unrelated digression

These analysis of Alice making sandwiches and drawings (IMO) misses the actual meaningful differences in these scenarios since it (IMO) focuses on the uncontroversial, but also irrelevant, breach-of-contract issues. In both these scenarios, the issue is not really the "property," it is the refusal to comply with a previously agreed arrangement. You can see this if we add a third scenario where I pay Alice to do jumping jacks for a week, she does them, and then I refuse to pay at the end of the week. No need to pay you, you already did the jumping jacks. No one "got" anything here, other than I guess "satisfaction" or "exercise". We can make the example even more abstract by having me pay Alice to do nothing all week, and she once again does a great job by sitting quietly in her room all week, and then I once again don't pay her. The sandwiches and drawings are just props in the original examples -- they're not actually necessary since this is a contract question, not a theft question.

The actual interesting aspects around the sandwiches and drawings are 1) what happens much after this transaction, and 2) what happens with third parties. With the sandwiches, "what happens after" is straight-forward. I either the sandwiches, resell them immediately, or they go bad. There's not much interesting there. No one needs to think hard about the "ramifications" of the sale of the sandwiches. Compare this to the drawing. What if after I have paid you, just like we agreed, I proceed to make my infinite copies. You might think that's not fair, you thought you'd have a repeat customer. I assumed I was free to do as I please with the drawing. In fact, ironically enough, in this instance if I treat the drawing like physical property, where the expectation is I can do as I please with it, it ironically creates this conundrum because "putting the paper in the photocopier" is in the set of "do as I please". But let's go one step further, what if I make all those copies and then sell them.

I'm sure you'll now respond that the royalties or usage rights were all implied in your original story. Great! But that's my point. Those were required. You needed a supremely complex web of laws and binding contracts (and litigation if they aren't followed) as a necessary component of that transaction due to the existence of degrees of freedom that simply don't exist for the sandwiches. You can write up a contract around the resale of a sandwich, but most sandwich shops don't because me eating sandwiches for the rest of my life by copying the original sandwich isn't a realistic scenario (so no need to price that into the original cost of the sandwich), and me out-sandwiching you by carbon-cloning the sandwich isn't feasible, and even if it was it would still have material ingredient costs that would bound its effect on my shop, and even "figuring out the recipe" isn't that much of a worry since you still need to like buy ingredients and make sandwiches as opposed to hitting paste over and over. These scenarios are dramatically different, and that's why sandwich shops usually don't employ lawyers but design shops do. And again, we didn't even go into third parties. What if someone manages to somehow make a copy of your image just as you're handing it to the client. Now both of you are in compliance with your deal, neither of you is angry at each other, but there's this weird situation where you were never expecting to get money from me, but I have a copy of the picture now, and it's really hard to reason about what that means in terms of "gain" and "loss" if I never do anything other than hang it up in my room. This is simply not possible with the sandwich, no one could quickly "copy the sandwich" in transit and potentially introduce an entirely new threat to your business.

Again, my only point here is that it seems very strange to insist that there physical property is identical to intellectual property, and that it isn't fairly complicated to make intellectual property approximate the relationships we have with physical property. And to be clear, nothing even derogatory has been said about this goal yet. You could take everything I've written in this comment so far, and use it as part of argument for copyright. However important is it precisely because of the explosion of complexity in possibilities that simply don't exist for the vast majority of physical items.

None of this was ever the point of copyright. The best part about all this is that Disney initially took off by… making use of public domain works. Copyright used to last 14 years. You’d be able to create derivative works of most the art in your life at some point. Disney is ironically the proof of how constructive a system that regularly turns works over to the public domain can be. But thanks to lobbying by Disney, now you’re never allowed to create a derivative work of the art in your life.

Copyright is only possible because we the public fund the infrastructure necessary to maintain it. “IP” isn’t self manifesting like physical items. Me having a cup necessarily means you don’t have it. That’s not how ideas and pictures work. You can infinitely perfectly duplicate them. Thus we set up laws and courts and police to create a complicated simulation of physical properties for IP. Your tax dollars pay for that. The original deal was that in exchange, those works would enter the public domain to give back to society. We’ve gotten so far from that that people now argue about OpenAI “stealing” from authors, when the authors most of the time don’t even own the works — their employers do! What a sad comedy where we’ve forgotten we have a stake in this too and instead argue over which corporation should “own” the exclusive ability to cheaply and blazingly fast create future works while everyone else has to do it the hard way.

The best party about all this is that Disney initially took off by… making use of public domain works. Copyright used to last 14 years. You’d be able to create derivative works of most the art in your life at some point. Now you’re never allowed to. And more often than not, not to grant a monopoly to the “author”, but to the corporation that hired them. The correct analysis shouldn’t be OpenAI vs. Intercept or Disney of whomever. You’re just choosing kings at that point.

Hopefully that clarifies that I was not necessarily making any statement about whether or not to use Raku regexes, which I don't pretend to know well enough to qualify to give advice around. Just for the sake of interesting discussion however, I do have a few follow up comments to what you wrote:

1. Aside from my original confusing use of the term "regexes" to actually mean "PCRE-style regexes", I recognize I also left a fair amount of ambiguity by referring to "actual parsers". Given that there is no "true" requirement to be a parser, what I was attempting to say is something along the lines of: a tool designed to transform text into some sort of structured data, as opposed to a tool designed to match patterns. Again, from this alone, seems like Raku regexes qualify just fine.

2. That being said, I do have a separate issue with using regexes for anything, which is that I do not think it is trivial to reason about the performance characteristics of regexes. IOW, the syntax "doesn't scale". This has already been discussed plenty of course, but suffice it to say that backtracking has proven undeniably popular, and so it seems an essential part of what most people consider regexes. Unfortunately this can lead to surprises when long strings are passed in later. Relatedly, I think regexes are just difficult to understand in general (for most people). No one seems to actually know them all that well. They venture very close to "write-only languages". Then people are scared to ever make a change in them. All of this arguably is a result of the original point that regexes are optimized for quick and dirty string matching, not to power gcc's C parser. This is all of course exacerbated by the truly terrible ergonomics, including not being able to compose regexes out of the box, etc. Again, I think you make a case here that Raku is attempting to "elevate" the regex to solve some if not all of these problems (clearly not only composable but also "modular", as well as being able to control backtracking, etc.) All great things!

I'd still be apprehensive about the regex "atoms" since I do think that regexes are not super intuitive for most people. But perhaps I've reversed cause and effect and the reason they're not intuitive is because of the state they currently exist in in most languages, and if you could write them with Raku's advanced features, regexes would be no more unintuitive than any other language feature, since you aren't forced to create one long unterminated 500-character regex for anything interesting. In other words, perhaps the "confusing" aspects of regexes are much more incidental to their "API" vs. an essential consequence of the way they describe and match text.

3. I'd like to just separately point out that many aspects of what you mentioned was added to regexes could be added to other kinds of parsers as well. IOW, "actual parsers" could theoretically parse Raku, if said "actual parsers" supported the discussed extensions. For example, there's no reason PEG parsers couldn't allow you to fall into dynamic sub-languages. Perhaps you did not mean to imply that this couldn't be the case, but I just wanted to make sure to point out that these extensions you mention appear to have much more generally applicable than they are perhaps given credit for by being "a part of regexes in Raku" (or maybe that's not the case at all and it was just presented this way in this comment for brevity, totally possible since I don't know Raku).

I'll certainly take a closer look at the full Raku grammar stuff since I've written lots of parser extensions that I'd be curious have analogues in Raku or might make sense to add to it, or alternatively interesting other ideas that can be taken from Raku. I will say that RakuAST is something I've always wanted languages to have, so that alone is very exciting!

"templated-regular-expression" on npm, GitHub: https://github.com/tolmasky/templated-regular-expression

To be clear, programming languages should just have actual parsers and you shouldn't use regular expressions for parsers. But if you ARE going to use a regular expression, man is it nice to break it up into smaller pieces.

Secondly, in a true demonstration of confusion, if you read my posts they demand nothing. They simply state what are likely outcomes of certain choices. I’m not sure how to possibly make the stance of “if you pay smaller bug bounties in a market that has other offerings, you will get less research focused on your product” any simpler. It seems fairly straightforward… and the existence of one bug report does not somehow “disprove” this. Why not make the bug bounty $1 otherwise? Oh, is that a ridiculous suggestion? Because that might not be a worthwhile enough incentive perhaps? But who are you to dictate what is and isn’t a worthwhile incentive. “That’s not how this works. That’s not how any of this works…”

> “either a researcher out there will spend some time on it […] or they won’t.”

Yes, I agree with this truism that they either will spend time on it or they won’t. Interestingly, this is true in all scenarios. My point is how to optimize researchers spending time on your product (which in theory you are inclined to do if your are offering a bounty), and I then separately even make suggestions for how to possibly require less attention by making safer choices and being able to “ride” on another project’s bug bounties.

But again, the simplest point here is that the position of “we offer low bug bounties because that is what we can afford” is fine, it’s just also absolutely defensible to be completely turned off by it as a potential user of that product, for the likely security implications of that position.

Long story short, there are ways to creatively solve this problem, or avoid it, but simply exclaiming “well it would be too hard to do the necessary thing” is probably not a good solution.

If your app is paying out $2K and a competing app pays out $100K, why would anyone bother searching for bugs in your app? Every minute spent researching your app pay 1/50th of what you'd get searching in the competing app (unless your app has 50x more bugs I suppose, but perhaps then you have bigger problems...).

I'm always so confused by the negative responses to people asking for higher bug bounties. It feels like it still comes from this weird entitlement that researchers owe you the bug report. Perhaps they do. But you know what they definitely don't owe you? Looking for new bugs! Ultimately this attitude always leads to the same place: the places that pay more protect their users better. It is thus completely reasonable to decide not to use a product as a user if the company that makes the product isn't paying high bug bounties. It's the same as discovering that a restaurant is cheeping out on health inspections and deciding to no longer eat there.

The simplest comparison point is the calculator app which behaves exactly as you described: if you put your finger down on the number 9, a 9 won’t show up until you lift up your finger. OTOH, if it worked like the Lock Screen, a 9 would show up, but would then be removed if you moved your finger away and lifted up. But again, nowhere else works this way.

If you think this is good interaction design, do you thus think the calculator app has bad interaction design? That it should instead be adding numbers immediately and then retroactively removing them?

All this to say, it is hard to answer this question in one comment, but to try to sum up my position on this, I believe the performance benefits of Swift were and remain overblown. It’s a micro benchmark based approach, which as we’ll see in a second is particularly misguided for Swift's theoretically intended use case as an app language. I think increasingly people agree with this as they haven't really found Swift to deliver on some amazing performance that wouldn’t have been possible in Objective-C. This is for a number of reasons:

1. As mentioned above, the most important flaw with a performance based Swift argument is that the vast majority of the stack is still written in Objective-C/C/etc.. So even if Swift was dramatically better, it’s only usually affecting your app’s code. Oftentimes the vast majority of the time is spent in framework code. Think of it this way: pretend that all of iOS and UIKit were written in JavaScript, but then in order to “improve performance” you write your app code in C. Would it be faster? I guess, but you can imagine why it may not actually end up having that much of an effect. This was ironically the bizarre position we found ourselves in with Swift: your app code was in a super strict typed language, but the underlying frameworks were written in a loosey-goosey dynamic language. This is exact opposite of how you'd want to design a stack. Just look at games, where performance is often the absolute top priority: the actual game engine is usually written in something like C++, but then the game logic is often written in a scripting language like Lua. Swift iOS apps are the reverse of this. Now, I'm sure someone will argue that the real goal is for the entire stack to eventually be in Swift, at which point this won't be an issue anymore, but now we're talking about a 20-year plan, where it seems weird to prioritize my Calculator app's code as the critical first step.

2. As it turns out, Objective-C was already really fast! Especially since, due to its ability to trivially interface with C and C++, a lot of existing apps in the wild had already probably topped out on performance. This wasn't like you were taking an install base of python apps and getting them all to move over to C. This was an already low-level language, where many of the developers were already comfortable with the "performance kings" of the C-family of languages. Languages, which, for the record, have decades of really really good tooling specifically to make things performant, and decades of engineering experience by their users to make things performant. And so, in practice, for existing apps, this often felt more like a lateral move. I actually remember feeling confused when after the announcement of Swift people started talking about Objective-C as if it was some slow language or something. Like, literally the year before, Objective-C was considered the low-level performance beast compared to, say, Android's use of Java. Objective-C just wasn't that that slow of a comparison point to improve that much on. The two languages even share the same memory management model (something that ends up having a big affect on its performance characteristics). Dynamic dispatch (objc_msgSend) just does not really end up really dominating your performance graph when you profile your app.

3. But perhaps most importantly, I think there is a mirror misguided focus on language over frameworks as with the developer ergonomics issues I pointed out above. If you look at where the actual performance gains have come from in apps, I’d argue that it’s overwhelmingly been from conceptual framework improvements, not tiny language wins. A great example of this is CoreAnimation. Making hardware accelerated graphics accessible through a nice declarative API, such that we can move as much animation off the CPU and onto the GPU as possible, is one of the key reasons everything feels so great on iOS. I promise no language change will make anywhere near as big of a dent as Apple's investment in CoreAnimation did. I’d argue that if we had invested development time in, e.g., async/await in Objective-C, rather than basically delaying that work for a decade in Swift, we’d very possibly be in a much more performant world today.

Anyways, these are just a few of thoughts on the performance-side of things. Unfortunately, as time moves on, now a decade into this transition, while I find more people agreeing with me than, say, when Swift was first announced, it also becomes more academic since it's not like Apple is going to go back and try to make Objective-C 3 or something now. That being said, I do think it is still useful to look back and analyze these decisions, to avoid making similar mistakes in the future. I think the Python 2 to 3 transition provided an important lesson to other languages, I hope someday we look at the Swift introduction as a similar cautionary tale of programming language design and community/ecosystem stewardship and management.

1. https://forums.swift.org/t/standard-vapor-website-drops-1-5-...

Correct, it is well known that they kept Swift a bizarre secret internally. It seems no one thought it would be a good idea to consult with the vast swathes of engineers that had been using the language this was intended to replace for the last 30 or so years, nor to consult with the maintainers of the frameworks this language was supposedly going to help write, etc. As you can imagine, this led to many problems beyond just not getting a large enough surface area of compiler performance use cases.

Of course, after it was released, when they seemed very willing to make backward-incompatible changes for 5 years, and in theory they then had plenty of people running into this, they apparently still decided to not prioritize it.

1. They wrote it to replace C++ instead of Objective-C. This is obvious from hearing Lattner speak, he always compares it to C++. Which makes sense, he dealt with C++ every day, since he is a compiler writer. This language does not actually address the problems of Objective-C from a user-perspective. They designed it to address the problems of C++ from a user-perspective, and the problems of Objective-C from a compiler's perspective. The "Objective-C problems" they fixed were things that made Objective-C annoying to optimize, not annoying to write (except if you are a big hater of square brackets I suppose).

2. They designed the language in complete isolation, to the point that most people at Apple heard of its existence the same day as the rest of us. They gave Swift the iPad treatment. Instead of leaning on the largest collection of Objective-C experts and dogfooding this for things like ergonomics, they just announced one day publicly that this was Apple's new language. Then proceeded to make backwards-incompatible changes for 5 years.

3. They took the opposite approach of Objective-C, designing a language around "abstract principles" vs. practical app decisions. This meant that the second they actually started working on a UI framework for Swift (the theoretical point of an Objective-C successor), 5 years after Swift was announced, they immediately had to add huge language features (view builders), since the language was not actually designed for this use case.

4. They ignored the existing community's culture (dynamic dispatch, focus on frameworks vs. language features, etc.) and just said "we are a type obsessed community now". You could tell a year in that the conversation had shifted from how to make interesting animations to how to make JSON parsers type-check correctly. In the process they created a situation where they spent years working on silly things like renaming all the Foundation framework methods to be more "Swifty" instead of...

5. Actually addressing the clearly lacking parts of Objective-C with simple iterative improvements which could have dramatically simplified and improved AppKit and UIKit. 9 years ago I was wishing they'd just add async/await to ObjC so that we could get modern async versions of animation functions in AppKit and UIKit instead of the incredibly error-prone chained didFinish:completionHandler: versions of animation methods. Instead, this was delayed until 2021 while we futzed about with half a dozen other academic concerns. The vast majority of bugs I find in apps from a user perspective are from improper reasoning about async/await, not null dereferences. Instead the entire ecosystem was changed to prevent nil from existing and under the false promise of some sort of incredible performance enhancement, despite the fact that all the frameworks were still written in ObjC, so even if your entire app was written in Swift it wouldn't really make that much of a difference in your performance.

6. They were initially obsessed with "taking over the world" instead of being a great replacement for the actual language they were replacing. You can see this from the early marketing and interviews. They literally billed it as "everything from scripting to systems programming," which generally speaking should always be a red flag, but makes a lot of sense given that the authors did not have a lot of experience with anything other than systems programming and thus figured "everything else" was probably simple. This is not an assumption, he even mentions in his ATP interview that he believes that once they added string interpolation they'd probably convert the "script writers".

The list goes on and on. The reality is that this was a failure in management, not language design though. The restraint should have come from above, a clear mission statement of what the point of this huge time-sink of a transition was for. Instead there was some vague general notion that "our ecosystem is old", and then zero responsibility or care was taken under the understanding that you are more or less going to force people to switch. This isn't some open source group releasing a new language and it competing fairly in the market (like, say, Rust for example). No, this was the platform vendor declaring this is the future, which IMO raises the bar on the care that should be taken.

I suppose the ironic thing is that the vast majority of apps are just written in UnityScript or C++ or whatever, since most the AppStore is actually games and not utility apps written in the official platform language/frameworks, so perhaps at the end of the day ObjC vs. Swift doesn't even matter.