What I mean is that you (IIUC) can’t use an AGPL library in a GPL app without relicensing the whole thing to AGPL. For many larger projects relicensing is a huge hassle and often a non-starter if there aren’t very good reasons for it.

“just don’t enforce it” probably isn’t enough for most companies and projects

A good reason to pick GPL is if you want to allow GPL software to integrate yours and you don’t care that much about the AGPL clauses (e.g. because your app isn’t a server).

CC0 might be a good fit for trivial template repos where you don’t want to burden downstream projects with having to include copyright notices.

Also the iOS SDK isn’t freely available, so you’d have to copy that out of an Xcode installation… but given enough time and effort, you could almost certainly hack together a cross-compilation config for Clang that compiles an unsigned iOS app on Linux. Signing it might in fact be the bigger issue, since I’m not aware of any tools that sign Mach-O binaries on Linux.

JS is fine, it’s more that people overdo it and bundle their heavy, deeply layered frameworks with thousands of npm dependencies for the web. Often times analytics/tracking/ad libraries are a major contributor of bloat, I once shrunk down a package-lock from thousands of lines to a few hundred just by stripping the telemetry libraries from an open-source app.

Use the right tool for the job. Sometimes it’s a static page, sometimes a server-rendered dynamic page and sometimes a single-page application, all of those can be made performant.

Having the ability to overload functions or constructors without a million Stuff::with_x variants is something I consider more ergonomic and not unsafe. I know the Rust community prefers explicitness in many places, but explicitness and safety are somewhat orthogonal in language design. I consider e.g. Swift to be a safe and ergonomic/sugared language, that borrows, no pun intended, a lot of ideas from Rust

As long as you limit yourself to a subset of modern C++, it’s actually a decent language. Less guardrails than Rust, but more syntactic sugar (think overloading, default parameters, implicit this, implicit reference-taking, implicit conversions). You could argue those are anti-features, but even as someone who really likes Rust, I gotta admit C++ is occasionally more ergonomic.

VSCode + CodeLLDB is great (and FOSS), surprised no one mentioned this yet

I know a bunch of larger C++ apps that use vcpkg for cross-platform (Windows/macOS/Linux) builds of their dependencies and it seems to work pretty well

When case insensitivity is the default I always wonder how many apps unknowingly rely on that due to typos somewhere. I encountered this once while porting a Windows/macOS app to Linux that someone imported a module with the wrong case and nobody noticed

Tbh rust-analyzer is still pretty great. What bothers me more is that Kotlin is pretty much the only language without an official language server, because it doesn’t align with their business interests…

It’s opt-in in Swift 5 mode and opt-out in Swift 6 mode, the Swift 6 compiler supports both modes though and lets you migrate a codebase on a module-by-module basis.

Agree that opt-in sort of defeats the point, but in practice it’s a sort of unavoidable compromise (and similar to unsafe Rust there will always be escape hatches)

Swift does have data race safety as of Swift 6 with their actor-based concurrency model and are introducing noncopyable types/a more sophisticated ownership model over the next few releases

Swift fits the description too

Not that specific tbh, most newer native languages these days are compiled and memory safe (Rust, Swift, Go, Kotlin Native, etc)

Coming from Haskell, OCaml always felt a bit strange to me. The double semicolons, the inconsistency in the standard library between curried and uncurried functions etc. Maybe I’m confusing it with Standard ML though, can’t remember.

It took them a few years, if I remember right, though they did add the unlock-with-watch pretty early.

Counterpoint, I believe the Swift syntax strikes a much better balance than Rust in terms of ergonomics and argument labels are awesome for designing fluent APIs. There are things that Rust does better, aside from having a bigger ecosystem, namely the whole borrowing/ownership system, though they’re catching up (noncopyable types and references are coming soon).

The concerns about ARC are generally a bit overstated, ARC only comes into play with classes, which modern Swift greatly deemphasizes in favor of structs, enums and protocols. Sure, sometimes you need them, especially when interoperating with Objective-C, but Rust has its escape hatches for reference counting too (Rc/RefCell, Arc/Mutex), those are just (intentionally) a bit more verbose.

In short, Swift encourages a very similar, value-oriented programming style as Rust with a modern type system (generics, associated types etc.), while offering lots of nice syntactic sugar (property wrappers, result builders etc.)

CMake can also emit its own errors during the configure step though, particularly if you have complicated build logic and/or lots of external packages.

That’s mostly still true, with the small caveat that the default prefix on arm64 macOS is /opt/homebrew rather than /usr/local, so you might have to add it explicitly to your PATH