Hacker News Reader

Comment by Animats | Hacker News Reader

I had great hopes for Rust as the future of systems programming, but they've decreased over time. Parts of the language are just too cute.

The borrow checker was brilliant. Any future language that doesn't use garbage collection will have to have one. That was the big advance in Rust.

But the object system (yeah, they're called structures and traits) is too weird. The enum approach to variant records is too weird. The error handling is too weird. The half-functional style is too weird. The widespread use of closures for simple stuff is too weird. There's too much unnecessary originality. Trying to port something from another language to Rust is difficult because Rust's ways of doing things are so different from other languages.

I have the feeling that Rust is destined for a niche like Haskell - cool, but not mainstream. That's sad. I really thought early on that Rust meant the end of the decades of hell from the lack of memory safety in C and C++. But that's not happening.

The Go crowd knew when to stop. The Rust crowd didn't.

View on HN

This critique makes no sense to me. The composition-based object system mirrors Go's. enums aren't original (ML, anyone? 1970s tech?) or weird (every new language from this decade has them, including Swift, and C++ will have them by C++20). Error handling is literally Go's `if err` pattern but first-class (Swift's error handling is quite similar as well). And your disdain for closures has long been noted and I reiterate that your concerns are overblown.

If you don't like Rust, that's A-OK. If you can't quite put your finger on why you don't like Rust, that's fine too. But please don't pass off your vague concerns as substantive criticism.

It makes a lot of sense if you take that "weird" is about familiarity, not functionality.

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

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

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.

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.

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

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

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

Alternative view: the clean separation of data from API has a nice analogy to the manipulation of data in C, and a powerful way to maintain that separation while still allowing for powerful object oriented programming where appropriate.

> The enum approach to variant records is too weird.

I disagree. The tagged union is an oft-used pattern in C and C++ code. Maybe calling it "enum" is a bit off, but the concept is incredibly useful, and Rust's compile-time support for it is incredibly useful and powerful in my opinion.

> The error handling is too weird.

It's very C-like, but more strongly typed and, thanks to the Rust developers' efforts, quite clean. A C programmer, or a C++ programmer who sets the "no exceptions" flag as a matter of best practice should feel quite comfortable with Rust's error handling.

> The half-functional style is too weird. The widespread use of closures for simple stuff is too weird.

I would substitute "cute" for weird, but overall I don't mind it. I do agree that emphasis on making these features more prominent, especially at the expense of more explicit (e.g. explicit for-loop) constructs, might hinder traction.

> I do agree that emphasis on making these features more prominent, especially at the expense of more explicit (e.g. explicit for-loop) constructs, might hinder traction.

I thin kit depends on both where the new users are coming from, and how much they've modified their thinking to a specific programming style. If you are a C or C++ programmer and already think in conceptualized for loops when planning steps, then it seems odd. If you haven't gone that far into letting that style define your thoughts, or continued to use other languages that were a bit more functional, you might find that that conceptually it's easier to reason about.

I.e. "I'm going to transform each of these items by doing X, Y and Z and store them here" as a concept is neither directly a for loop nor a map a the basest level, but you might start thinking in maps or loops after a while if that's your only option.

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

It's equivalent to writing C++ with:

  * No structural inheritance (i.e. no inheritance of data)
  * Inheritance only from pure virtual interface classes 
  * MyCppPureVirtualClass * pointers in various interfaces

Except that traits are also usable for static dispatch as in templates/concepts.

This isn't the most common style of C++, but it's not uncommon either, and I happen to like it a lot; it's all over Cef's and Chromium's code, for example.

> The enum approach to variant records is too weird.

What's weird about it? It's just the same as e.g. Haskell, ML, but with a different (arguably slightly overloaded) keyword. Swift uses the same terminology.

> The error handling is too weird.

Eh. I certainly like the way that explicit error handling is "forced" on the caller with mechanisms like Result<T,E>::unwrap. But I agree that magical things like the question mark operator are a little too cute.

> There's too much unnecessary originality.

FWIW, I can't think of much real originality in Rust. It just brings together "exotic" features from lesser-known languages.

I can't think of much real originality in Rust. It just brings together "exotic" features from lesser-known languages.

I think you're right. Except for the borrow checker, which was a major breakthrough.

The borrow checker is Cyclone's region-based memory management combined with linear/affine types.

Edit: As an aside, I found a Reddit post the other day asserting that the Cyclone developers knew that it would never become mainstream but thought it was important because other languages would adopt it's ideas. It's amazing that they predicted that regions would be picked up later on by Rust.

You can find it here: https://twitter.com/tmccrmck/status/850465514807631872

Compile-time checking of owned and borrowed references was in Vala, a C#-inspired language for the GNOME ecosystem, four years earlier.

Doesn't Vala use reference counting? [1] I'm not actually sure; do you have some pointers I could read here?

1: http://www.vala-project.org/doc/vala/Overview.html#Memory_ma...

From what I remember, it just uses GLib's system for implementing reference-counted pointers in C and is equivalent to using Rc<T> or Arc<T> everywhere in Rust.

Yeah, that's what I thought. Which is very different than most Rust code!

Yes, but so does Rust. Reference counting is orthogonal to, although related to, to borrow checking.

Vala's wiki has a page all about its ownership mechanism: https://wiki.gnome.org/Projects/Vala/Ownership

Rust does not use reference counting for ownership, or borrow checking. It is true that you can introduce it for your own types though, with Rc/Arc. That's not really "rust using" it though; it's just a library.

