Rust's Ugly Syntax (2023)

https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html

by nequo • 2 years ago

161 162 2 years ago

matklad.github.io

sedatk3• 2 years ago

I think the article makes a good point, but the actual example isn’t Rust’s worst, not even close. It gets really hard to follow code when multiple generic types are combined with lifetime markers. Then it truly becomes a mess.

hckr1292• 2 years ago

Agree about the example! I can't tell if this article is tongue-in-cheek or earnest. I'm unclear on the point the author is trying to make.

tcfhgj4• 2 years ago

The author explains it in the first sentence, i.e. not the syntax of lifetimes may be your problem, but the feature itself

zarzavat3• 2 years ago

My reading is: people use Rust because it’s fast but then they complain about the semantics that make it fast.

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.

LoganDark5• 2 years ago

I always, always forget what `'a: 'b` means, because I remember it always being the opposite of what I think it is, but memorizing that obviously doesn't work because then it will just flip again the next time. It's so annoying.

nrabulinski• 2 years ago

I always describe it to myself this way - T: Foo means T is a superset of Foo (because it at least implements Foo but most likely more) thus 'a: 'b means 'a is at least as wide as 'b, and possibly wider

delifue• 2 years ago

In lifetime, subtype means longer lifetime (it's unintuitive). 'a : 'b means 'a is a subtype of 'b, which contains 'b and can be longer.

Rust can improve this by introducing syntax like `'a contains 'b`

runiq• 2 years ago

If you think of it as 'a implements b', it makes sense for both lifetimes and (other) subtypes: If lifetime `a` implements `b`, it is obviously valid for `b` (and maybe longer).

lifthrasiir5• 2 years ago

It was a good signal to me that you are overthinking into the architecture if that is really required. Rust makes something pretty much impossible in C/C++ possible, but not necessarily easy, and that would be one such example.

littlestymaar• 2 years ago

I had the same problem until I realized this: for generics and traits T: A means T implements A and it's actually the same with lifetimes: 'a: 'b means lifetime 'a implements lifetime 'b, which naturally translates to objects with lifetime 'a lives at least as long as 'b.

mst2• 2 years ago

I am reminded of many instances over my life of:

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.

bobbylarrybobby• 2 years ago

You have to first remember what lifetimes are there for in the first place: to indicate that values live at least a certain duration. That is what the type &'a means. Then it becomes clear what the relation 'a: 'b means

namjh2• 2 years ago

IMHO the mentioned examples of complexity like multiple type variables and lifetimes with bounds are for who "really" wants compile-time contracts. These are mostly opt-in so higher level use cases(like writing backend business logics) should not care about that, just wrapping everything with Boxes and Arcs.

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..?

Hamuko• 2 years ago

I do remember the compiler constantly suggesting lifetimes to me as a newcomer to the language, so it didn't really feel that opt-in. Quite a lot of the suggestions also started to look like someone poured alphabet soup all over the code.

yulaow• 2 years ago

throw in some async too and I really lose myself most of the times

WhyNotHugo2• 2 years ago

Here's a nice example of a Trait that has async functions:

    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,

Rendered docs: https://mirror.whynothugo.nl/vdirsyncer/v2.0.0-beta0/vstorag...

Source: https://git.sr.ht/~whynothugo/vdirsyncer-rs/tree/v2.0.0-beta...

virtualritz• 2 years ago

https://mirror.whynothugo.nl/vdirsyncer/v2.0.0-beta0/vstorag...

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...

mrweasel5• 2 years ago

The use of ' as a symbol that has any meaning on it's own has got to be one of the most stupid choices I've seen in a language. It's made worse by the fact that you can still use '...' as s character literal.

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.

the_mitsuhiko3• 2 years ago

It's worth pointing out here for people not familiar with Rust, that this is the result of code generation by a third party crate to enable async methods on traits.

iknowstuff3• 2 years ago

or just

    async fn list_items(&self, colletion_href: &str) -> Result<Vec<ItemRef>, Error>

nazka• 2 years ago

That's why I am a huge fan of Rust but at the same time at the end of the day all I want is the features of the language that Rust has minus the memory management and a GC. That would be my dream language. If only ReasonML/Rescript were more popular... Or I guess Elixir

sedatk3• 2 years ago

check out Google’s Carbon :)

coryfklein• 2 years ago

Scala

neonsunset2• 2 years ago

It's not necessarily identical to what you are looking for per se but a mix of C# and F# will be the closest overall to Rust in terms of performance, access to systems programming features, language expressiveness and tooling experience.

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.

AxelLuktarGott• 2 years ago

Is it really better to remove the error case information from the type signature? Aren't we losing vital information here?

treyd2• 2 years ago

The std::io error type is defined roughly as:

    type Result<T> = std::result::Result<T, io::Error>;

So it's actually fine, since we're specifying it's an IO result. This is a fairly common pattern.

eterps• 2 years ago

Just give me Rattlesnake or CrabML and I'll stop complaining :-)

awesomebytes2• 2 years ago

