Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rust I wanted had no future

graydon2.dreamwidth.org

Post reply on HN
Print view View original

431–440 of 523 posts

Re: The Rust I wanted had no future

#431

Post by 59nadir »

dataflow wrote: post #244
hardwaregeek wrote: post #222

A lot of Graydon's ideas feel like interesting extensions to ML-style languages. I bet if he had continued down that path, it would have been a lot more of an experimental language with a hodgepodge of different ideas. Which is totally valid (you need these languages to test new paradigms and features), but definitely would not have become mainstream. Basically, I view Grayson as a leader who set the tone for Rust be…

> Rust ending up as a replacement C++ helped it If anything, it's more a C replacement than a C++ replacement. It will take some market share from both of course (and other languages to a lesser extent too), but functionality-wise, it just isn't (currently, at least) practically able to replace some C++ use cases.

In some ways I think Rust is a bad replacement for both. It's an alternative in some ways to C and an alternative in some ways to C++.

I don't think anyone who still uses C today and hasn't lived in a cave for the last 20 years would be very interested in Rust since it's just not at all like using C. There is the rare Bryan Cantrill who for some reason was seemingly unaware that other languages existed from 1990 until 2018 but I think it's safe to say most other people who primarily use C would not prefer the leap to something like Rust.

For the people who use C++, certainly they're already used to a language that wants to dominate, so Rust should be fine. In terms of features, apparently it doesn't hold up, but because it's like C++ I'm sure they're just a couple of years away from adding those things too, and then the language can continue being more important than the actual data transformations the programs are supposed to be doing.

Re: The Rust I wanted had no future

#432

Post by hadrien01 »

diarrhea wrote: post #379
hadrien01 wrote: post #197

Earlier quoted context omitted.

The language doesn't push you towards interfaces implemented once, but many developers indeed persist doing it for no reason at all. With proper code review we're able to make that practice go away on the projects I'm working on.

Lots (all?) major frameworks push for dependency injection though, where interfaces are a must, as far as I know (not for DI-the-principle, but DI-as-implemented). ASP.Net Core is a good example. It's not C# at the language level forcing interface-driven development, but frameworks like ASP.Net are so tightly integrated that boundaries blur.

You don't need interfaces for dependency injection, you can inject classes directly. I see interfaces more for separation of concerns (with domain-driven design pushed from all parts in the .NET world at the moment...), but that's not an obligation.

Re: The Rust I wanted had no future

#433

Post by hadrien01 »

rjbwork wrote: post #413
vips7L wrote: post #203

Earlier quoted context omitted.

Isn't this just mostly an issue with mock testing in C#? Developers cargo cult single implementation interfaces because its so hard to mock concrete classes.

>Isn't this just mostly an issue with mock testing in C# Yes. You have two choices: Interface implemented once, or virtual on all your public members. I personally think Interface is the sane choice. Would be nice if the .NET devs let us mock POCO's though...

You can mock (well, "fake") POCOs with packages like AutoFixture that use reflection to generate mostly fake data, depending on what you need. You don't need interfaces or virtual, but you do need public getters unfortunately.

Re: The Rust I wanted had no future

#434

Post by dataflow »

59nadir wrote: post #431
dataflow wrote: post #244

Earlier quoted context omitted.

> Rust ending up as a replacement C++ helped it If anything, it's more a C replacement than a C++ replacement. It will take some market share from both of course (and other languages to a lesser extent too), but functionality-wise, it just isn't (currently, at least) practically able to replace some C++ use cases.

In some ways I think Rust is a bad replacement for both. It's an alternative in some ways to C and an alternative in some ways to C++. I don't think anyone who still uses C today and hasn't lived in a cave for the last 20 years would be very interested in Rust since it's just not at all like using C. There is the rare Bryan Cantrill who for some reason was seemingly unaware that other languages existed from 1990 unti…

Yeah to some extent I agree. Regarding this:

> but because it's like C++ I'm sure they're just a couple of years away from adding those things too

If they're smart (which they are), I'm sure they'll eventually cave and add some of the missing stuff, no matter how much they want to believe these features are unnecessary. Just like how C is finally coming around and adding generics and all that. The particular capabilities I mentioned here wouldn't be impossible to add, and they can probably achieve some of them better than C++ did. But I do think there will remain use cases that Rust will fail to accommodate.

Re: The Rust I wanted had no future

#435

Post by Ygg2 »

pjmlp wrote: post #411
Ygg2 wrote: post #303

Earlier quoted context omitted.

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.

Re: The Rust I wanted had no future

#436

Post by [deleted] »

pmoleri wrote: post #377
divan wrote: post #261

Earlier quoted context omitted.

It's crazy that the programming community even accepted the concept of async/await as a sane one. Being sync or async is essentially a property of the attention of the caller, not of the action itself. Is "eating a donut" a sync or async action? If I'm focusing all my attention on it, essentially putting all tasks aside (after) - then it's a synchronous action. If I'm reading a book/watching a video/walking/etc, whil…

> How does "func EatADonut() async {}" aka "eating a donut is an inherently async action" even make sense to people? Of course it does, read it as "beware, something blocking down the road". If you can EatADonout without blocking, please do, but want it or not that's a different implementation, one that doesn't block and the signature it's telling you so. We're so used to sync and having hidden blocking operations. I…

[deleted]

Re: The Rust I wanted had no future

#437

Post by smasher164 »

I admire Graydon's humility on the subject--and sure enough, I disagree with some of his ideas in this post, and agree with other ones.

- Explicit lifetimes are what make rust what it is. It would have surely failed had they not been introduced.

- I disagree about having a first-class module system instead of traits. Coherence and implicit instance resolution are a core value of Rust. `Send / Sync` are key examples of that.

- Green threads probably wouldn't been viable for rust, given the kind of programs it's targeting.

- Pretty much everything else however, I agree with.

Re: The Rust I wanted had no future

#438

Post by __jem »

FpUser wrote: post #422
LegionMammal978 wrote: post #410

Earlier quoted context omitted.

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.

Re: The Rust I wanted had no future

#439

Post by Ygg2 »

FpUser wrote: post #422
LegionMammal978 wrote: post #410

Earlier quoted context omitted.

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?

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

Re: The Rust I wanted had no future

#440

Post by dureuill »

FpUser wrote: post #422
LegionMammal978 wrote: post #410

Earlier quoted context omitted.

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?

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

Post reply on HN