Hacker News Reader

> The question mark operator is unrelated to async - you might say "fallible functions" instead.

This jumped out at me too and I think it would be better stated as “this function doesn’t handle this error” or “this function may produce this error”, which is basically checked exceptions ~without error handling as arbitrary control flow.

> Not really a class. There isn't a good parallel to this in most other languages.

It’s a lot more like a class than the next most obvious TypeScript idiom (structural type compatibility/duck typing). It has to be explicitly defined and that’s the most important part coming from a JS/TS background.

I agree with and fully endorse the rest of this comment.

> which is basically checked exceptions ~without error handling as arbitrary control flow.

With the `?` operator, Rust behaves identically to a language with checked exceptions as it also has "arbitrary control flow" in that the code may "jump" elsewhere on errors. The implementation may be different, but the abstraction is identical.

The places it may jump are explicitly marked in the code, though. And that makes a tremendous difference in readability. The problem with exceptions is not the alternative control flow, but the fact it is hidden, and an exception can come out of nowhere, from 10 layers below (that's particularly bad for unchecked where you can't see them even in signatures).

You responded while I was typing but your response is much better.

I really don’t think it is that much of a problem. You almost always want a high-level error handling logic, and not all errors can or should be handled at callsite. Rust’s ? macro is a good tradeoff, but I really do think that exceptions are the best way of error handling — optionally marking a given exception type as “should be handled” aka checked exceptions. Though existing implementations are not without errors.

I genuinely don’t think this is right! The syntax is equivalent to try->catch->throw or whatever but it doesn’t change the fact that the function has a clear either/Result type. Every call site gets the same return and has the same error semantics whether that syntax is used or an explicit return statement/expression is used. ? just means it’s a potential early return. Not a goto.

I don't know rust, so pardon my lack of knowledge. But given a quick look, can't "traits" be seen just like "typeclasses" in haskell?

Btw, I feel like I should learn rust now.

They are exactly typeclasses.

Yes, Rust traits are Haskell typeclasses. What he's saying has no parallel in most other languages are the `impl` blocks (which can be used to both define arbitrary methods and implement traits, the latter being directly analogous to Haskell's `instance` definitions).

Not just methods, impl defines all associated functions for a type, and Rust automatically allows you to call any associated function as a method if its first argument is some form of "self".

If you've got a Cat named puss, the call puss.meow() is effectively shorthand for something like Cat::meow(&puss) where that first parameter was the &self parameter to your "method".

Because this is namespaced, there's no problem if your Cat type has this meow() method and a Trait (say, AnimalNoises) it implements also has a meow() function, Rust knows those are different functions and the confusion only arises for a human reader, and only in code that actually wants to call one of the two identically named functions.

AnimalNoises::meow(&puss) and Cat::meow(&puss) are distinct, but writing thing.meow() requires inspecting other nearby code to discover whether from context this code knows thing is a Cat or just wants to make AnimalNoises. Where this might be confusing you should write AnimalNoises::meow(&thing) to make your intention clear to humans, and have it checked by the compiler.

Only the type's author gets to implement it, and only once (the standard library and especially core are special) so there's an essential distinction between SomeType::function() which was necessarily provided by the SomeType author, and just third party code that works with this type.

There can be additional differences in call syntax due to Deref support, which can delegate methods from a "child" to a "parent" type. For example, if we have puss: Rc<Cat> then puss.clone(); will implicitly call Cat::clone and return a new owned Cat (which can add overhead and is not zero cost) , whilst Rc::clone(puss) will simply create a new Rc reference to the same Cat object.

> For example, if we have puss: Rc<Cat> then puss.clone(); will implicitly call Cat::clone

[Edited, this used to suggest it's a typo, but probably it's just a different way to think about what's happening, so I removed this claim]. There almost certainly isn't a Cat::clone and in fact what's happening is that Clone is in the prelude, so this is:

Clone::clone(&puss)

[edited to add]

Which is really even:

<Cat as Clone>::clone(&puss)

and because Rc is a Smart Pointer it implements DeRef and so that's ultimately:

<Cat as Clone>::clone(<Rc as Deref>::deref(&puss))

Definitely understandable that people want to write puss.clone() instead.

By the way, misfortunate::Multiplicity demonstrates Deref and DerefMut nicely, providing a type which has two things inside it but references to it act like one thing when being mutated and like the other when merely referenced...

Not something for absolute beginners, but worth seeing to build correct intuitions (and to underscore Rust's admonition not to implement Deref and DerefMut if you aren't a smart pointer -- misfortunate is like Jackass, this is for entertainment and not to be attempted in your real Rust projects).

Extensions in swift feel mostly the same to me, except you can define them on any type you want and not just types or traits your namespace defines

You are correct. I know nothing about how Rust was actually developed, but I'd bet a lot of money that its creators were very big into Haskell. In addition to traits/type classes, Rust has quasi-monads (the Try trait is a fraction of the functionality but ends up being 95% of the real world use IMO) and uses a weaker form of Hindley-Milner that, again, is good enough for 95% of inference. And of course it has sum types and a limited set if Haskell's pattern matching (with the @ syntax to boot).

It was actually much more heavily inspired by OCaml than Haskell early on. See this comment talking about it, which includes a quote from Graydon on the topic: https://news.ycombinator.com/item?id=24956301

But it’s true that much of the inspiration for Rust comes from functional languages, and the trait system is definitely inspired by Haskell.

Rust's traits are a limited version of Haskell's type classes. They are more limited in at least two ways:

1. Rust's traits are unary relations (i.e., predicates) on types, whereas Haskell's type classes support relations of arbitrary arity ("multi-parameter type classes").

2. Rust's traits do not support higher kinds, so you can't define many things which are considered pretty basic to Haskell programmers (Functor, Monad, etc.).

But despite these limitations, Rust's traits are still great and better than what 99% of other languages have.

You seem knowledgeable about Rust, is this article pointing in good directions to learn the language from a dev primarily coding in JS?

I've recently started learning Rust with very little experience in low level languages. Just go build something and read the Rust book: https://doc.rust-lang.org/book/title-page.html.

The trickiest thing is ownership and lifetimes, but that's not really something you can understand just by reading. You need to build an intuition for how ownership and lifetimes work.

My recommendation for people learning rust for years has been to read both the Rust Programming Language book and Programming Rust at the same time.

No. The article is terrible (sorry). The OP was probably generous with "some small corrections". Not only the article touches up on some minor details about the language (mostly syntax) but gets them wrong or with a mistake half the time. These details are hardly 10% of the journey into Rust.

The best place to start is still the Rust book: https://doc.rust-lang.org/book/ and then start coding with it. I'd also suggest you learn some C along the way, if you only have a JS background.

Do let me know the mistakes and I will fix them!

And agreed, the Rust book is excellent.

I did have experiences with C which made going into Rust that much easier. But for others that don't, wouldn't you think going straight to Rust would be easier than learning C on the side?

As someone only passingly familiar with Rust and coming from a JS/TS background I agree this article is not helpful. If you want to make the jump:

- if a good article would be useful to you, the best resource will almost definitely be The Rust Book which is just a really well organized and easily accessible website

- if you prefer just exploring, Rust and its ecosystem is a lot easier to just wander into and try stuff than JS; but it’s going to feel really strict and have unfamiliar rules even if you’re used to strict TS

- even if you bail out of either it’s worth the time, I guarantee you’ll learn something even if it doesn’t show its value right away

Thank you so much! I've corrected them on the article.