Hacker News Reader

Comment by moonchrome | Hacker News Reader

As someone casually following Rust and haven't touched it or C++ in probably 5+ years (but keeping tabs in hope of coming back to that world), I feel like a lot of decisions he mentions are what made me optimistic about Rust adoption/positioning itself as a modern C++ replacement. So I kind of agree with his conclusion - his version of Rust would be much less interesting to me, and I think a lot of it's current users. eg. I only started playing with Rust once they removed green threads. Zero cost abstractions are a major selling point.

View on HN

I was at the sidelines when Rust 1.0 was being made and I think it got into an llvm induced feedback loop. Slowly turning into C or C++ with other features but the same type, object and memory model.

Part of the reason was Rust's desire to show itself as a direct competitor w.r.t performance, I think.

Performance, but with sanity.

Say you use a vector in C++. You push one element and pop two. In Rust that's a None. In C++ the answer is UB (in my case 43).

The fatal mistake here is using the STL...

The safe thing Rust did here is affordable in Rust (Option<T> is the same size as T for many T including all references) so they could afford to do it, whereas it's expensive in C++. Could it have been made cheaper in C++? Sure, but safety wasn't their priority so who cares?

That prioritisation applies to the whole ISO language, not only to the standard library.

Talking about C?

https://godbolt.org/z/vYcMhE9h7

You turned on a feature which helps diagnose this type of mistake at runtime, and it helped you by diagnosing the mistake at runtime. What does that prove?

What I'm talking about is that Rust's Option is very cheap in all the cases where it can be very cheap, which makes this whole design feature more affordable. C++ eventually grew std::optional which is not powerful enough for this work and yet is also bigger and slower. They could have done better, but safety wasn't a priority.

It proves that there is a way to diagnose this type of mistake, that is what matters.

Unlike C, which the only way to be safe is not to touch it at all.

As for performance, ISO doesn't implement compilers, there are many ways to improve performance while keeping the semantics in line with the standard.

If the compiler vendors decide to focus elsewhere is another matter, a bit like there are languages as complex as Rust and compile faster, because that has been a concern, whereas rustc developers have their concerns elsewhere.

Still, catching errors at runtime is subpar compared to catching them at compile time.

Even your dynamic example won't tell me calling pop/push x/y times respectively will fail if x > y.

I have to trigger it somehow.

Since when does Rust support dependent typing?

The fatal mistake is not enabling bounds checking, which most STL implementations support.

-Wabsolutely-everything

I haven't written the Language of Kings in a while: does GCC -Wall truly enable all warnings yet?

Obviously not. It would be an instant scandal if they tried that.

It doesn't, and that would be a bad thing, because warnings aren't magic and bug-free themselves. Nor is there any reason to comply with every single warning every person in the world has come up with.

clang has a -Weverything and it isn't supported.

And what should be defined behavior? There are quite a few choices that depend on particular situations. Feature designers have no knowledge about what would you want so they left it up to application programmer to check the situation upfront and act accordingly to their wishes. If you want same behavior across the whole application you can always write generic function doing just that.

Return either value or an EMPTY placeholder. Look Java did it. It returns a nullable value or Optional.

Then I have to check the result anyways. Same thing

You should always check

The argument is that Rust forces you and in C++ you can forget/the compiler can do what it wants

No. In Rust check is there by default, with optional unchecked access. In C++ the safety is off by default and you have to remember to check.

It's like Yaml parsers, they had "load_yaml" which is unsafe and "safe_load_yaml" which is the secure option. Imagine no surprise when Rubyists went for shorter safe looking method and got their servers pwned.

I think you are wrong. I looked and in Rust doc it says that: "Removes the last element from a vector and returns it, or None if it is empty". You better be doing check for "None".

The check is still there, that's not under dispute. GP is saying that it's still not the "same thing" as C++, since Rust will refuse to compile the code unless you either perform the check, or actively opt into unchecked access. In contrast, C++ will happily compile the code if you unintentionally neglect to perform the check.

Are you saying that Rust will refuse to compile code that does not explicitly check option return result for empty?

