rust

recated and removed [0] So TL;DR: 1-4 bytes => 1 character, 2+ characters => maybe 1 grapheme cluster. Hope that helps either you, or someone else reading this. [0] https://github.com/rust-lang/rust/pull/24428

atic, but mildly discouraged. println! is a macro because it 1) is a compiler intrinsic to do compile time magic like the recent addition of capturing bindings directly in the formatting string and 2) it takes a variable number of arguments. Differentiating between macros and function calls is important if you want to get a sense for what the code you're reading can do. You can choose another way of differentiating them, but whatever you choose will be subjective and has to mesh well with the rest of the language. Explicit self makes it easy syntax to differentiate between associated functions (part of the type) and methods (part of the instance), while also making very clear when you're accessing the current instance's data. And because Rust cares about mutability and ownership, you still need to communicate the differences between self, &self and &mut self. It also provides syntactic space for arbitrary self types: fn foo(self: Pin<&mut Self>)

when unit testing. It's way more valuable to ensure docstrings and standalone documentation are valid.

ler can catch panics, but panics are not the primary "exception" analogue in Rust. Panics are only for fatal errors. I don't know anything about Swift, but from a quick search I see something called "Fatal Errors", which I assume act a similar way. Now to address the points in your gist. > lauded the Borrow Checker for discouraging people from using the borrow checker! This results in less performant code much of the time. The borrow checker is much improved with non-lexical lifetimes which makes it far easier to deal with. > The escape hatch of macros and build-time source generation has allowed Rust to sweep some of its usability issues under the rug (Just use a macro!). Swift strives to support all of the use cases developer have in the language itself I have no idea how you could, for instance, implement something like `serde` without macros or reflection without building it into the language. Other common uses, like `lazy_static`, have been replaced with better APIs that don't use macros at all. Building these things into the language or standard library without enough experimentation beforehand can be problematic, as `lazy_static` shows. Rust's development is more open than Swift. It doesn't have the luxury of a single owner that can dictate THE WAY to do things, because it must support use cases from web servers to embedded MCUs. Macros and other forms of build-time execution provide that flexibility. > Coarse Imports Personally, I think Rust's module system and imports area the best I've ever used. As I said, I've never used Swift. Are all of the standard library functions in a single namespace? I imagine that this makes implementing things like refactoring much easier. > First party IDE > > Say what you want about Xcode Xcode is MacOS exclusive. > With the current state of RLS, developers often forsake modern IDE features even though reliable code completion, refactoring tools and diagnostics greatly benefit developers. RLS is now deprecated, and rust-analyzer is fantastic. > Out-of-the-box debugging experience I haven't ever tried interactive debugging with Rust, so I can't comment. > One of the more powerful uses of a type system is to have functions perform different processing based on the type of its arguments. I think one of the fundamental difference of today is that this should be handled by traits, not by standalone functions. > In Rust, this is achived via the From and Into mechanic. The first unfortunate consequence of this is that you often have to create a new type and trait pair per argument you want to be polymorphic. I don't think this is a common pattern at all. Generally you'd just implement the trait for each type and put the different behaviors in the trait impl, rather than in the function using an enum. > you can effectively only ever have one generic implementation of your custom into Into… for a trait, since otherwise the type checker complains there can at some point in the future be a collison. This is only true for types outside your crate. > In Rust, you cannot create trait objects out of certain types of traits. Often, you could use trait objects for this type of thing, but I haven't figured out a way to do this with more complex constraints. For instance: trait Bar {} trait Baz {} trait Foo { // This is invalid fn foo(t: &(Bar + Baz)) -> (); } I think what you're looking for is: trait Foo: Bar + Baz { fn foo(&self); } This will work as long as Bar and Baz are object-safe. > Making it generic disallows using Foo as a trait object: trait Foo { fn foo<T: Bar + Baz>(t: T) -> (); } // This is invalid fn do_work(f: &Foo) -> () { … } You can make the trait generic instead of the function: trait Foo<T: Bar + Baz> { fn foo(&self, t: T); } > Multiple if let cases They are a work in progress, available in nightly: https://github.com/rust-lang/rust/issues/53667 But they do require an extra level of parens in some cases, though I think that's insignificant. > Guard Statements Rust has these now as "let ... else" statements. let Pattern(binding) = thing else { ... }; > Explicit try This was covered above: use Result or Option instead. Panics are not exceptions. And as for unwrap, yeah you just have to know that it will panic. It's just a thing you have to know about the language, like `try`. > Rethrows Transpose is stable now. But generally for that case I'd do this instead: let y = Some(1).ok_or(Error)?.and_then(|i| { if i > 3 { Err(Error) } else { Ok(i + 1) } })?; > Ternary Operator I prefer the lack of a ternary, since, as you show, an if can do the same thing. > String Interpolation You can include variable names inline now. And they're not C-style at all. > Named arguments Personally, I've never felt the lack. Especially with the inline hints from rust-analyzer. > Default arguments I actually prefer how Rust does not have function overloading. This includes default arguments and optional arguments. > Function-level polymorphism And the above also applies to this. > This is also useful for operators (in Swift, + is a polymorphic function) This is implemented with traits in Rust. > Alternatively, you could use use: use MyDescriptiveEnum as E; match e { E::Foo => …, E::Bar => …, } You can do a glob import instead use MyDescriptiveEnum::*; match e { Foo => …, Bar => …, } > Raw types for enumerations Rust enums have this for primitive numeric types, but others do not. > Rust's enum and struct initializers all use different syntax. In Swift, there is a single syntax Sure, they both use parens, but they are still different syntaxes. > Trailing Closures I don't like this. Seems like a special case for little to no reason. > Default Closure Arguments Same as the above. > Extensions, Type Inference for Associated Types I agree these could be useful improvements.