And also don’t tip your waiters because that just helps the owner /s.
I work in a Windows-dependent company, and would very much like to see all MS-products thrown out. Withholding features is ignorant and will make everyone’s lives miserable. Users won’t see it as a problem with Microsoft, they might not see it as a problem at all, they will just quietly suffer.
A slightly better path is to guide users to standardized, open applications on Windows. Then, an admin might have an easier time eventually pulling the cord without breaking too many workflows.
As a single anecdote, I will say that when I personally migrated from Windows to Linux, it was a lot easier because I was already using mostly FOSS applications. It turns out, if you use Windows to run Firefox and Libreoffice and whatever, there's a lot less friction to using Linux to run Firefox and Libreoffice and whatever:)
Have you engaged with the advanced features? TS is the only mainstream language that lets you express pretty much everything in the typesystem, to the point where I frequently have to hold myself back.
Having used Swift and Kotlin in the past, their typesystems don’t come close to the flexibility with which you can wrangle data in TS. Many concepts that I would consider fundamental are either not present or require complicated syntax eg.: product types A & B, sum types A | B, { …spreading }.
And where Swift needs custom syntax such as `guard let` and `case let` to narrow types, Typescript is able to analyze normal control flow.
For practical reasons, there are a ton of ugly workarounds, but I’d rather live with those than go back to the rigid “Java++” languages.
those are intersection types and union types and are much more unique and rare in type systems eg all typed functional languages have product/sum types but typescript is the only mainstream language I know to have unions and intersection.
The problem is the type system is not strong, where structural typing can cause a lot of issues, such as adding a property to an object for example and the typechecker will not care. This does not happen in more strongly, non-structural typed languages.
Yeah that's one of the practical workarounds I mentioned. It mostly comes up while spreading (which is why spreads should usually go first) and when persisting (which is why your ORM should have a runtime schema).
But it's a double edged sword:
- You can brand types with additional information. For example, React Query does this to keep track of which type is stored under which cache-key. This is where most strongly typed languages just give up.
- You can progressively extend/narrow types without having to worry about inheritance. Invariants can be statically checked by encoding them in a type: eg IssuedInvoice = Invoice & { … }. A function that needs only a subset of a domain-object can specify this rather than requiring the email-address to verify a phone number.
- You can even emulate nominal types using keyed unions.
The first two alone have saved me from more errors than structural typing introduced.
...and then WhatsApp starts to send ads in push-notifications that you can't turn off. And you either have to live with it, or be a massive black hole in your friends communities.
I don't know if RCS is the way, but monopolistic messaging apps definitely aren't.
> and then WhatsApp starts to send ads in push-notifications that you can't turn off
*that you can't filter.
Every time an app begs me to enable notifications, I give it the side-eye because I immediately assume it's going to include notifications that I don't want to see, which are essentially ads for some app feature / some part of their walled garden.
I want to be able to filter notifications at the OS level. That could be by a substring search on the content of the notification, or by a unique-per-call-site (in the code) identifier included in the API the app uses to surface a notification (though I suspect most apps would just re-use the same identifier everywhere because the developers don't want me to be able to filter their ads).
Apple Maps is not that good. The main selling point of like half their services was “we're worse but at least not an ad-company”.
Due to some misguided loyalty, I usually search for places in AM fist, then switch to Google. I still don't see viable alternatives to their operating systems, but it's clearly time to de-apple wherever you can.
It's not automatic though. Theres function calls() and you must createSignal for every derived value.
When you ignore the performance aspect, React has the objectively least amount of boilerplate for reactivity.
The question, that I genuinely don't know the answer to, is a) whether the performance improvement is worth it, and b) whether that's still the case after the compiler.
React is the most inefficient in terms of performance (after imgui); it recomputes everything on every event like mousemove. It was probably made for simple forms with tens of variables.
On desktop that ship has sailed. Maybe 2 of my regularly used apps have a native design.
UIs have converged enough that the experience is acceptable I guess. And as a devolper, why in the world would I want to write my app for a locked-in ecosystem with a now shitty design-system.
It hasn't fully done so on the desktop when you consider macOS. E.g. if you ship a macOS app which has the main menu bar inside the window (or missing entirely) instead of using the system menu bar, it will look very jarring and users will rightly complain.
There's a reason why unixporn only ever shows a terminal and a handful of applications in very specific states.
MacOS was (because it sure as hell isn't anymore) so great because it had multiple talented third-party designers all building on the same consistent design system.
I assume the native Mac-app ecosystem will die from this update. iOS will recover, but for Mac it's gonna be custom designs and electron all the way.
- I haven't dealt much with SwiftUI myself, but several developers mentioned¹ a buggy and unstable migration process to the new design.
- Most pro users (aka devs) are probably not convinced by this design language anyways
- Even before Tahoe, cross-platform apps had been eating away at the native market (Obsidian, Figma, VSCode, 1Password, ...).
- Apps that are still native are usually not best-in-class anymore - especially Apples own apps.
Their reasoning may be that, if Mac apps are dying anyways, they could at least get iPad apps to replace them. If it didn't work for Microsoft, maybe it will work for Apple.
On the bright side, I feel less locked into MacOS now.
I'd say a program or subcommand tha comes with the compiler/interpreter. Go has gofmt, zig has zig fmt.
The compiler already parses the language so a formatter is only a few steps from that. And being part of the compiler means it's always up to date, there's less bikeshedding, all IDEs and text editors get formatter support easily.
it's config file, so they are often edited in unusual configurations without normal editors present. And they are often not checked in the source code, so there is no standard way to add linter.
And KSON is pretty unique in how bad is it. For example, go to playground and remove a single dot in line 11 (after the books list). Look how the parse tree changes - this 1-character edit means the file is still valid, but the rest of the file is now filed under one of the books.
Do you know of any other config language with this property - a single character removed yields a syntactically correct file which yet parses absolutely incorrectly? I don't. Worst I can think of is maybe one section parses weirdly, or next element of a list. But something like _entire rest of file_ is broken is unique to KSON.
I work in a Windows-dependent company, and would very much like to see all MS-products thrown out. Withholding features is ignorant and will make everyone’s lives miserable. Users won’t see it as a problem with Microsoft, they might not see it as a problem at all, they will just quietly suffer.
A slightly better path is to guide users to standardized, open applications on Windows. Then, an admin might have an easier time eventually pulling the cord without breaking too many workflows.