stavros2• 2 years ago

What's Rattlesnake? I can't find anything at all online.

frankie_t2• 2 years ago

I think he's referring to Python, just like other made up names probably refer to Java, Js, C++ and OCaml.

frankie_t2• 2 years ago

Wanted to say the same. He straight up conjured a good looking code in CrabML as an example of similar level of "ugliness", while it has about three times less syntax noise.

hyperpape• 2 years ago

It ends in ";;". If that's not a typo, and it's semantically significant that there are two semicolons instead of one, that sounds quite finicky.

baq• 2 years ago

Choked on my coffee when I got to Rattlesnake. Great name.

oguz-ismail• 2 years ago

The final version is still ugly. Why `pub fn'? Why is public not the default and why do you have to specify that it's a function? Why `: type' and `-> type', why can't type go before the identifier? Why do you need `File::' and `Bytes::'? What is that question mark? Why does the last statement not need a semicolon? It's like the opposite of everything people are used to.

atoav2• 2 years ago

As someone who doesn't think it is pretty, but knows Rust I went through all your points and let me assure you except for the one where you wonder why the syntax can't be more like C/C++ where it comes down to taste, all of your questions have an answer that really makes sense if you understand the language.

E.g. making pub default is precisely the decision a language would make that values concise code over what the code actually does.

janalsncm• 2 years ago

Definitely agree, “pub” was one of the design decisions I loved learning Rust. If you forget to add it, you’ll get a compiler error. But if pub was default, I’d be exposing code unnecessarily. And no need for a separate private keyword, the absence of pub is sufficient.

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.

pta2002• 2 years ago

Short answer for the type ordering and `fn`: because C/C++/Java tried that type of syntax and the result was an ambiguous grammar that is way too hard to parse, not to mention C's overly complicated pointer syntax.

uasi• 2 years ago

Your points have nothing to do with ugliness.

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.

mFixman• 2 years ago

If public were the default, you'd end up having to make other functions `priv fn` instead.

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.

kelnos3• 2 years ago

Why `pub fn'?

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...

mjburgess2• 2 years ago

Kinda disingenuous, you don't reskin one language in another to make an argument about syntax -- you develop a clear syntax for a given semantics. That's what rust did not do -- it copied c++/java-ish, and that style did not support the weight.

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())

tcfhgj4• 2 years ago

To me this example is not more clear than normal Rust

mjburgess2• 2 years ago

If you've programmed a lot in Rust, then that's a win -- since its "not more clear", and yet, you've no experience in this syntax.

timeon• 2 years ago

Now there are too many colons.

bvrmn2• 2 years ago

Original code contains more. (::). Personally I don't understand why there are `::` and `.` to access deeper namespace levels. It's a static language, compiler should know how to resolve attributes and `.` should be enough for all cases.

demurgos• 2 years ago

People may disagree on specifics, but you're definitely right that being able to separate the function signature from its definition would be very helpful in complex cases.

scotty792• 2 years ago

Why? You can easily find parameter names in the signature if you just put them on separate lines. For me there's very little reason of putting them all together on separate line after the signature. And then when you look for a type of a parameter you know the name of, it gets difficult.

degurechaff• 2 years ago

Rust target user is C/C++ developer. not using brace is out of options.

xigoi• 2 years ago

Do you think C++ programmers are incapable of learning a language without braces?

blksv2• 2 years ago

I strongly support your point, but the example is still sand-in-the-eyes for me. I hold that one symbol should not alter the semantics of a program and there should never ever be sequences of one-symbol syntactic elements.

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;

mst2• 2 years ago

Huh. My brain says logically I should find that better, but the -lack- of punctuation is making it really tricky to skim read the way I do most languages.

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.

kelnos3• 2 years ago

Rust does allow you to split out generic specifications into a separate "declaration block" so things don't get too busy. Like you could write the original Rust code as:

    pub fn read<P>(path: P) -> io::Result<Vec<u8>>
    where
        P: AsRef<Path>,
    {
        // ...
    }

Personally I don't find your example with the type signature completely separate to be easier to read. Having to look in more than one place doesn't really make sense to me.

Funny, though, Rust's 'where' syntax sorta vaguely superficially reminds me of K&R pre-ANSI C:

    unsigned char *read(path)
        const char *path;
    {
        /* ... */
    }

_answ2• 2 years ago

I have a feeling that most of the clarity you find in your example comes from better use of whitespace. Consider:

    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())
    }

Plus, your example does not have the same semantics as the Rust code. You omitted generics entirely, so it would be ambiguous if you want monomorphization or dynamic dispatch. Your `bytes` and `file` variables aren't declared mutable. The `try` operator is suddenly a statement, which precludes things like `foo()?.bar()?.baz()?` (somewhat normal with `Option`/`Error`). And you weirdly turned a perfectly clear `&mut` into a cryptic `&!`.

Please don't assume that the syntax of Rust has been given no thought.

remcob2• 2 years ago

