Due to potential new direction of D, I’m looking for some escape route just in case. I’m primarily a gamedev, so no functional programming languages like Rust or Haskell. Also one of the features I dislike the most in C/C++ is the super slow and super obsolete precompiler with its header files, so no zig, I don’t want to open two files for editing the same class/struct. Memory safety is nice to have, but not a requirement, at worst case scenario I’ll just create struct SafeArray<Type>. Also I need optional OOP features instead of reinventing OOP with all kinds of hacks many do when I would need it.
Yes I know about OpenD, and could be a candidate for such things, just looking into alternatives.
Swift is… not a great language. It’s got some promise but goddamn does it have a “designed by committee” feel to it; they just keep throwing on features like they’re going out of fashion and it’s getting ridiculously complex. Just the syntax alone is a bit of a nightmare – soooo many keywords and symbols. It’s also extremely hard to predict how well Swift code will perform, in large part due to ARC (automatic reference counting) memory management, which is a huge downside for game development. And don’t even get me started on the new concurrency stuff…
Just as a side note, it’s not purely an Apple project nowadays. They’re still the “project lead” but it’s not exclusively theirs anymore. Still, regardless of that, at least personally I really couldn’t recommend it especially to someone looking to get into game development.
I mean, Swift is not an Apple project just like .NET is not a Microsoft project - barely. I have not heard of significant outside involvement in either of them.
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.)
Far as Swift’s syntax goes, I really like argument labels too, but it’s just that there’s SO. MUCH. SYNTAX. Lots of sugar, yes, but sometimes that’s part of the problem in my opinion, because it often adds to the syntactic and semantic “noise.” Also, there’s 98 keywords (more if you count eg.
try,try!andtry?as different keywords, and this count is missing eg.sendingand other new keywords) – compare this to say Rust’s or or Python’s 35. Java’s got 68, while C++ also has 98 and it’s notorious for having way too many of them. And then there’s all the symbols – some of which have different meanings in different contexts.It’s true that ARC only applies to reference types, but even with value types you can often get some fairly surprising performance problems due to implicit copies, for example in getters and setters – and the
_readand_modifyaccessors that can sometimes help with that due to returning (well,yielding) a borrowed value instead of a copy aren’t meant for “public” use (which doesn’t mean many libraries etc. don’t use them, much to the consternation of core devs).