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

91–100 of 291 posts

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

#91

Post by sidlls »

_jordan wrote: post #69
sidlls wrote: post #16

Earlier quoted context omitted.

C++ is hard, too. So is C, to write correctly. Hasn't stopped either of them from literally powering almost every computer in use. Rust's complexity is equivalent to, but distinct from C++'s. I prefer it over C++, and I'm one big fan of the latter.

Rust is a paradigm shift; "...to write correctly" most people don't start off the bat with correct IMO. The learning curve is steep with rust.

Yes, and I would say that is problematic for fast uptake. However I don't think that over the long term it is an insurmountable barrier.

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

#92

Post by jostmon »

soulbadguy wrote: post #79
makmanalp wrote: post #71

Earlier quoted context omitted.

You're being so rude and inflammatory, for no reason. What's so frustrating is how you're convinced that everyone else is an idiot. > it's incredibly disingenuous to act like it's a major issue I gave you a trove of real world examples of serious security issues in widely used software developed by competent teams. Quite a few of these would have not existed in a language with the kind of guarantees that Rust provide…

> I gave you a trove of real world examples of serious security issues in widely used software developed by competent teams. Quite a few of these would have not existed in a language with the kind of guarantees that Rust provides. How is this disingenuous? Genuine question : do we know that those bugs would have been avoided using rust? Maybe some of those part would have had to be done unsafe mode for some reasons.…

You seem to be presupposing that all, or much of the C/C++ written today will follow best practices and be written by "expert" programers. A portion will, perhaps even a substantial portion, but I'd be willing to wager a far larger portion of the Rust written today will follow best practices and doesn't have to be written by expert programers. This is because the safety in Rust isn't optional, like it is with C/C++ best practices/new features.

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

#93

Post by soulbadguy »

pcwalton wrote: post #85
soulbadguy wrote: post #68

Earlier quoted context omitted.

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

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

#94

Post by biokoda »

xiphias wrote: post #77
biokoda wrote: post #49

Earlier quoted context omitted.

> The only problem is that the compiler is very slow now, so it doesn't scale to large code bases The way of working with that is use cargo check command which is much faster and splitting your problem into multiple crates so you don't have everything in one giant project. Which is what tends to happen in large code bases anyway. Also they are putting quite a lot of work into making it faster. Before you get to that…

While your suggestions work at some companies, it's not a good solution for every company: https://www.wired.com/2015/09/google-2-billion-lines-codeand...

A single repo can have lots of crates

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

#95

Post by pcwalton »

soulbadguy wrote: post #93
pcwalton wrote: post #85

Earlier quoted context omitted.

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.

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

#96

Post by sidlls »

Animats wrote: post #27

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

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

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

#97

Post by sidlls »

pcwalton wrote: post #48
Animats wrote: post #27

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

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

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.

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

#98

Post by soulbadguy »

pcwalton wrote: post #89
soulbadguy wrote: post #79

Earlier quoted context omitted.

> I gave you a trove of real world examples of serious security issues in widely used software developed by competent teams. Quite a few of these would have not existed in a language with the kind of guarantees that Rust provides. How is this disingenuous? Genuine question : do we know that those bugs would have been avoided using rust? Maybe some of those part would have had to be done unsafe mode for some reasons.…

> I think a much more interesting question is how much safer a code written in rust today would be vs a C/C++ code written today , reflecting our current understanding and knowledge on how to build safe system. A lot safer, judging by browser exploits.

> reflecting our current understanding and knowledge on how to build safe system...

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

#99

Post by daenney »

k__ wrote: post #90
daenney wrote: post #33

Earlier quoted context omitted.

> I'd say, before Rust becomes really mainstream, we have to wait for the current generation of sysdevs to die. Why?

Of old age I mean. It's like with everything. Most people simply do what they always did, most never reinvent themselves.

> Of old age I mean.

Yeah I get that. I asked why they should die. Not how or by what means.

> It's like with everything. Most people simply do what they always did, most never reinvent themselves.

Based on? And note that we're not talking about "most people", we're talking about a very specific subset of people. Considering the changes in popularity of programming languages and the recent surges in adoption of Go and Swift, I'd say there's at least evidence to support people do change in this domain when something comes along that excites them or opens up new possibilities.

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

#100

Post by pcwalton »

sidlls wrote: post #97
pcwalton wrote: post #48

Earlier quoted context omitted.

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

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.

Post reply on HN