from Hacker News

Rust's Ugly Syntax (2023)

by nequo on 8/30/24, 4:15 AM with 165 comments

by sedatk on 8/30/24, 6:38 AM
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.
by wiz21c on 8/30/24, 7:20 AM
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...

by tmtvl on 8/30/24, 11:33 AM

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

by MetricExpansion on 8/30/24, 7:20 AM

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

by jiwangcdi on 8/30/24, 8:05 AM
> 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.
by eterps on 8/30/24, 6:44 AM
Just give me Rattlesnake or CrabML and I'll stop complaining :-)
by anonymous2024 on 8/30/24, 8:45 AM
I wonder. How does Rust syntax compares with https://www.hylo-lang.org/ syntax? That also is memory safe, typesafe, and data-race-free.

by librasteve on 8/30/24, 3:51 PM

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]

by qalmakka on 8/30/24, 10:26 AM
People that complain about Rust's syntax never have never seen C++ at its worst
by tevelee on 8/30/24, 1:06 PM
The article just turned Rust into Swift. Nicer syntax, same semantics
by apatheticonion on 8/30/24, 10:19 AM
Someone needs to tell them about async Rust. Big yikes.
by mgaunard on 8/30/24, 8:56 AM
There are several problems with the C++ variant, which could have been easily avoided by just following the original Rust more closely.
by AxelLuktarGott on 8/30/24, 6:39 AM
Is it really better to remove the error case information from the type signature? Aren't we losing vital information here?
by Woshiwuja on 8/30/24, 10:20 AM
So you just end up with python at the end?
by macmac on 8/30/24, 7:21 AM
My hot take is that Rust should have been a Lisp. Then it could also have had readable macros.
by mjburgess on 8/30/24, 7:00 AM
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())
```

by remcob on 8/30/24, 7:00 AM

Why stop there and not go all the way to

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

by singularity2001 on 8/30/24, 1:38 PM

   "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

by oguz-ismail on 8/30/24, 6:45 AM
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.