Yes, you cannot use the result without matching on the result/option type.

>Are you saying that Rust will refuse to compile code that does not explicitly

Depends what you mean by explicit.

Look at it like this:

    pub fn main() { 
      let mut vec : Vec<i32> = vec![];
      let x = vec.pop();
      println!("{:?}",x); // prints: None
    }

In this case you see the value is missing.

    vec.pop().expect("I want a value")

will panic with "I want a value" because value is empty. And most rigorous way to deal with it is:

    if let Some(x) = vec.pop() {
       println!("{:?}",x); 
    } else {
       println!("EMPTY"); // prints: Empty
    }

will either print value or EMPTY depending on what the vector contains.

Types like Result will issue warning that you didn't handle the cases.

for some reason I can not answer your subsequent reply so I do it here:

I looked at your example and played a bit with it and yes I agree with you - compiler does help in this case.

My old text:

So instead of checking if vector is not empty you check that the return result is not empty. I do not see much difference. If Rust compiler would choke when "else" clause in your example is not present I would understand your point about compiler preventing improper access.

`x`, the value of the Vector access, only exists within the context of the first block. It does not exist in any other scope. This makes it impossible to access when the result is not valid.

> If Rust compiler would choke when "else" clause in your example is not present

The compiler won't choke, but it will stop you from accessing the value.

It doesn't matter if you omit the `else` clause or not, the type system ensures that you can't access invalid values.

Here's a bit of an example based off of @Ygg2's code: https://play.rust-lang.org/?version=stable&mode=debug&editio...

> for some reason I can not answer your subsequent reply so I do it here

Hacker News will try and discourage really quick back and forth comments. To do so, the reply button is hidden. However, if you click on the timestamp, to go to the comment's own page, you can reply there.

Thanks for the tip. Did not know it

To be precise, Rust will refuse to compile code that accesses the value without checking that it is not empty.

Rust does that with the combination of "sum types" (aka "enums with data") and pattern matching. An `Option<T>` is either `Some(T)` or `None`. Matching on an option with the pattern `Some(value)` creates a new syntactic scope where the value is accessible. This scope is only entered if the `Option` is actually non-empty.

All ways of getting the value from the option are ultimately shorthand for a match in that way. For example, option.unwrap() will either get the value if it there, or panic. Option.unwrap_or(x) will either get the value of it there, or use x instead.

In practice this is x100 less error prone than C++. Source: was burned by vector.front() on empty vectors more than once. In C++, UB. In rust, usually the "empty case" is considered when first writing the code, or at least caught during review (unwraps tend to be very visible in reviews)

Problem is, you call pop on empty vector in C++, you get nasal demons. Not a case in Rust.

I'm not a C++ expert but here is my understanding. Vector is essentially a tuple of (dynamic_array_address: ptr, size: size_t, capacity: size_t). To pop a value from vector you just decrements size. So what happens when you have empty vec? Your size is 0, and you're substracing 1, which causes undefined behavior.

Correct way is to check BEFORE you pop_back().

In Rust, any number of invocation of pop() will not result in undefined behavior. You can ignore the value, or you can check it, but it doesn't expose you to UB just for slightly misusing a vector.

>"Correct way is to check BEFORE you pop_back()"

Absolutely and this is exactly what I do. I always check the containers before removing elements.

>"In Rust, any number of invocation of pop() will not result in undefined behavior. You can ignore the value, or you can check it, but it doesn't expose you to UB just for slightly misusing a vector."

I do not understand "slightly misusing" part. I assume in Rust it would bomb if pop() returns "none" and you try for example add said "none" to some number.

Vec<T>::pop() and similar methods return an Option<T>, so it's a compile-time type error to just add a number to it directly.

> I assume in Rust it would bomb if pop()

That's the thing. It wouldn't. Worse you can do is make whole program panic, with well defined stack trace and message.

It will never return non-sense and pretend all is ok.

In C++ it is an error, if one bothers to enable bounds checking.

https://godbolt.org/z/vYcMhE9h7

> Error: attempt to access an element in an empty container.

