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

Ask HN: Will Rust ever become a mainstream systems programming language?

news.ycombinator.com

Post reply on HN
Print view View original

241–250 of 291 posts

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#241

Post by burntsushi »

lossolo wrote: post #239
burntsushi wrote: post #233

Earlier quoted context omitted.

"Manipulation"? Really? Please. > And you would reply that almost everyone use it, because everyone is shipping their apps with Docker. Seems reasonable. Docker is a pretty compelling data point for the viability of Go for writing systems tooling. This argument still seems strange and very petty.

> "Manipulation"? Really? Please. > This argument still seems strange and very petty. Those are not an arguments for anything. What I wrote still stands. It's clear that author asked which company use (writes) Rust besides Mozilla, not which company integrate third party tools that was written in Rust - it's logical.

> Those are not an arguments for anything.

Well, you cherry picked my comment. I had other thoughts---specifically disagreeing with your analogy---but I guess that wasn't important to you?

If you (or anyone else) had a different interpretation than me, then that interpretation should have been immediately clarified by the link I provided and subsequent clarifying comments. Readers can decide for themselves whether it "counts" or not because they have all the information.

> I thought you are not part of "rust evangelism strike force" but seeing what you are writing now, I need to reevaluate that opinion.

Questioning biases is important. I encourage everyone to form their own conclusions. I personally think questioning my character and my intellectual honesty over what I said in this thread is extraordinarily petty.

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#242

Post by parenthephobia »

steveklabnik wrote: post #164
parenthephobia wrote: post #104

Earlier quoted context omitted.

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

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

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#243

Post by soulbadguy »

dbaupp wrote: post #198
Animats wrote: post #196

Earlier quoted context omitted.

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 p…

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

> 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

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#244

Post by soulbadguy »

steveklabnik wrote: post #160
soulbadguy wrote: post #155

Earlier quoted context omitted.

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.

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#245

Post by lossolo »

burntsushi wrote: post #241
lossolo wrote: post #239

Earlier quoted context omitted.

> "Manipulation"? Really? Please. > This argument still seems strange and very petty. Those are not an arguments for anything. What I wrote still stands. It's clear that author asked which company use (writes) Rust besides Mozilla, not which company integrate third party tools that was written in Rust - it's logical.

> Those are not an arguments for anything. Well, you cherry picked my comment. I had other thoughts---specifically disagreeing with your analogy---but I guess that wasn't important to you? If you (or anyone else) had a different interpretation than me, then that interpretation should have been immediately clarified by the link I provided and subsequent clarifying comments. Readers can decide for themselves whether it…

> If you (or anyone else) had a different interpretation than me, then that interpretation should have been immediately clarified by the link I provided and subsequent clarifying comments.

Purposely interpreting something differently while there is social majority consensus on interpreting it the other way looks like having an agenda, especially by someone that is heavily involved in topic in question like you are.

> I personally think questioning my character and my intellectual honesty over what I said in this thread is extraordinarily petty.

We are not bug free. When more than one random person questions my behavior same way I do not find that "extraordinarily petty", maybe there is something to it, maybe I should look at it. I am human, I have faults, denying that is another fault.

> Questioning biases is important. I encourage everyone to form their own conclusions.

I agree with you here. Anyone reading this discussion can make their own conclusions, some already did and were vocal about it - that's why we have this discussion in the first place.

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#246

Post by steveklabnik »

parenthephobia wrote: post #242
steveklabnik wrote: post #164

Earlier quoted context omitted.

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

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!

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#247

Post by steveklabnik »

soulbadguy wrote: post #244
steveklabnik wrote: post #160

Earlier quoted context omitted.

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.

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#248

Post by burntsushi »

lossolo wrote: post #245
burntsushi wrote: post #241

Earlier quoted context omitted.

> Those are not an arguments for anything. Well, you cherry picked my comment. I had other thoughts---specifically disagreeing with your analogy---but I guess that wasn't important to you? If you (or anyone else) had a different interpretation than me, then that interpretation should have been immediately clarified by the link I provided and subsequent clarifying comments. Readers can decide for themselves whether it…

> If you (or anyone else) had a different interpretation than me, then that interpretation should have been immediately clarified by the link I provided and subsequent clarifying comments. Purposely interpreting something differently while there is social majority consensus on interpreting it the other way looks like having an agenda, especially by someone that is heavily involved in topic in question like you are. >…

Emphasis mine:

> Purposely interpreting something differently while there is social majority consensus on interpreting it the other way

I did no such thing.

> When more than one random person questions my behavior same way I do not find that "extraordinarily petty"

You're the only person accusing me of purposefully misleading people.

> that's why we have this discussion in the first place

I'm in this discussion with you because you're assaulting my character, not because we disagree about whether Microsoft is actually "using" Rust or not. I don't care what you think about the latter, but I am not going to let unsubstantiated bullshit about me personally go uncontested. Now, please either show some evidence that I've purposefully tried to mislead others, or---and I mean this in the nicest way possible---shut your trap.

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#249

Post by soulbadguy »

Rusky wrote: post #152
stmfd wrote: post #42

Earlier quoted context omitted.

Let's look at Rust's homepage: - Zero-cost abstractions - C++, in my opinion, is the founding father of zero-cost abstractions. - Move semantics - we've had this since C++11. - Threads without data races - C++11 introduced a threading library as part of the language. We can avoid a lot of data races, deadlocks, etc. if you actually look deeper into how to implement the modern threading library well. - Efficient C bin…

> - Move semantics - we've had this since C++11. C++11 move semantics and Rust move semantics are not equivalent. C++ requires every movable type to have a null state, and a (perhaps derived) move constructor that can potentially throw exceptions. Rust avoids the null state problem by statically omitting the constructor call (or, in the dynamic case, inserting a flag into the stack frame rather than forcing the progr…

> C++11 move semantics and Rust move semantics are not equivalent. C++ requires every movable type to have a null state, and a (perhaps derived) move constructor that can potentially throw exceptions.

This doesn't sounds true to me. Can you clarify what you mean by moveable type have to have null state ?

> Rust avoids the null state problem by statically omitting the constructor call

You seems to be conflating move semantics and move optimization...

Re: Ask HN: Will Rust ever become a mainstream systems programming language?

#250

Post by steveklabnik »

soulbadguy wrote: post #243
dbaupp wrote: post #198

Earlier quoted context omitted.

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

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

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.
Post reply on HN