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

Rust and the Future of Systems Programming [video]

hacks.mozilla.org

Post reply on HN
Print view View original

371–380 of 511 posts

Re: Rust and the Future of Systems Programming [video]

#371

Post by donatj »

user5994461 wrote: post #295
Matthias247 wrote: post #267

Earlier quoted context omitted.

I wouldn't say Go hasn't succeeded. Maybe not as a general replacement for C/C++. But still lots of new applications that would most likely have been written in C/C++ a few years ago are now popping up in Go (unix daemons, commandline tools, ...).

Go has succeeded in its niche (distributed systems). There are real jobs opportunities in Go, in the major tech hubs. Funny thing is. Everything that is done in Go could be done in Java. Go is succeeding because lots of dev despise Java (related to the entreprisey & the usual culture of java companies).

As well as the fact that Go runs markedly faster and lighter (memory) than Java, and without needing to worry about JVM versions. We've been slowly migrating services and the statically compiled binaries are truly amazing for ensuring it will run. Not once have I encountered an 'it runs on my machine' situation.

Re: Rust and the Future of Systems Programming [video]

#372

Post by burntsushi »

quotemstr wrote: post #370
burntsushi wrote: post #367

Earlier quoted context omitted.

If you can't acknowledge the presence of trade offs, then I don't see how I could justify specific trade offs. Just because I want to engage in a productive conversation doesn't mean my entire argument boils down to tone policing. It is OK to stop talking to someone because they are too frustrating to talk to.

Where did I disagree with the existence of trade-offs? What I find invalid is the idea that all trade-offs are equally good. The Rust scheme has certain advantages and certain disadvantages. I believe that the advantages don't matter much and that the disadvantages are worse than other people think. The advantages and disadvantages of the conventional C++ and Java model are better for a general purpose systems langua…

> Where did I disagree with the existence of trade-offs?

When you say stuff like this:

> This debate was settled

and this

> I do dismiss this advantage out of hand

In general, most of your comments on this topic make every possible negative point about Rust's error handling without ever taking care to balance it with the positive points. If we can't even come to a mutual understanding that there are some trade offs involved in this decision, then it's really hard to move on to balancing the trade offs. Especially when you say things like this:

> All you do with "try!" is annoy readers

> had its designers not jumped on the anti-exception bandwagon

> without properly considering the advantages of the exception model

> All of this because some people don't like exceptions

This is a consistent dismissal of both the trade offs involved and of the people that actually worked on this stuff. Do you actually believe Rust is the way it is because we just hopped on a bandwagon? If so, that's extraordinary bad faith.

Re: Rust and the Future of Systems Programming [video]

#373

Post by quotemstr »

Manishearth wrote: post #368
quotemstr wrote: post #365

Earlier quoted context omitted.

Sure, but then we're back to exceptions in one form or another, so now we have Result all over the place and have to deal with panics. Being able to panic on OOM won't go back in time and rewrite stdlib

> Being able to panic on OOM won't go back in time and rewrite stdlib I don't see how that's relevant? If you have to deal with OOM you're probably not going to deal with it at a fine-grained level, you'll have one high-level panic catcher somewhere that handles this and all other panics. Given that overcommit exists as well, this makes the cases where you want workable Result-on-OOM quite niche. (And there is work -…

Hundreds of millions of people use non-overcommit systems. That's a good thing, because overcommit is a mistake that encourages profligate use of system resources. I fear that abort-on-OOM will only reinforce the presumption of overcommit in the minds of developers. Even on overcommit systems, you can run out of address space or vsize.

I believe in treating memory like any other resource. You wouldn't abort by default when you run out of disk space, would you?

Re: Rust and the Future of Systems Programming [video]

#374

Post by quotemstr »

burntsushi wrote: post #372
quotemstr wrote: post #370

Earlier quoted context omitted.

Where did I disagree with the existence of trade-offs? What I find invalid is the idea that all trade-offs are equally good. The Rust scheme has certain advantages and certain disadvantages. I believe that the advantages don't matter much and that the disadvantages are worse than other people think. The advantages and disadvantages of the conventional C++ and Java model are better for a general purpose systems langua…

> Where did I disagree with the existence of trade-offs? When you say stuff like this: > This debate was settled and this > I do dismiss this advantage out of hand In general, most of your comments on this topic make every possible negative point about Rust's error handling without ever taking care to balance it with the positive points. If we can't even come to a mutual understanding that there are some trade offs i…