Thanks for the link, I'll dig in!

That's the point. IIRC it's called Rust to allude to the fact that there's nothing really new in the language

Odd that you find closures weird. I use them everywhere that I can because it allows you to make your library more modular and, at the same time, allows you to write unit tests for otherwise impossible functions to test without dependency injections and other convoluted external setups that won't pinpoint the cause of an error very well.

Case in point, in the Ion shell that I am working on, I have a shell expansion module within that takes a structure containing closures that are used to grab and expand array variables, string variables, tilde variables, and process expansions.

Because of this, the module can live as an entirely separate piece of software with no dependency on the specifics of Ion, and I can write reduced unit tests that extensively test every component. I could strip it out of Ion and use it with a completely different shell project. That shell would just have to provide the batteries (closures) that define what to do with certain tokens.

I don't know why you're calling all of that stuff "weird". I have to assume it's simply because you were never exposed to another language that had stuff like it. But you're definitely wrong about that keeping Rust from going mainstream - just look at Swift, which has a very similar trait system (called protocols), enum variants with associated values, an arguably weirder error system, widespread closures, and half-functional style. And I'd say Swift is already fairly mainstream.

Swift is mainstream because Apple replaced Objective-C with it for iOS and said that it's new standard for writing apps. How much of Swift is written out of Apple ecosystem? Not much.

Apple didn't replace Obj-C. They added Swift alongside it. Literally nobody is being forced to switch, and all of Apple's frameworks are still written in Obj-C (they can't be written in Swift until Swift has ABI stability).

Yes, Apple's weight helped Swift tremendously. But people are switching from Obj-C to Swift because they think it's better, not because Apple's making them.

> How much of Swift is written out of Apple ecosystem? Not much.

Not much yet, because the Linux support is still missing a lot, but it's being filled in quickly, and a lot of people seem to be excited about being able to start using Swift on Linux.

> Trying to port something from another language to Rust is difficult because Rust's ways of doing things are so different from other languages.

That's the whole reason to have a new language; if we just wanted a language that works like elcurrent popular languages, we wouldn't need a new language for that.

> I have the feeling that Rust is destined for a niche like Haskell - cool, but not mainstream.

Becoming a Haskell or a Lisp -- never an industrially dominant language but one from which later and more industrially popular languages are continuously mining for some subset of their ideas because they solve problems long before most users of industrially popular languages even recognized the problem, much less the value of the particular solution, is not a failure.

And it makes the language one that is valuable to learn even if you don't often get to use it anger.

This is like reading criticism of Erlang which we use. A bunch of people (the vast majority of which never shipped anything in it) have plenty of arguments against it, those of us that actually use it love it to bits.

Rust is productive, efficient and a joy to use. For things we required C/C++ before, we will be using Rust now.

Rust aims to be mainstream hence the effort to improve ergonomics and marketing,documentation. Or atleast safe systems programming to be mainstream.

Japan's NicoVideo seems to agree. 550K lines of Erlang, and 20K lines of Rust.

The fact that you think all these features are 'weird' just solidifies you haven't used a typed language with any modern features

You don't have to do any of that in your code. All the main compiled languages (or at least C++, Java, and C#) are all getting features roughly equivalent to what think is difficult in Rust: closures, functional pipelines, option types, pattern matching, and the like.

Sure, you've got to know about Option and Result to do anything with Rust, but you've got to know about exceptions and null pointers in the rest of those languages. But you can write coherent Rust using for loops everywhere instead of stupid closure tricks.

> The half-functional style is too weird. The widespread use of closures for simple stuff is too weird. There's too much unnecessary originality. Trying to port something from another language to Rust is difficult because Rust's ways of doing things are so different from other languages.

This. I've spent some time researching Rust but it's just ugly language for me, really. When I read D everything is so clean, so readable. When I need to read/write Rust, it's just not enjoying for me. There are people that will enjoy it for sure, that came for example from Haskell.

Create language like Rust with D like syntax, no GC, no additional indirection, RAII, less strict rules or possibility to turn off some of them and I am sold.

> Create language like Rust with D like syntax, no GC, no additional indirection, RAII, less strict rules or possibility to turn off some of them and I am sold.

I think that language will end up looking a lot more like Rust than you think. You can't just compare a language that wasn't designed for zero-cost memory safety to one that was, as if the zero-cost memory safety features have no learning curve.

> I think that language will end up looking a lot more like Rust than you think.

I disagree, I think you could pick different way based on Cyclone coupling with some modern static analysis techniques, it would not have so many features as Rust have but it would be less invasive and more "C/D'ish".

> and more "C/D'ish"

This I think is where a lot of the pushback comes from. People say want a new C replacement, but some portion of them look at what that actually means, and find they actually want C with a new feature or two because actually learning something new, even new looking, is work. Rust is not C or C++ with a few new features, it's a new language, and some people really want that, and some people are put off by how different it is.

It's perfectly fine for people to have a preference, but people should be aware of what it is - a preference. It's not some inviolate law that C's syntax and way of doing things is good, and we should make sure a successor follows that. It's importance to distinguish the familiar from the good. C has a huge advantage in that it's familiar, through it's own popularity and history and in those languages that it influenced. That doesn't mean it's inherently better though.

I agree with you that people have a preference. For me it's about enjoying what I am doing, I would rather change my job than write Rust every day, not because it's a bad language or I don't know how to use it but because this style of writing the code is not clean and elegant for me. I would rather write D, just my personal taste.

Reply on news.ycombinator.com