Hacker News Reader

Comment by pcwalton | Hacker News Reader

> But the object system (yeah, they're called structures and traits) is too weird.

So you praise Go for having structures and interfaces, but you criticize Rust for having structures and interfaces because that's "too weird".

> The enum approach to variant records is too weird.

Why? Because of the keyword? Swift uses that keyword too!

> The error handling is too weird.

What would you rather see?

> The half-functional style is too weird.

I can't think of any way that Rust differs in this regard from, say, Ruby. Or JavaScript.

> The widespread use of closures for simple stuff is too weird.

Again, it doesn't differ from Ruby. (Actually, Rust uses closures/blocks quite a bit less than Ruby does, because of the pull-style iterators...)

> There's too much unnecessary originality.

Such as? None of the features you've mentioned are at all original.

View on HN

Your comment doesn't seem like a helpful way to advocate for Rust. It's a critique of the comment but doesn't address the commenter's concerns.

Because "addressing" the concerns would make Rust a worse language.

1. Removing structs and interfaces (in favor of what? Java-style classes and interfaces?) would make Rust more verbose, less of a systems language, and slower at runtime due to the indirect dispatch.

2. Changing the keyword "enum" to something else is a cosmetic change which would make as many users unhappy as it made happy. (We know, because we solicited feedback on the keyword before selecting it!)

3. I've addressed error handling in the sibling comment. There's basically no other way to do it that would be in line with Rust's goals as a systems language.

4. Rust would be a worse language if it lacked closures. Closure support is a basic feature in a modern language.

I didn't suggest changing the Rust language. There are other ways to address concerns than by saying "you're wrong," which is effectively what your comment did.

Unless the person actually happens to be... you know wrong... Which does happens sometime.

Nothing wrong with pointing out that someone's logic is wrong. It is true that the only way to address these 'concerns' is to change Rust into something that it is not. Rust without closures, structures, traits, pattern matching, and algebraic data types would not be Rust, it would be C. We don't want C.

Nitpick : > 1. Removing structs and interfaces (in favor of what? Java-style classes and interfaces?) would make Rust more verbose, less of a systems language, and slower at runtime due to the indirect dispatch. Classes and interface can be implemented without indirect dispatch...

Only if you monomorphize interfaces—which gives you Rust's traits.

No. THe fundamental difference is that rust traits cannot convey structural information , classes (java and c++ can)

There's an open (and desired) RFC for this. It's not likely to happen soon since it's not a super high priority, but I'd be willing to bet it gets merged in the future.

Fair enough, as long as we agree that classes/struct in C++/java a quite a different beast than just monomorphic traits.

Absolutely, you're totally right with regards to today.

If Rust doesn't differ from Go, from Swift, from Ruby, from JavaScript in these regards then perhaps, as was pointed earlier, Rust didn't know when to stop. It seems to violate the Law of Parsimony. I like Rust's borrow checker and that's pretty much it.

Sometimes I think CRust would be a good idea, the minimal ideas that I like from Rust just layered on top of C as a linter.

> If Rust doesn't differ from Go, from Swift, from Ruby, from JavaScript in these regards then perhaps, as was pointed earlier, Rust didn't know when to stop. It seems to violate the Law of Parsimony.

The point is that these ideas are not "weird"—they're just decisions taken straight from other languages.

I can't believe we have to defend closures, of all things, from the charge of being "weird" because a language from the 1970s didn't have them, but here we are.

> Sometimes I think CRust would be a good idea, the minimal ideas that I like from Rust just layered on top of C as a linter.

That is not possible. You can't just graft the borrow check from one language onto another language that was not designed for it. For example, C doesn't even have generics, and the lifetime system is designed around generics.

Honestly, I'm tired of responding over and over to the suggestion that we should have done Rust as a static analysis on C++. If you actually try to design such a system, it becomes obvious very quickly that it cannot work for systematic reasons.

  Rust is a systems programming language that runs blazingly fast,
  prevents segfaults, and guarantees thread safety.

In a systems programming language I can do without closures, without generics, without .... I would and will say the exact same thing about Swift which also provides closures, generics, ....

Us systems programmer types, we tend to drag our knuckles a lot. Still we do have opposable thumbs for grasping tools and we're damned proud of that. Perhaps if and when we sufficiently evolve and attain an upright, high level posture we'll see the light. But for now, be happy that we're trainable if not educable.

Now please excuse me, but I have to go pick some low hanging fruit. That and worse is a lot better.

I don't think the current state of systems programming is something to be proud of.

>> The error handling is too weird.

>What would you rather see? Exceptions

We would lose lots of users from C and C++ if we mandated exceptions for error handling. The code size and complexity of unwinding is too much of a price for many to pay.

Not mandate them , use have them as an options where the monadic Errors types are not enough or are too cumbersome to use.

And thereby prevent people from writing code that needs to catch errors but can't use exceptions. Won't work.

I don't understand what that sentence means...

Some people don't want to use exceptions because of runtime overhead costs.

If exceptions are just "an option" that a library can choose when designing its interface, then you'll get a split ecosystem: a bunch of libraries that do use exceptions for error-handling, and then a separate bunch of libraries that do the same thing, but don't use exceptions for error handling, which is wasted, redundant effort.

> then you'll get a split ecosystem

Agreed. Point in case: Have a look at D and the discussions about their GC.

I haven't kept up much about the last year, but my general impression runs down to: If you want to use their standard library. There's gonna be garbage collection. Period. If you want to avoid it, enjoy implementing its functionality all by yourself.

With rust and exceptions you would likely not have a problem with the main ecosystem, but the same problem is bound to pop up with some big & famous library.

Edit: Similarly, exceptions are one of the reasons C++'s SG14 exists.

Rust is already paying the cost of unwinding. RFC 1236 added unwinding machinery for catching panics.[1] ("A drawback of this RFC is that it can water down Rust's error handling story.") This is the expensive part of exception handling. Rust has exceptions, but they're not very good.

Go also backed into adding most of the machinery for exceptions by adding catch with unwind for panics. If you're going to have the unwinding machinery, why not have real exceptions?

Exceptions aren't so bad if you do them the way Python does, using a predefined exception hierarchy. Catching an exception catches everything in its subtree. Catching RuntimeError catches most of the things one can induce from outside the program. Python's WITH statement also has one of the few mechanisms which can gracefully handle an error on releasing a resource. Exceptions in C++, Java, and Javascript are more troublesome.

[1] https://github.com/rust-lang/rfcs/blob/master/text/1236-stab...

You have talked about Python's exception scheme before, and been rebuffed before (it is too dynamic to use pervasively in a systems language), please be more specific, and also have the minimum grace to not repeat incorrect things.

In any case, panics are not guaranteed to unwind or be catchable: they can be turned into aborts (yes, on the stable compiler). This means an arbitrary library using them for recoverable error handling is incorrect.

What dynamism? An exception hierarchy just requires a type hierarchy, and Rust has enough inheritance for that. Rust has some dynamic dispatch, although it's not clear if the mechanism for trait objects [1] can implement an exception hierarchy cleanly.

A WITH clause mechanism implies no dynamism.

Please be more specific with your complaints. Thanks.

[1] https://doc.rust-lang.org/book/trait-objects.html

Firstly, "just" determining membership of a value within a type hierarchy requires far more dynamism than zero. Given a fairly arbitrary type-erased value x, how do you tell if its type implements some fairly arbitrary trait T? This hierarchy presumably has to be open, which makes the problem harder.

Additionally, unless one is using explicitly typed exceptions (i.e. Java-style checked exceptions, very much unlike Python), it requires allocations, as it's not possible to statically determine the size of the error object to be returned.

Similarly, from an assurance/reliability point of view, the dynamically typed nature of non-checked exceptions is unfortunate.

(These second two are, I believe, the points I made last time we discussed Python's exceptions.)

Having to allocate memory while processing an exception probably isn't a big deal, since Rust does not claim to be able to operate in an out-of-memory condition. Besides, unwinding already causes allocation:

"We'll also need a way to handle out-of-memory (OOM) conditions. The standard library calls the abort intrinsic, which just calls an illegal instruction to crash the whole program. The reason we abort and don't panic is because unwinding can cause allocations to happen, and that seems like a bad thing to do when your allocator just came back with "hey I don't have any more memory"."[1]

[1] https://doc.rust-lang.org/nomicon/vec-alloc.html

> Having to allocate memory while processing an exception probably isn't a big deal, since Rust does not claim to be able to operate in an out-of-memory condition

Allocating is definitely a big deal for a pervasive error handling! For instance, parsing a number might not succeed. Both the actual parsing and the failure cases are cheap, but not if the latter has to be indicated by allocating and unwinding and doing a pile of the dynamic checks up the stack.

Additionally, whether the language is able to operate in OOM isn't the only reason to choose an error handling scheme. However, even if it was, I don't think it applies directly to Rust: Rust-the-language (and Rust-the-core-library) can operate in an OOM condition, e.g. people run Rust code without needing a dynamic allocator at all. You are correct that some parts of the standard library don't handle OOM, but, using exceptions pervasively means that there is one error handling scheme for things that can rely on having an OS/malloc and one for things that don't need them.

> Besides, unwinding already causes allocation

Yes, and that is one reason why unwinding is not used as a pervasive error handling scheme in Rust: there are various fairly fundamental problems with it. It is one of the reasons why panics can be switched to abort.

> Allocating is definitely a big deal for a pervasive error handling!

Exceptions are not meant for "pervasive error", they are for exceptional execution paths. If an execution path is frequent enough, wether it's an "error" or not, then it should not be an exception.

I think this is the part of the argument that the "no exception camp" usually misses : there are multi type of errors (recoverable vs fatal, frequent vs unfrequent, expected vs unexpected), having exception is not about using exceptions for all of them

To be fair to the "no exception" camp, they do see that there are multiple kinds of errors: they partition them into recoverable errors and unrecoverable errors.

And yet the bulk of this thread was in reference to python where exceptions are the pervasive scheme.

As the sibling points out, this is in the context of the suggestion of using Python's approach, where exceptions are not just pervasive, they are so pervasive they're used for non-errors/control flow (e.g. StopIteration).

There's also Swift's approach, which looks like exceptions but is really similar to Rust's approach under the hood. Swift also requires failable calls to be prefixed by "try" which makes them even easier to spot than the postfix "?" that Rust uses.

Just curious, have you ever used any other modern languages that do not use exceptions for error handling? Most people who complain are just used to the exception way, but once you embrace returning errors out of functions, it really does feel like a massive improvement in terms of the paradigm.

How do you return failure for a bus error in Rust?

You can use signal handlers if you need to, but it's not like there's a good way to handle most bus errors in userspace to begin with. Anyway neither standard C nor standard C++ even spec out interrupt handling, and SIGBUS isn't a standard signal :P

A signal handler (signal!(sig::ffi::Sig::BUS, test_bus);) will catch the bus error in userspace. You now need to communicate that caught exception to the offending fn. For that, you'll need setjmp() and longjmp(), something else that Rust lacks.

If Rust is going to bill itself as a systems programming language, it needs these. I added them for my app:

  extern {
    #[link_name = "llvm.setjmp"]
    pub fn setjmp(a: *mut i8) -> i32;
    #[link_name = "llvm.longjmp"]
    pub fn longjmp(a: *mut i8, b: i32) -> ();
  }

It took me awhile to figure this out (and it barely works). There's a cleaner way (adding a wrapper) that is even more work.

> A signal handler will catch the bus error in userspace.

Sure, but what I meant is that most of the time userspace programs have nothing interesting they can do with the bus error (and, as I noted, standard C does not actually provide this option anyway). Regardless there are existing signal handling libraries that aren't that hard to use in Rust (you now describe one in your post), so I'm not sure why you're pointing to that as "something... that Rust lacks."

There's no way I'm aware of that setjmp / longjmp could possibly be integrated with safe Rust, but I agree that they should be available to unsafe code (in a way that doesn't require invoking llvm intrinsics).

Whenever I see "systems programming language" in the context of Rust advocacy I've basically begun mentally substituting "programming at the applications/systems grey-area border". There's a lot of ambiguity about what "systems programming" really means, so I wouldn't say they're not using it correctly, but I've been getting the impression that your brand of systems programming isn't what they're targeting.

And that's okay. There is a ton of space outside of that context, and still within the "systems" space that C and C++ could use a high quality competitor in, and Rust fits that bill nicely, in my view.

Rust is targeting all meanings of the word "systems programming". If you need some feature that Rust doesn't have, file an issue or write an RFC.

I think you have some point (especially for the definition of "systems programming"), but in my perspective Rust has a possibility [1] to encompass the largest possible meaning for systems programming. Here's why:

Rust the language is really composed of two almost identical subsets, "safe" one and "unsafe". Safe Rust is what you will normally see, governed by normal safety rules and abstractions. Unsafe Rust is not what you will normally see, but still governed by safety rules and abstractions, only with an escape hatch. What I feel is that safe Rust covers the higher-level subset of "systems programming" (predictable performance, strong abstraction and safety), while unsafe Rust covers the lower-level subset of "systems programming" (excellent performance, near-complete control over everything). And still they are almost identical, so that the abstraction made in unsafe Rust is usable in safe Rust, and that's ideally how it covers the entirety of "systems programming"---the only border is the abstraction itself. Of course, provided that we have enough supply for appropriate abstractions (the community is trying hard with several promising results though).

Rust programmers do like the safety guarantee of safe Rust and rarely talk about unsafe Rust, but I think unsafe Rust plays a large role in the possibility of Rust. It's much closer than the border between, say, "glue" languages and their implementation languages. We don't change the fact that we will sometimes have to bend the rules (it's probably impossible). Instead we let you bend the rules, but only when you are in the cage. And that cage is, while not immunable to every attack, really strong.

[1] The advocacy naturally advocates for something's possibility and not for something's success. So it is still correct that Rust still lacks some solutions for existing problems, though it's not inherent.

> Rust programmers do like the safety guarantee of safe Rust and rarely talk about unsafe Rust

I think that's a misunderstanding of meaning. Rust's safety and unsafe are intrinsically linked. It's not that Rust is always safe, but that you have a well defined way to compartmentalize safe and unsafe portions of the program, and can use that to reason better about what's going on. In a way, talking about the safety of Rust is specifically talking about unsafe.

Haskell is the last language i used without exceptions

Haskell has exceptions. So does Rust. People just prefer to use Either / Result (with good reason).

Exception in Haskell ?

Yeah. Try grabbing the head of an empty list, for instance. People for the most part don't like exceptions in Haskell, but that's not the same as the language not having them.

The `error` function is approximately `throw`.

Catchable with: https://hackage.haskell.org/package/base-4.9.1.0/docs/Contro...

I work on several languages professionally being the only one without exceptions Go and I don't see how its idiotic pattern of checking the value returned after every single call is a massive improvement on anything except masochism.

I dislike Go's error handling too. Rust solved this neatly with question mark operator (previously implemented as try!() macro).

Go's "error" system is nothing like Rusts. I personally find Go's terrible and boilerplate-y.

Rust's uses algebraic types to make things checked at compile time and uses operators like `?` to give you expressiveness while removing the overhead and annoyance of manually checking everything. It is a huge improvement.

I would be downright appalled if Rust were to start promoting exceptions. It's an anti-feature.

Being this emotionally invested in a feature, really is unprofessional...

Using exceptions would be unprofessional. If someone were to use exceptions, then all of my carefully crafted error-handling routines would go up in flames because someone's library decided not to use an algebraic data type for conveying error messages across boundaries. It's bad enough that C libraries can suffer catastrophic failures bringing the entire stack down. I want a consistent error-handling strategy, and pattern matching is the best method of clearly displaying intents and possible downfalls.

> Using exceptions would be unprofessional. Unless it happens to be the best tools for the particular scenario...

> then all of my carefully crafted error-handling routines would go up in flames

No just sandbox the code inside a try catch...

> pattern matching is the best method of clearly displaying intents and possible downfalls.

You are stating an opinions as a fact here.

You are basically stating that we should be doing both try/catch AND result/option at the same time, everywhere. That would get annoying fast.

> No just sandbox the code inside a try catch...

This works fine if it's just a matter of rolling back a database transaction or releasing file handles (b/c someone else is doing all the work for you). But if you have more complicated invariants, your try catch has to handle restoring those invariants, no matter what path your code took.

I'd recommend taking a look at Common Lisps condition system, which does exceptions right.

The most important feature is that catch blocks are executed before the stack is unwond, providing the ability for a handler to signal back to the context where the error occurred how it should be handled.

It's sad that no other languages implement this and instead simply decide that exceptions are bad.

Fun trivia: Rust had conditions! Nobody used them, so they were removed.

That sounds short-sighted to me. Even in Lisp restarts (i.e. the feature that allows a handler to communicate back to the point where the exception was thrown) aren't used that often, but when they are, they are incredibly valuable.

In TXR Lisp, a continuable exception occurs every time you see a warning about something in the code, like an unbound variable. It is intercepted higher up and automatically continued.

The code expander has an entry point which allows the caller to be informed about what variables and functions are free in a block of code. The implementation of this entry point works by intercepting warning exceptions about unbound symbols, and accumulating them in in lists, which are then returned to the caller.

This is a useful thing which reduces the need for users to write their own code walker in certain kinds of advanced macros.

Perl 6 does[1], referenced directly from CLOS (from which a lot of other stuff was cribbed from as well).

1: https://docs.perl6.org/language/exceptions

Many people sooner or later have to spend an evening/night debugging serious issue affecting critical production system, discovering that system is left in inconsistent state after some corner case is throwing an exception that the code between it and the catch block didn't anticipate/handle correctly. And then they become emotionally invested.

> code between it and the catch block didn't anticipate/handle correctly

This sounds like a general errors handling issue that nor exceptions nor monadic errors types can prevent.

No language can fix mistakes, but in Rust if you have a() calling b() which calls c(), there is no way* that c can jump to a without any indication of it in b. You at least need to have `?` somewhere in b. I consider it a really good thing, among other advantages.

* panic + catch_unwind, but that's special and not meant or used in practice for error handling

Rust requires at compile-time that you handle each case.

I'd even prefer the golang way of error handling by `if err!= nil` over exceptions, treating errors as values is so much better

Hyperbole is lost on you, it seems.

I prefer to think of the difference being "In classical inheritance, verbs are members of nouns, but, in Rust, you define your nouns and verbs as distinct top-level identities, then define the valid relationships between them."

Thinking about it in that sense, classical inheritance has always been based on a fundamentally flawed abstract model.

(Admittedly, purely noun-to-noun inheritance does have its place in a well-structured abstract model, in cases like "every Teacher is a Person", but I stand by Rust's decision to omit it... at least in the near term, because developers are too used to overusing/abusing it out of habit.)

> I can't think of any way that Rust differs in this regard from, say, Ruby. Or JavaScript.

"Everything is an expression" is pretty different. You can say ML/Lisp, but those are non-top-10 languages/styles.

> > I can't think of any way that Rust differs in this regard from, say, Ruby. Or JavaScript.

> "Everything is an expression" is pretty different.

No, in Ruby, everything is also an expression; this is sometimes unrecognized because some constructs that are cognates to constructs that are statements in other languages are frequently (but inaccurately) referred to as statements in Ruby (the most frequent example I've seen is "case statements").

Eh you got me. I still think it's pretty surprising (especially for systems languages), but OK :)

Also Ruby is a kitchen sink language, so I don't know if we should be using it as the baseline for a language with a small surface area.

Reply on news.ycombinator.com