Someone much more insightful than me pointed out that most of the safety advantages of Rust are really a cultural phenomenon, rather than a strictly technical one. You could write unsafe unsafe Rust that derefs invalid pointers all day but when building systems and libraries with Rust, people value safety and Rust enables that as a priority.

Yes, that is kind of true.

It is also what attracted me into C++ coming from Turbo Pascal and Turbo Basic, back in the early 1990's.

Although C++ culture could be much better towards safety, it is definitely better than whatever WG14 is doing, or C has brought into the picture for the last 50 years.

Also anyone that just copy pastes C like code into C++, is the kind of developer that will be using unsafe{} all over the place, on the languages that have them.

Telling people to stop using unsafe is much easier than telling people to not have undefined behaviour.

C developers like telling themselves that only people with bounded rationality make security critical mistakes. All the skilled C developers have ascended beyond the mortal realm and would never let themselves be chained up with crutches for the weak like affine types or overflow/bounds checking.

> a cultural phenomenon, rather than a strictly technical one. You could write unsafe unsafe Rust that derefs invalid pointers all day

Yes you could. But I do not think " cultural" is the right term for not putting all your code in an `unsafe` block

> Someone much more insightful than me pointed out that most of the safety advantages of Rust are really a cultural phenomenon, rather than a strictly technical one

It's not. It's a safety phenomenon. See Java, C# etc.

Java doesn't have huge focus on it, but managed to get it right.

It's not an error by default and more importantly it's not an error under right circumstances (e.g. lets say number of pops and inserts is supplied via arguments).

Yes defaults matter, it doesn't change the fact that protective gear is available, and like seatbelts, helmets and motorrad full body armour, it is up for security conscious people to make do of what is made available to them.

As for your dynamic arguments request, have fun,

https://godbolt.org/z/YYKrnh4Y9

It's not just that defaults matter, the problem here is why have footgun as the default?

In a runtime example I can run it with tests and it would behave fine if both values are same or first arg is bigger, in Rust's case it would behave valid for ANY combination of arguments.

Likewise with C++ if the safety belt is buckled.