I'm criticizing Rust's error handling strategy. I shouldn't have to defend it at the same time. To be clear: everything is a trade-off. I don't think it's fair to claim that I don't think trade-offs exist merely because I haven't enumerated the scant good sides of the specific trade-off Rust made

Re: Rust and the Future of Systems Programming [video]

#375

Post by wyager »

z3t4 wrote: post #253
wyager wrote: post #211

Earlier quoted context omitted.

Why would I want to? Better to explicitly convert the number to a string.

This is something you do often in JavaScript, for example: "You have " + messages + " new messages"

"You have " ++ show messages ++ "new messages"

This is type safe.

Re: Rust and the Future of Systems Programming [video]

#376

Post by Manishearth »

quotemstr wrote: post #373
Manishearth wrote: post #368

Earlier quoted context omitted.

> Being able to panic on OOM won't go back in time and rewrite stdlib I don't see how that's relevant? If you have to deal with OOM you're probably not going to deal with it at a fine-grained level, you'll have one high-level panic catcher somewhere that handles this and all other panics. Given that overcommit exists as well, this makes the cases where you want workable Result-on-OOM quite niche. (And there is work -…

Hundreds of millions of people use non-overcommit systems. That's a good thing, because overcommit is a mistake that encourages profligate use of system resources. I fear that abort-on-OOM will only reinforce the presumption of overcommit in the minds of developers. Even on overcommit systems, you can run out of address space or vsize. I believe in treating memory like any other resource. You wouldn't abort by defaul…

Overcommit wasn't my main point. My point was that the intersection of systems where:

- You are using the stdlib (so not designing an OS or other low level programming)

- OOM must be recovered from

- OOM-as-panic with recovery at a higher level in the application is not going to work and you need fine grained OOM recovery

is small. Overcommit makes it smaller, but ignoring that it is still small.

Re: Rust and the Future of Systems Programming [video]

#377

Post by cynicalkane »

Retra wrote: post #327
kzrdude wrote: post #277

Earlier quoted context omitted.

You'll like Rust, because concurrent mutation of a value is impossible if you hold a `&` or `&mut` to the value. So this can in fact be ruled out by the programmer.

It's only impossible in safe code. Unsafe cade can violate those rules all day long. You can't guarantee that there's no unsafe code running concurrently.

Concurrently modifying aliased memory (`&` references and pointers) is undefined behavior. Not just in Rust, but in just about any language.

As an aside, alias unsafety in Rust is always UB, even without concurrency.

Re: Rust and the Future of Systems Programming [video]

#378

Post by niketn »

nercht12 wrote: post #88
CodeMage wrote: post #71

Earlier quoted context omitted.

True enough. However, I'm willing to bet that a non-trivial amount of nightmarish code in C++ comes from the language itself. Also, I'm willing to be that a Rust build would be an improvement over a C++ build. As an example, I'm really sick of header files.

Yes and no. Rust adds its own set of hassles. You think building becomes a synch? With Rust, you're fighting the compiler probably more than with C++. I'm sure some game developers would rather have an occasional crash they can fix down the road after their game is published than be forced to make a perfect system the first time. Remember, with game production, it's about time-to-market, not about perfect code.

This might be a large investment for the engine itself, but minimal investment for the game. In my experience, the largest, buggiest and most complicated parts of a game are all contained within the engine.

Re: Rust and the Future of Systems Programming [video]

#379

Post by fabianhjr »

harveywi wrote: post #64

The state of Rust editors continues to evolve [1], but I would be curious to learn more about the editors/IDEs that people are using for Rust development. Any stories or thoughts? [1] https://areweideyet.com/

Spacemacs' Rust Layer (Emacs) https://github.com/syl20bnr/spacemacs/tree/develop/layers/+l...

Re: Rust and the Future of Systems Programming [video]

#380

Post by oconnor663 »

tome wrote: post #274
jstimpfle wrote: post #177

Earlier quoted context omitted.

I haven't experienced that feeling for anything but toy programs. But concerning productivity: fighting the compiler sometimes means abandoning perfectly reasonable (and efficient!) designs just because the compiler doesn't like them. I'm not aware of any type corsets that I think force good designs. In a really clean design mistakes are not terribly hard to fix, even in a language like C. Granted in C they are in so…

> fighting the compiler sometimes means abandoning perfectly reasonable (and efficient!) designs just because the compiler doesn't like them. Citation needed!

One thing that's hard to do in safe code is getting two &mut references out of a HashMap at the same time. (If you know the keys are disjoint.) That might matter to some design somewhere?
Post reply on HN