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

261–270 of 291 posts

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

#261

Post by bogomipz »

stmfd wrote: post #42
bogomipz wrote: post #18

Earlier quoted context omitted.

>"I don't think there's much incentive post C++11 to really consider porting anything (even small things) over" I am curious why specifically C++ 11? Could you elaborate?

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…

Thanks for the detailed explanation. I appreciate it.

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

#262

Post by xiphias »

soulbadguy wrote: post #73
xiphias wrote: post #36

Earlier quoted context omitted.

Rust is the first language since C++ that can improve/not hinder runtime speed while making development safer, so I definately see its future. The only problem is that the compiler is very slow now, so it doesn't scale to large code bases, which is a no-go in my company. Hopefully the Rust team understands that this is not only a would-be-nice to have feature (I see learning the borrow checker as a smaller problem)

Dlang ?

In Dlang you either opt for slower garbage collection or get back to manual memory management where you don't get any advantage compared to C++

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

#263

Post by tmccrmck »

lossolo wrote: post #220
mmstick wrote: post #129

Earlier quoted context omitted.

Google and Microsoft are using it.

You have any sources to support that claim? Where do they use it? In their infrastructure?

Unless you count ripgrep being shipped with VS Code as a data point of Microsoft using Rust, I can almost certainly say that the above poster is wrong.

Source: We had an email thread about using Rust on the MS Rust mailing list about a month ago.

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

#264

Post by kbenson »

lifthrasiir wrote: post #193
sidlls wrote: post #141

Earlier quoted context omitted.

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

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

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

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

#265

Post by 46Bit »

46Bit wrote: post #208
tmccrmck wrote: post #161

Earlier quoted context omitted.

> If rust ever gets to the point where it's not much harder to write than java/c# then why not got for the fastest one and avoid performance death by a thousand cuts? Sure. If it's just as easy for the task then why not? But I wouldn't recommend Rust for web development for the same reason I wouldn't recommend C++ for web dev: complexity. Obviously, this is entirely subjective but I don't think either language will e…

> I used to TA a freshman data structures class. I can't imagine ever going to a class of new programmers and trying to explain to them when to use Rc >> vs. Rc >>. I'm interested - how do you teach it? I would have thought that the type system could make these things easier to visualise rather than harder, but then I don't have teaching experience.

A friend pointed out some reasons, in particularly the safety stuff, that would make Rust unsuitable.

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

#266

Post by mmstick »

flukus wrote: post #187
mmstick wrote: post #185

Earlier quoted context omitted.

This is the same line of logic and statements repeated by C and C++ programmers that shortly thereafter get showed up with a list of CVEs in their 'modern C/C++' projects. Remember the recent Curl developer PR disaster?

I think it's too early to tell if rust will prove any better in the real world, which includes things like devs using unsafe sections to cope with time pressures.

Use of unsafe in Rust is not required or recommended in most, if not all situations. That said, auditing a handful of small unsafe blocks is easier than auditing an entire project.

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

#267

Post by kbenson »

lokedhs wrote: post #204
hyperpape wrote: post #182

Earlier quoted context omitted.

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

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

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

#268

Post by mmstick »

whyever wrote: post #202
mmstick wrote: post #178

Earlier quoted context omitted.

Thanks. I've never built a website before, but now I've built a website, and a web server + cms client at the same time. I've been thinking of open sourcing the code at some point in the future. The website stores all the content in a database, uses handlebar templates to generate HTML pages, stores the generated HTML pages in a concurrent hash map compressed with the native Rust implementation of Zopfli, and only re…

Couldn't you just gzip the HTML and serve it directly to the browser?

The HTML pages are generated dynamically from content in my database, in the same manner that Wordpress works. Once a page for a URL has been generated, it is indeed gzipped with zopfli and stored in a concurrent hash map so that future requests for the same content will serve the already-compressed content.

If the timestamp has expired and a user requests expired content, only then will that page be re-generated, re-compressed and updated. Without this, I would have to re-generate and re-compress the content each time I get a request.

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

#269

Post by mmstick »

Rusky wrote: post #211
mmstick wrote: post #183

Earlier quoted context omitted.

It's entirely dishonest and ignorant to simply discredit and dismiss someone's point of view because you have it set in your mind to not believe a point of view that isn't your own. My history with Rust is proof alone that there is more to the story than you claim. I'm not the only one that has no difficulty with Rust either. It is all a matter of mindset, and so if you think it is hard, then it will be hard. However…

It is all a matter of mindset, but you are blindly ignoring the fact that it takes effort to learn a new mindset. Maybe it went smoothly for you and that's fine (though I suspect you're just not remembering it, perhaps willfully). In fact it went relatively smoothly for me as well. The point is claiming it's easy dismisses the very real obstacles that exist for others, and does worse than nothing at convincing people…

I had zero issues learning and then creating software with Rust shortly thereafter. In fact, we even have recent threads in the Rust user's forum from people that have picked up Rust and already have some software solutions implemented it on day one. To claim otherwise is just denial.

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

#270

Post by kbenson »

sidlls wrote: post #96
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 pat…

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

Post reply on HN