Heavy disagree. This is less giving a safety belt and more like saying we got airbags (that are deadly without seatbelts) and a DIY seat belt is somewhere in there too (it's in a box under the seat).

Coming from Java the C++ stuff is jarringly unsafe.

Agree that Java is much better than using raw C++.

Still, if you want to contribute to OpenJDK internals, they will only be taking pull requests in C++, not Rust.

So better learn how to build those seatbelts and airbags, for all the projects we rely on, including Rust's own reference implementation, that aren't going to rewrite their code from C++ into something else.

I think this quote also applies more generally:

> It's easier to work with than C++, but that's fairly faint praise.

So, while Rust positions itself as a C++ alternative with all the complexities that C++ developers love, it may become less attractive for other use cases. For instance, I find it highly questionable to develop a web app in Rust...

There's tons of existing languages that are mostly okay that you can develop a webapp in.

Rust as a C++ replacement serves a real unmet need in the marketplace.

We build a proof-of-concept backend replacement for what is essentially “SharePoint being used as a DB with a frontend by people who don’t know how to use SharePoint” and was a nice experience. We also build it in a few other languages, C#, Go, Python and TypeScript and Rust was probably the best experience of them all. We ended up going with C# because we needed Odata, and at the time we hadn’t yet run into the many “joys” of working with Odata, ASP and Entity Framework and how their model builders, really, really, really, won’t play together nicely.

Knowing what we know now, we should’ve gone with TypeScript and just written our own Odata filter on top of it, but live and learn.

If I was in a position where I could pick and chose languages, and not worry about how not having TypeScript in most things will mean our best front-end developer can never go on vacation because he’s sort of our only front-end developer, I wouldn’t mind using Rust for web-backends.

Rust GUI is obviously not a great experience. At least not yet. But it’s not that bad either. I think it’s mostly the case of how JavaScript is just so good at it and seeing such a fast pace of improvements because the entire world uses it for most GUIs these days, that it’s just hard for anything else to compete. I mean, look at stuff like Flutter or Blazor, they are backed by Microsoft and Google and they’re vastly inferior choices for most use cases compared to simply building things in React, ReactNative or even electron, and that’s not because I have some wild love for JavaScript, it’s because it’s seeing rapid improvements they dwarf it’s competition simply by being used by a lot of people.

I wish Rust would have someone like Facebook pick it up and build a frontend framework for it, but I think that is just too unlikely for you to bet on, and you certainly wouldn’t want to do it yourself, even as open source because then that would probably be your entire job.

On the flip-side, the packages that handle basic back-end web stuff for Enterprise use are rock solid in Rust. Which is impressive, at least to me, considering it’s young age. I have no idea why, but maybe some serious players are contributing to it because they use it themselves. There isn’t a “Django” or Ruby+Rails for Rust, but if what you’re building is a lot of smaller APIs with various transport methods and data access in an federated authentication scenario then Rust is surprisingly mature for the web. It’s primary disadvantage being that your TypeScript and Rust developers won’t be able to cover for each other (which is why we didn’t poc with Java).

> I wish Rust would have someone like Facebook pick it up and build a frontend framework for it

We have yew, and my personal favourite: leptos (https://leptos.dev/)

As someone who recently started their first web app in Rust and is using Yew for the front-end, I wish they included benchmarks against other Rust frameworks. I also wish I had more experience and had looked harder; Yew is very verbose in my experience and Leptos looks a little more sane.

> it may become less attractive for other use cases. For instance, I find it highly questionable to develop a web app in Rust...

I mean who'd want to and why bother trying to support that use case? Basically none of Rust's value proposition exists for a web app while nearly every single one of the downsides do.

Hard disagree. Rust brings a lot to the table for a web app. Compiled vs interpreted makes it easier to catch (syntax) errors beforehand. You can even go as far as compiled templates. Mapping JSON (or whatever) to strongly typed objects is great. Dependency management is best in class. I rather like diesel.rs (although it is very much an acquired taste) especially if you treat it like a safe query builder rather than an ORM.

The single biggest problem I've run into is that there's no real good story for a web app framework (especially since everyone's gone crazy over async). Rocket is perhaps a bit too magical for rust folks and it's been abandoned, but I rather liked it. I've warmed up to axum, but all this async stuff still rubs me the wrong way.

And, yes, compile times still suck.

Arguably TypeScript is pretty close to as safe while being less work.

Perhaps. But TS is still Javascript under the hood which means implementation details leak and they smell awful. If they didn't it'd come down to a preference for compiled vs interpreted.

The number one syntactical beef I've is operators. e.g. == vs ===, ""+number.

Although all of those things are true, I think the main point being made is why choose Rust for that, instead of Go, .NET, etc, any of which offer everything you've outlined as being worth having, while having fewer of the downsides of Rust.

  any of which offer everything you've outlined

They don't, that's the "problem". Off the top of my head dependency management in Go is not best in class to put it charitably. .NET will tie you more closely to Windows. Sure, mono is a thing but you'll have more packages to choose from and fewer compatibility issues running .NET on Windows.

Mono? 2000 and late called and want their .NET implementation back. Now it's all about the .NET formerly known as "Core".

Your knowledge of the .Net ecosystem is a bit out of date. It's had first class support for mac and linux for 7-8 years now.

First class support on Linux and Mac with caveats. Zero snark intended.

Web development for .NET is multiplatform for quite some years now. https://en.wikipedia.org/wiki/.NET

Mono is mostly only relevant if you need platform specific capabilities that wont be covered in .NET.

To me, one thing missing from most popular web languages is the single best part of Rust: A well-defined handling of the non-happy path.

I'm talking about things like exhaustive "switches", built-in, ENFORCED handling of "missing" values (null, undefined), and finally useful error handling.

I actually don't need any of the baremetal features of Rust. It's just that most of it's "zero-cost" abstractions are still far superior to those of other languages.

Haskell, Scala, F#, OCaml.

(Some dislike it, but Java’s checked exceptions are exact homologous of result types)

The problem with Java exceptions is that they have very poor generic support.

Outside of that, yeah they just differ in very low-level aspects that most developers don't even know about.

> Dependency management is best in class

Do crates have namespaces that ownership is verified for?

Crate namespaces is best-in-class++ feature and currently not available.

Yeah, I ask because the JVM world has had that since... whenever Maven's central repository came about [0][1][2], I guess, and it ensures that there's no debate about namesquatting [3], nor typosquatting attack vectors [4].

I am constantly baffled that NPM, PyPi, crates.io etc. didn't copy this idea for those last two reasons. In my mind, it's not quite best in class without it.

[0]: https://central.sonatype.org/publish/requirements/coordinate...

[1]: https://central.sonatype.org/faq/how-to-set-txt-record/

[2]: https://central.sonatype.org/publish/requirements/coordinate...

[3]: https://internals.rust-lang.org/t/pre-rfc-formal-squatting-p...

[4]: https://blog.sonatype.com/this-week-in-malware-may-13th-edit...

> Compiled vs interpreted makes it easier to catch (syntax) errors beforehand. ... Mapping JSON (or whatever) to strongly typed objects is great

cough C#. You also get LINQ. And a fairly heavy amount of web frameworks in ASP.NET / Razor.

Or Java, F#, Scala, Kotlin, Haskell. If we were to randomly pick a language, chances are it could be a good fit for these — Rust became as well-known as is because it was made for a different niche, where there were no competition.

Haskell is a beautiful language, but I find their web frameworks rather cumbersome to work with personally.

Hell, even Python can map JSON to a strongly typed object. I am a firm fan of Pydantic and its competitors when dealing with JSON blobs. No-one deserves a KeyError in prod code.

I am doing that for a just for fun side project and it was an interesting experience.

The pieces and features i wanted exist but tying them together was not always straight forward.

From the top of my head I used:

- actix-web

- tracing (logging)

- sea-orm

- config from yaml files and a custom implementation to allow profiles.

- utoipa (for openapi and swagger ui)

- thiserror

In a professional context I would not have used Rust for this project, but it was quite fun to explore it's possibilities and rich crate ecosystem.

>"I mean who'd want to and why bother trying to support that use case"

I write my web apps in C++. They tend to be little bit more than just query database / update database. They're exposed as JSON based RPC and can be accessed by JS front end from browser or third party systems we interact with. The performance is stellar and the code size is not much different comparatively to using PHP / Ruby / Python / your_pet_goes_here.

Nice. Do you have some open source samples? I would like to see your style!

No. I do not work on opensource projects unfortunately.

>So, while Rust positions itself as a C++ alternative with all the complexities that C++ developers love, it may become less attractive for other use cases. For instance, I find it highly questionable to develop a web app in Rust...

But we already have plenty of options for this use case (.NET, JVM, Go, Python, Ruby, node.js, PHP, Erlang, etc. etc.). Very mature ecosystems that solve a lot of different edge cases.

There are very few C++ alternatives worth mentioning, none as mature as Rust in terms of adoption/tooling.

If you need to write a webapp that would require C/C++ kind of memory handling/performance then Rust would be the ideal candidate I think.

I don't know what kind of tradeoff matrix makes you use the Rust graydon describes over the existing options.

For example my main issue with D (but TBH that's something I've given up on actively tracking 10 years ago probably) is that by including GC in the runtime/stdlib - it basically painted itself as a poorly supported competitor to C# rather than a C++ replacement.

It makes me smile that my top-level comment says I would have preferred the ML-version of Rust, while you say you prefer the zero-cost-abstraction version of Rust that's more C++-like.

Indeed in software engineering there is no silver bullet nor a perfect language for everybody :-)

ML-version of Rust would not have been a uniquely interesting language. It targeting the C++-niche is what made it into quite the big name it has become.

There’s already a ML-version of Rust, it’s Ocaml

I'm pretty sure that the ML version of Rust is actually ATS.

https://www.cs.bu.edu/~hwxi/atslangweb/

Thanks, never heard of ATS before.

Reply on news.ycombinator.com