4 ms·
> Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C. Rust? Rust is basically a simpler Swift. The object
by nicoburns 8mo ago
> Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C.
Rust? Rust is basically a simpler Swift. The objective-c bindings are really nice too, and when you're working with obj-c you don't have have worry about lifetimes too much, because you can lean on the objective-c runtime's reference counting.
I think the way to think about it is that with Rust, it's as if all the goodness in Swift was implemented with in the "C" level, and the Objective-C but is still just library-level a runtime layer on top. Whereas Swift brings it's own runtime which greatly complicates things.
- estebank 8mo agoOne of my recurring language design hot takes is that it's easier to design for speed and then make it easy to use than it is to make it easy to use and then try to speed it up.
- coliveira 8mo agoC++ is trying to make C easier to use for 40 years, and it's still not there. So I wouldn't call that easier.
- astrange 8mo agoC++ is trying to make something EASIER to use?
- anthk 8mo agoC++ if any made C user friendly.
- jcelerier 8mo agohow would you write something like #include <print> #include <map> #include <string> int main(int argc, char** argv) { using namespace std::literals; std::string foo = "foo:"; foo += argv[0]; std::map<std::string, int> m{ {foo, 123} , {"count: "s + std::to_string(argc), 456} }; std::println("{}", m); } in C
- hackyhacky 8mo agoSure, there are nice parts of C++. And there are also brain-dead parts that add needless complexity such as: * rvalue references * the difference between auto, decltype, typeof * unreadable template monstrosities * various different flavors of "smart" pointer * the continued existence of footguns relating to UB, dangling pointers, unexpected temporary lifetimes, etc * total absence of a build system or package management * legacy APIs that still take raw pointers * concepts, a half-assed attempt at generic constraints
- pjmlp 8mo agoNo worries, you get some of those in C23, and C2y. Where is C's build system and package management? Yeah, because using _Generic alongside typeof and preprocessor macros isn't half-assed attempt at generics.
- hackyhacky 8mo agoYou misunderstood. Perpetuating C's weaknesses, and then adding additional complexity, is not a defense.
- pjmlp 8mo agoIt kind of is, when the goal was to be TypeScript for C, before this was even a concept. Now ideally we would all be using Modula-2, Ada, Delphi, VB, C#,.... and co, but given that even C compilers are nowadays written in C++, we make do with what we have, while avoiding C flaws as much as possible.
- deleted 8mo ago[deleted]
- pjmlp 8mo agoEven better example, import std; int main(int argc, char** argv) { using namespace std::literals; auto foo = "foo:"s; foo += argv[0]; std::map<std::string, int> m{ {foo, 123} , {"count: "s + std::to_string(argc), 456} }; std::println("{}", m); }
- pjmlp 8mo agoIt has been there for me since 1993, in every single scenario as alternative to C, when the choice boils down to either of them. Since 1993, I only have used C when required to do for various reasons out of my control, or catching up with WG14 standards.
- raincole 8mo agoExamples?
- zer0zzz 8mo agoExcept the entire design of swift is meant to make everything more automated. * automated exclusivity with value types and value witness tables, classes as arc types (ie Arc<Mutex<T>>) * automated interop with C/C++/Obj-C through the clang ast importer Maybe they could have started with rust and added on what they needed, but why not build a new language at that point where things so fundamental are involved? Source: I worked in lattners org at the time of swifts inception (on an unrelated backend) but that was the motivation. I also worked on the swift compiler for a little bit some years later on in my career.
- Someone 8mo ago> Maybe they could have started with rust and added on what they needed Unlikely, I think, because of timelines. Swift’s first public release was in June 2014. Rust is a few years older (first public release in January 2012), but that wasn’t the rust we have today. It still had garbage collection, for example (https://en.wikipedia.org/wiki/Rust_(programming_language)#2012–2015:_Evolution https://en.wikipedia.org/wiki/Rust_(programming_language)#20...)
- gbanfalvi 8mo agoI would absolutely not call Rust a simpler Swift. Swift doesn't have and ownership/borrowing system, explicit lifetime for objects, much more expressive (and therefore complex) macro support... I get that there's a tradeoff. Rust requires you to be way more explicit about what you're intending upfront and that can, in the long term, lead to simpler code -- but there's no dimension (depth-wise or breadth-wise) that I'd call Rust simpler.
- mojuba 8mo ago> I would absolutely not call Rust a simpler Swift. Swift doesn't have and ownership/borrowing system Swift already does have those things but unlike Rust, they are opt-in. Not going to argue which language is simpler, but sorry, you don't seem like someone who knows Swift very well.
- needlesslygrim 8mo agoWhile Swift now has the `borrowing` and `consuming` keywords, support for storing references is nonexistent, and the only way to return/store `Span`s, etc, is only possible through using experimental `@lifetime` annotations. Swift is a nice language, and it's new support for the bare necessity of affine types is a good step forward, but it's not at all comparable with Rust.
- lenkite 8mo agoRust is still more complicated than Swift, but you needn't worry - the Swift team is flexing their muscles hard to ensure that Swift becomes the biggest, most complicated language on Earth and wins the complexity, cognitive burden and snail performance once and for all eternity. Their compiler already times out on the language, soon even an M7 will also give up.