Hacker News Reader

Comment by haskman | Hacker News Reader

They didn't explore a Haskell (or PureScript) inspired syntax, but I think it could massively improve things without compromising on semantics. The separate function signature itself is a great improvement.

"Haskell flavored Rust" anyone?

    read
      :: forall p
      .  AsRef Path p
      => p
      -> Result (Vec u8)
    read path = inner (as_ref path)
      where
      inner :: &Path -> Result (Vec u8)
      inner path = do
        mut file <- File.open path
        let mut bytes = Vec.new
        read_to_end file (&mut bytes)
        pure bytes

View on HN

Of course, they did. The initial compiler was written in Ocaml.

Early Rust looked much more like a ML language. They intentionally moved to a C-like syntax because it is more familiar to their target audience.

I didn't mean the designers of Rust. I meant the author of the article did not consider a Haskell like syntax.

I completely understand the reasons for Rust devs targeting a C like syntax. Rust had already blown its novelty budget on the borrow checker semantics.

CrabML is a ML-like syntax which is very close to the Miranda-based syntax Haskell uses.

I guess they didn’t explore a Haskell (or a Lisp, Prolog (which always surprises me by looking so clean that you don’t think anything can be going on), Python, Pascal etc) style because it scares c/c++ programmers generally. And then they would have to fight harder for adoption than they had to now.

Personally I think many styles, like the Haskell-y you show here, would be far more pleasing on the eye; luckily we live in a time where it is not too hard to create either a different compiler frontend, or, easier, a translator (transpiler, but I don’t like the word as it only translates, hence it takes too much credit being called transpiler).

Yup, this could and should be a separate preprocessor step. Changing the syntax of the Rust language itself so drastically would be nearly impossible at this stage.

While this is true, we are still in a time when seeking adoption for this newly made syntax is much harder.

It looks better, but hard to comprehend without looking into the original code. E.g. this line:

    inner path = do

Generally speaking, improved syntax would have been great, but similar projects that existed 10-15 years ago failed to be adopted widely (CoffeeScript, HAML).

Why is that hard to comprehend? `do` starts a new block with sequencing semantics (so we don't need the `?` operators) in Haskell.

CoffeeScript can actually be considered very successful, since it influenced the design of a lot of other language features we take for granted. Same can be said for HAML.

It's similar to what you can do in Julia, but there you use this syntax only for one-liner functions. The problem with this function declaration is that you need read up to the '= do' combo in order to understand that you're in a function definition. A keyword in the beginning would make it much easier.

I'd love to hear what features CoffeeScript made appear in other languages. JS did not take the syntax at all. I guess it's hard to tell whether generators and var-args came from CS or Python.

Off the top of my head Coffeescript introduced the function arrow syntax to JS, as well as class based inheritence.

Also you don't need to take my word for it, Brendan Eich, the creator of JS himself has said that CoffeeScript had a significant impact on his thoughts about the future of JavaScript (https://brendaneich.com/2011/05/my-jsconf-us-presentation/).

I was actually thinking of working on something like this as a side-project in case I was laid off...

I've been thinking about something like this for a while too. Happy to collaborate!

Reply on news.ycombinator.com