fn list_items<'life0, 'life1, 'async_trait>(
&'life0 self,
collection_href: &'life1 str,
) -> Pin<Box<dyn Future<Output = Result<Vec<ItemRef>, Error>> + Send + 'async_trait>>
where
Self: 'async_trait,
'life0: 'async_trait,
'life1: 'async_trait,
Source: https://git.sr.ht/~whynothugo/vdirsyncer-rs/tree/v2.0.0-beta...
Not only is is incredibly ugly it's also rather confusing, but it fits well into how I view Rust, complicated for the sake of making the developers look smart.
It wouldn't fit the syntax of the language obviously, but why not simply have the developer prefix the variable with the keyword "lifetime", rather than assigning a symbol. It seems a little like starting functions in Go with a upper case letter to export them, dude just give us an export keyword, it's fine.
' has a long history of use for various purposes in programming language syntax not derived from C.
In Ada, attributes are a single quote followed by the attribute name.
If I have an enum called Fruit then Fruit'First would give the first value in the Fruit enum definition.
http://www.ada-auth.org/standards/22rm/html/RM-4-1-4.html
Attributes provide meta information about types and are very useful when working with custom integer types and ranges:
https://learn.adacore.com/courses/advanced-ada/parts/data_ty...
Using ' for Rust lifetimes or Ada attributes is just a sigil https://en.m.wikipedia.org/wiki/Sigil_(computer_programming)
It is not too different from:
& for addresses / references in C, C++, and Rust,
* for dereferencing in C, C++, and Rust
$ for value substitution in shells and scripting languages
: to mark keywords in Clojure and some Lisps https://www.mainframestechhelp.com/tutorials/cobol/arithmetic-statements.htm
Language features that appeal to beginners and outsiders naturally aid in language adoption, even if they actively work against expert practitioners. So, funnily enough, we should a priori expect the zeitgeist opinion to favor lowest-common-denominator languages features and shun high-utility but "complex" ones.
That is a real shame, however. As a business or whatever, instead of maximizing for ease of onboarding, I want to maximize for facility in exploring the end-goal problem domain, i.e. expert work. Instead of picking a "readable" language, I want to pick one that increases our ability to find simple solutions to complex-seeming problems, conventionally readable or not.
IMHO, baseline languages like Python are great for writing down what you already think but terrible for iterating on your understanding, and 95% of our work as engineers is (should be?) changing our understanding of the problem to fit reality as it bumps us in the face.
Rust doesn't allow multi-letter character literals for the usual reason, so there is no real ambiguity. Some old editors do only have a very-limited syntax highlighter with fixed rules (e.g. no regexp), so such editors will be indeed unable to handle this, but they won't be able to support many other languages if that's the case.
let f = ... and
let f' = ...Can you clarify why you have that opinion? What would your syntax suggestion have been?
type 'a t = 'a option =
| None
| Some of 'a
fn slice<'a>(s: &'a str) -> &'a str { &s[0..2] }
This is not nothing if you ask me. Rust is a language within which your shifty naive program will still outperform many other solutions, all while being reliable as heck if you wield the type system the right way.
The only thing that I dislike about it is that certain code becomes unreadable. As this article says it often becomes unreadable for a reason — a reason which you would just not think about in other languages — but unreadable is still unreadable.
Unrelated to parent but maybe relevant to you: Rust API naming guidelines say no `get_` prefix on getters.
https://rust-lang.github.io/api-guidelines/naming.html#gette...
async fn list_items(&self, colletion_href: &str) -> Result<Vec<ItemRef>, Error>1) Every time I go through a particular door I try to push it when it's a pull door.
2) I notice this and ensconce in my brain that it's the opposite of what I think it is.
3) After a while, my brain actually starts to remember it the correct way around to start with.
4) But my brain doesn't then drop the 'opposite' rule so now I remember it the correct way around, then invert it, thus recreating step 1.
I don't claim this says anything about rust, but I think it does say something about human brains (or at least mine and apparently yours).
My sympathies.
Rust can improve this by introducing syntax like `'a contains 'b`
Sure, maybe I don't need to statically guarantee the correct execution of code that could easily just throw at runtime instead, but it sure is a fun hobby.
Of course Rust is not perfect; there is some 'leakages' of low level aspects to high level like async caveats(recursion, pinning, etc.). I'm not sure how these can be avoided. Maybe just trial-and-errors for all..?
Albeit I admit there somewhat exists a community sentiment like "if you use Rust, you should maximize its zero cost abstraction feature so lifetime is good and generics good", and my (minor) opinion is that, it's not always true to all users of Rust.
And the clumsy Arc<Mutex<Something<TheOtherThing>>> makes users feel bad about using runtime cost paid types. Maybe we should introduce easy Rust dialect which transpiles into Rc/Clone everywhere but I doubt it's trivial to transpile.
If you come to rust from high level language you can just do everything with Rc and cloning.
It's still hard because Rust, in opposition to every pipular language, is a value oriented language. But at least you won't have much contact with alphabet soup.
Cons are:
- C# has OOP (you don't have to use it heavily)
- No Hindler-Milner type inference in C#, nested generic arguments may need to be specified by hand
- Smaller amount of supported targets by CoreCLR: x86, x86_64, arm, arm64 for ISAs and Linux, Windows, macOS and FreeBSD for OSes. NativeAOT-based support is experimentally available on iOS, and is undergoing further work. As you can imagine, LLVM targets absolutely everything under the sun and above it too. no-std story in Rust is first-class. C# has bflat and zerosharp but they are niche.
- In C#, type unions will only be available in one of the coming versions. F# to the rescue
- Error handling is a combination of exceptions and e.g. int.TryParse patterns, there is no implicit returns with ? like in Rust
- Lack of associated types and the types own their interface implementations unlike traits which you can introduce without control over the source. This results in having to implement wrapper types (even if they are structs) if you want to modify their interface implementations
- You only control shallow immutability - readonly struct will not prohibit modification of the contents of a Dictionary<K, V> that it holds
- async/await is more expensive
- Big popular libraries often have features or implementation incompatible or not guaranteed to work with native compilation via NativeAOT
- Object reference nullability (e.g. 'T?') happens at the level of static analysis i.e. does not participate in type system the same way Option<T> does in Rust
Pros are:
- Has FP features like in Rust: high order functions, pattern matching (match val -> val switch { , also 'is'), records, tuples, deconstruction
- Fast to compile and run, AOT not so fast to compile but tolerable
- If you know how to use Cargo, you know how to use .NET CLI: cargo init -> dotnet new {console, classlib, etc.}, cargo run -> dotnet run, cargo build -> dotnet build/publish, cargo add {package} -> dotnet add package {package}
- Monomorphized structs generics with the same zero-cost abstraction assurance like in Rust, &mut T -> ref T, &T -> ref readonly T, sometimes in T but with caveats
- Box/Arc<T> -> class or record, Arc<Mutex<T>> -> class + lock (instance) { ... }
- Easy to use async/await but without ever having to deal with borrow checker and misuse-resistant auto-scaling threadpool. Task<T>s are hot started. Simply call two task-returning network calls and await each one when you need to. They will run in background in parallel while you do so. While they are more expensive than in Rust, you can still do massive concurrency and spawn 1M of them if you want to
- Built-in Rayon - Parallel.For and PLINQ, there is Channel<T> too, you can e.g. 'await foreach (var msg in chReader) { ... }'
- Iterator expressions -> LINQ, seq.filter(...).map(...).collect() -> seq.Where(...).Select(...).ToArray(), unfortunately come with fixed cost but improve in each version
- Rust slice that wraps arbitrary memory -> Span<T>, e.g. can write the same fast idiomatic text parsing on top of them quite easily
- Stupid fast span routines like .IndexOf, .Count, .Fill, .CopyTo which use up to AVX512
- Compiler can devirtualize what in Rust is Box<dyn Trait>
- Can make small native or relatively small JIT single-file executables that don't require users to install runtime
- Rich and fast FFI in both directions, can statically link into Rust, can statically link Rust components into itself (relatively new and advanced)
- Great tooling, Rider is very good, VSCode + base C# extension about as good as rust-analyzer
- Controversial but powerful runtime reflection and type introspection capability, can be used in a very dynamic way with JIT and compile additional code on the fly
- A bit easier to contribute to, depending on area owner and project (runtime, roslyn, aspnetcore, ...)
- CoreLib has full-blown portable SIMD API that is years ahead of portable-simd initiative in Rust
Because I occasionally use Rust and prefer its formatting choices, I carry this .editorconfig around: https://gist.github.com/neon-sunset/c78174b0ba933d61fb66b54d... to make formatting terser and more similar. Try it out if K&R and `I` prefix on interfaces annoy you.
In other words, be careful what you wish for.
Most people would probably be better served by a language that was a tiny bit slower but had better developer productivity. However, once you deviate from the goal of “as fast as possible”, then you have to choose which parts you want to sacrifice speed for productivity. Like Excel, everybody agrees that Rust is too complicated but nobody can agree on which 10% to remove.
I don't think most people use Rust because it's fast - fast is nice but Rust is being thrown at a bunch of use cases (e.g. backend services and APIs) for which it replaces "slower" garbage collected languages (the language being faster doesn't always make the overall product/service faster but that's a separate question).
What Rust gives you is a viable potential alternative to C and C++ in places where you absolutely can't have a GC language, and that's a huge deal, the problems and confusion start when people try to use Rust for everything.
> everybody agrees that Rust is too complicated
I don't think this is true either - a large part of the Rust community seem to think that it's as complicated as it needs to be. As a beginner/outsider, I found it kind of cumbersome to get started with, but that's certainly not everyone's opinion.
> Most people would probably be better served by a language that was a tiny bit slower but had better developer productivity.
True, and such languages already exist and are widely used, Rust doesn't need to fit that use case.
D maybe? D and Rust are the two languages which come to mind when I think about "possible C++ replacements".
Interestingly, my life starts at the end of the article, with the simple verison of the code, and as my understanding of rust widens, I go up to the beginning of the article and better define my function...
(defun read (path)
(declare (generic P (AsRef Path))
(type P path)
(returns (io:Result (Vector U8))))
(flet ((inner (path)
(declare (type (Ref Path) p)
(returns (io:Result (Vector U8))))
(try-let ((file (File:open path))
(bytes (vector)))
(declare (mutable file bytes))
(try (read-to-end file bytes)
(Ok bytes)))))
(inner (as-ref path)))) @usableFromInline
func _read(pathView: PathView) throws(IOError) -> [UInt8] {
var file = try File(pathView)
var bytes: [UInt8] = []
try file.readToEnd(into: &bytes)
return bytes
}
@inlinable
public func read<Path>(path: borrowing Path) throws(IOError) -> [UInt8] where Path: PathViewable, Path: ~Copyable {
try _read(pathView: path.view())
}
// Definitions...
public enum IOError: Error {}
public protocol PathViewable: ~Copyable {
func view() -> PathView
}
public struct PathView: ~Escapable {}
public struct File: ~Copyable {
public init(_ pathView: borrowing PathView) throws(IOError) {
fatalError("unimplemented")
}
public mutating func readToEnd(into buffer: inout [UInt8]) throws(IOError) {
fatalError("unimplemented")
}
}I can't understand this. Isn't this for polymorphism like what we do this:
```rust fn some_function(a: impl ToString) -> String { a.to_string(); } ```
What to do with memory layout? Thanks for any explanation.
As for `impl`,
fn foo(a: impl ToString)
fn foo<S: ToString>(a: S)
The reason the function takes `AsRef<Path>` instead of `&Path` is callsite ergonomics. If it took `&Path` all callsites need to be turned into `read(path.as_ref())` or equivalent. With `AsRef<Path>` it transparently works with any type that can be turned into a `&Path` including `&Path` itself.
pub fn read<P: AsRef<[u8]>>(path: P) -> Result<Vec<u8>>
The answer to the question “When do I need the ;; within OCaml source code?” is never.
It's not a part of the language and is only used by the interpreter as an end of input mark.
Historical note: In CAML Light, the predecessor of OCaml, double semicolons were mandatory. For this reason they are quite common in old code originally written in CAML Light or written in the early days of OCaml. These days they are considered a bad style.
pub fn read(path: Path) -> Bytes {
let file = File::open(path);
let bytes = Bytes::new();
file.read_to_end(bytes);
bytes
}
sub read(Str:D $path --> Buf:D) {
$path.IO.slurp: :bin
}
public byte[] Read(string path) => File.ReadAllBytes(path);
say $path.IO.slurp: :binOnly if you suffer from a very high level of stockholm syndrome, that is. Rust's syntax is vastly clearer than C++ in basically all circumstances.
* async closures
* async trait fns,
* `impl Trait` everywhere
are in place.
Would certainly help with the wild return and type signatures I've had to write involving combinations of `Pin` `Box` & `Future<Output = Result<...>>`.
I think Rust futures are really awesome as they expose the lower level details of how async behavior works, giving the developer the flexibility to adapt it to their use case - but the standard library really dropped the ball on standardized usage/types.
For instance, can we please just have `AsyncRead` and `AsyncWrite` traits? Can they also be easy to implement (are just `async read()`)?
Right now you have to use adapters between Tokio types and the Futures crate and they both offer their own non-interoperable read/write traits.
type Result<T> = std::result::Result<T, io::Error>;
When type signatures are so complex it makes vastly more sense to separate them out,
Consider,
read :: AsRef(Path) -> IO.Result(Vec(U8))
pub fn read(path):
inner :: &Path -> IO.Result(Vec(U8))
fn inner(path):
bytes := Vec.new()
return? file := File.open(path)
return? file.read_to_end(&! bytes)
return OK(bytes)
inner(path.as_ref()) pub fn read<P>(path: P) -> io::Result<Vec<u8>>
where
P: AsRef<Path>,
{
// ...
}
Funny, though, Rust's 'where' syntax sorta vaguely superficially reminds me of K&R pre-ANSI C:
unsigned char *read(path)
const char *path;
{
/* ... */
} pub fn read<P>(path: P) -> io::Result<Vec<u8>>
where
P: AsRef<Path>,
{
fn inner(path: &Path) -> io::Result<Vec<u8>> {
let mut bytes = Vec::new();
let mut file = File::open(path)?;
file.read_to_end(&mut bytes)?;
Ok(bytes)
}
inner(path.as_ref())
}
Please don't assume that the syntax of Rust has been given no thought.
In an Ada-like language, it would be something like
generic
type Path_Type implements As_Path_Ref;
type Reader implements IO.File_Reader;
function Read(Path: Path_Type) return Reader.Result_Vector_Type|Reader.Error_Type is
function Inner_Read(P: Path) return Read'Result_Type is
begin
File: mutable auto := try IO.Open_File(P);
Bytes: mutable auto := Reader.Result_Vector_Type.Create();
try Reader.Read_To_End(File, in out Bytes);
return Bytes;
end;
begin
return Inner_Read(Path.As_Ref());
end Read;I'm not arguing the example you found sand-in-the-eyes is necessarily good but my mental skim reading algorithm copes with it much better.
But while it is harder to _skim_, it is easier to _read_, as you don't have to concentrate on and decipher the syntax, risking to miss some of the crucial elements (oh, how do I hate missing ampersands in C++!).
pub fn read(path: Path) -> Bytes {
File::open(path).read_to_end()
} pub fn read(path: Path) -> Result<Bytes> {
File::open(path)?.read_to_end()
}
It compromises a bit on generality and (potential) performance to achieve better readability and succinctness. Often a worthwhile trade-off, but not something the standard library can always do.
"I think that most of the time when people think they have an issue with Rust’s syntax, they actually object to Rust’s semantics."
I prefer it this way; defaults should be conservative or more common: I write many many more private functions than public. I'm not sure what your objection to 'fn' is... seems like a superficial problem. It likely makes the language easier for the compiler to parse, and to me, it makes it easier to read.
> Why `: type' and `-> type', why can't type go before the identifier?
Because putting the type afterward is more ergonomic. If you're used to C/C++/Java/etc. it feels weird, but once you start writing code with the type after the declaration, it feels much more natural.
> Why do you need `File::' and `Bytes::'?
I'm not sure what you mean here. They're types. You have to specify types.
> What is that question mark?
The question mark is basically "if the Result is Ok, unwrap it; if it's an Err, return it immediately."
> Why does the last statement not need a semicolon?
Leaving off the semicolon returns the last expression from the block.
> It's like the opposite of everything people are used to.
Maybe if your experience with programming languages is fairly limited...
E.g. making pub default is precisely the decision a language would make that values concise code over what the code actually does.
The same reasoning works for “mut” as well.
That said, I don’t like Rust’s syntax. Especially once you get to lambdas, things get hard to read.
> Why `pub fn'? Why is public not the default and why do you have to specify that it's a function?
If public were the default, you'd end up having to make other functions `priv fn` instead.
> Why `: type' and `-> type', why can't type go before the identifier?
It's easier to parse, and most major typed languages other than C/C++/C#/Java put the type after the identifier.
> Why do you need `File::' and `Bytes::'?
Seriously?
> What is that question mark?
The final version doesn't use a question mark.
> Why does the last statement not need a semicolon?
This is a legitimate question. In Rust, the last statement without a semicolon becomes the return value.
My guilty pleasure is Go's visibility system, where all functions that start with lowercase are private to the scope of the current class/file and all Functions that start with Uppercase are public.
It doesn't look but it would work and it's a mess when you need acronyms, but it somehow works great and the result looks nice.