I think some dyed in the wool programmers are not afraid to learn something new but from experience see some nightmarish patterns in rust (e.g. c++ style templates for generics, phantom) and also watch less experienced programmers/architecture astronauts successfully argue to move things to rust without considering the future pain and are legitimately worried about being eventually forced to use it. Doesn't help that e.g. government is now saying "don't use memory unsafe languages".
I learned C++ first and Rust only within the past couple years, and I'd never willingly choose write a project in C++ again with the option to use Rust instead. Generics can get messy and the phantom data is indeed awkward, the difference to me is that in Rust if you go wrong the compiler most often can highlight the exact issue and suggest accurately how to fix it. My experience with C++ is that the compiler errors tend towards being so incomprehensible they sometimes felt intentionally misleading. The Rust compiler enforces correctness to a degree that gives me significantly more confidence in the programs I write; C++ is a major improvement on C here but still gives you so many ways to shoot yourself in the foot that would just not compile in a Rust project.
I haven't actually, glad to hear it! I still see big advantages to the extra compile time safety provided by Rust, and despite the mentioned similarities I find its syntax significantly clearer to read and write. C++ templates took me forever to really wrap my head around where a similar declaration in Rust feels immediately intuitive even where I don't fully understand all the nuances.
Almost ten years ago I was really excited about rust, but the sort of thing you describe has really put me off. It's become 'C++ but with better guarantees', whereas I liked it for being 'python ergonomics with stricter correctness' or something.
I really think there's room for a language more focussed on (sacrificing a bit for) usability/readability/DX - rust has great features like doc tests, in-module tests, structural pattern matching, macros, traits, .. but<some<of<the<container<crap, 'that>, ends<up, necessary>>>>> really ruins it for me. And on the one hand yes it is trivial, it is just syntax. But I do think it matters?
(It's late, I'm tired, not a very well formed thought, but coincidentally I was daydreaming about designing a language earlier today, so here we are.)
A compositional type is just a consequence of having a good type system. It means that you can slice your requirements into multiple independent types because they are individually describable in the type system. The converse is not true, which is why C++ also seems to have a compositional type. (C++ doesn't really have a true compositional type; C++ templates have no such guarantees, and thus even harder to use than true compositional types.)
Non-Apple development keeps getting better. It’s a very easy to read language with lots of safety, strong types,good standard library, await, and tons of users (thanks to Apple). Integrates easily with C/C++/Obj-C/Obj-C++, or anything else that can do C interop. Just gained neat macros and tests.
It’s probably my current “if I could pick anything” language.
On top of all the rest, it looks more like JS/Python than the pile of symbols C++ or Rust or even Obj-C can turn into.
Ladybird browser decided to use Swift of all things. I am just confused on how can one use a ARC based language for extreme performance software like a browser . Don't you need manual memory control or custom memory paradigms like arenas ?
Nice, but like the extinct Dodo, these are all affectionate memorials to dead software. The web browser is still alive and kicking after 30 years. And is the world's most popular software application. And all the mainstream browsers are mostly written in C++. Even the massively hyped Servo never got adopted into Firefox.
Swift has always been designed with the potential for more manual memory control. Recently, non-copyable types were introduced, and non-escapable types are currently being proposed. Additionally, more ownership control features are being added. While there is still much work to be done, progress is steady.
> it looks more like JS/Python than the pile of symbols C++ or Rust or even Obj-C can turn into.
I mean, maybe at a surface level. But under the covers with stuff like existential containers, opaque types, boxed types, ARC, etc it's a lot more complicated
Maybe the syntax "looks" modern like python but writing in it feels like smart pointer C++ with more safety features built in
Personally I'd rather just use C++ with a strict style guide, fewer new semantics to relearn
It's also funny that apple presents it as a "beginner friendly" language. Maybe it's possible for people to write in it without getting too far in the weeds, but like C++ it feels like a kitchen sink
Maybe all languages are like this to some degree, where there's a big gap between being proficient enough to write something and knowing it well enough to write something properly. It feels like Swift has a low barrier of entry but doing things properly has a much higher learning curve
Do you expect people to become expert rust programmers over night? I have 15 years of c++ under my belt and only recently got the chance to do some rust. Of course some of my rust code is going to look like c++ until I get some practice, some code review criticism, and personal study in. I’m here for the journey, and I am enjoying rust’s perks and mostly less mental overhead.
Rust superficially looks like C++ to avoid looking weird to existing C/C++ programmers, but semantically it's quite far from C++. Rust's generics are not like C++ templates: they're only type based, and don't use syntax-based matching, don't have tricks like SFINAE. ODR is guaranteed by construction. Trait lookup is simpler: there's no overloading, no inheritance, no implicit conversions, and interaction with namespaces is simple (ambiguity is an error).
Phantom type looks alien if you haven't used it, but for what it does, it's actually a pretty simple. It's there to explain in Rust's terms what an opaque type or a foreign C/C++ type does. You just need to give Rust an example of an equivalent type, and you get a correct as-if behavior, and you don't need to even know that you've just configured type's variance and destruction order checking.
Fair enough. I have personally experienced pain with phantoms.
But then what would you advice to do ? There are nightmare patterns in rust and c++. Looks to me as pick your poison just that one is new and other has been around for fair bit.
I am sorry. I really don't see your point. Typescript is in a completely different league of languages than rust/c/c++ with vastly different use cases.
Also, the world still mostly speaks C99 when iterative improvements are constantly being made up to C23.
The point is that Typescript was able to replace JavaScript by adding to it. Converting a codebase from js to ts was simple. Going from C++ to Rust is not.
I think C23 is going in the right direction, but it needs to go further.