Why stop there and not go all the way to

    pub fn read(path: Path) -> Bytes {
      File::open(path).read_to_end()
    }

oneshtein• 2 years ago

How to return an error in your example?

tcfhgj4• 2 years ago

Throw an exception

proving the point of the article even further

gary_0• 2 years ago

    pub fn read(path: Path) -> Result<Bytes> {
      File::open(path)?.read_to_end()
    }

isn't so bad either.

MetricExpansion• 2 years ago

If I understood all the semantic properties, including the separate compilation requirements, correctly, here’s how I think it would be done in Swift with the proposed nonescapable types features (needed to safely express the AsRef concept here). (Note that this doesn’t quite compile today and the syntax for nonescaping types is still a proposal.)

  @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")
      }
  }

wiz21c• 2 years ago

For my own situation, the articles present the right way to express all possible performance/error handling (which is expected in a standard lib) and then goes on to show how I actually code it in my own softawre where I don't really need the level of detail/finetuning of the standard lib.

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...

awesomebytes2• 2 years ago

I've only learned a tiny bit of Rust, and I feel the same. Going from the bottom up, makes it all make so much sense. (Albeit I still like the Rattlesnake syntax haha)

macmac• 2 years ago

My hot take is that Rust should have been a Lisp. Then it could also have had readable macros.

kzrdude• 2 years ago

What if Rust was an OCaml-ish.

jiwangcdi3• 2 years ago

The next noisy element is the <P: AsRef<Path>> constraint. It is needed because Rust loves exposing physical layout of bytes in memory as an interface, specifically for cases where that brings performance. In particular, the meaning of Path is not that it is some abstract representation of a file path, but that it is just literally a bunch of contiguous bytes in memory.

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.

K0nserv3• 2 years ago

Rust needs to know the exact size, layout, and alignment of every argument passed to a function to determine how it gets passed(register(s) or spilled to stack) and used. For example PathBuf and String can both be turned into a reference to a Path, and while they have the same size their layout and implementation of `as_ref` differ.

As for `impl`,

    fn foo(a: impl ToString)

is syntactic sugar for

    fn foo<S: ToString>(a: S)

The reason the standard library doesn't use this is because the code predates the introduction of `impl` in argument position.

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.

jiwangcdi3• 2 years ago

Then if Path is not about abstraction, why not use a raw byte slice like &[u8]

anonymous2024• 2 years ago

I wonder. How does Rust syntax compares with https://www.hylo-lang.org/ syntax? That also is memory safe, typesafe, and data-race-free.

mgaunard• 2 years ago

There are several problems with the C++ variant, which could have been easily avoided by just following the original Rust more closely.

apatheticonion2• 2 years ago

Someone needs to tell them about async Rust. Big yikes.

carlmr2• 2 years ago

I'm a big Rust fan, but async Rust is an abomination.

iknowstuff3• 2 years ago

I love async Rust. Its implementation is marvelous. Sueper plasant to write now that

* async closures

* async trait fns,

* `impl Trait` everywhere

are in place.

Woshiwuja3• 2 years ago

So you just end up with python at the end?

qalmakka2• 2 years ago

People that complain about Rust's syntax never have never seen C++ at its worst

olologin• 2 years ago

C++ is relatively easy to read. The only troubles I had is reading STL's sources because of all _ and __ prefixes, and understanding template errors from compiler, but that will soon be fixed with concepts.

qalmakka2• 2 years ago

C++ is relatively easy to read

Only 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.

tmtvl• 2 years ago

Aw, no Rasp variant? Let's brainstorm it up...

  (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))))

tevelee• 2 years ago

The article just turned Rust into Swift. Nicer syntax, same semantics

singularity2001• 2 years ago

   "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."

You think wrong. Rust syntax is horrible because it is verbose and full of sigils

Woshiwuja3• 2 years ago

Still trying to understand when i have to put ||

nequo2• 2 years ago

Is it harder to understand than when to put lambda: in Python code?

librasteve2• 2 years ago

Here's the cleaned up version of Rust from the OP:

  pub fn read(path: Path) -> Bytes {
    let file = File::open(path);
    let bytes = Bytes::new();
    file.read_to_end(bytes);
    bytes
  }

Here is is in raku (https://raku.org):

  sub read(Str:D $path --> Buf:D) {
    $path.IO.slurp: :bin
  }

[the `--> Buf:D` is the raku alternative to monads]

sedatk3• 2 years ago

Then it’s just this with C#:

  public byte[] Read(string path) => File.ReadAllBytes(path);

I think the article’s trying to explain a concept using an arbitrary piece of code from stdlib, not necessarily that specific scenario (opening and reading all bytes from a file).

neonsunset2• 2 years ago

This. In general, standard library is a poor example as it has to serve very wide range of scenarios, be robust to many environmental conditions when IO is involved and perform optimally. If it's terse enough while doing so, it's good enough already.

librasteve2• 2 years ago

well no need for the sub wrapper really

  say $path.IO.slurp: :bin

Rust's Ugly Syntax (2023)

Related Stories