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

I Hope Rust Does Not Oxidize Everything

gavinhoward.com

Post reply on HN
Print view View original

151–160 of 195 posts

Re: I Hope Rust Does Not Oxidize Everything

#151

Post by sebstefan »

anonymoushn wrote: post #128
sebstefan wrote: post #108

Earlier quoted context omitted.

"despite the GC" and "despite the unsafety" is really putting a lot of weight on that "despite" These are massive problems

I don't think it's so cut and dry. For lots of usecases, using Rust involves writing everything from scratch, because the only libraries available pull in an opinionated async runtime and feel entitled to call the global allocator and various syscalls at times the user cannot control, and these components cannot be swapped out because of fundamental issues that prevent Rust libraries from being composable (unless the…

You're replying to me as if the comment was in a vacuum

It's responding to:

> complexity just for the sake of it,

> lots of pain for minimal gain

> If you need async/await you'll do better in modern .NET despite the GC

> if you need the highest CPU performance you'll do better in C++ despite the unsafety

To this I respond, GC is such a massive problem (I guess you can fill in "for some categories of problems" but I think it's obvious) that some people need to avoid it. And those people often turn to C++, where the "unsafety" is a very big problem.

Re: I Hope Rust Does Not Oxidize Everything

#152

Post by steveklabnik »

kosolam wrote: post #129
bayindirh wrote: post #97

Earlier quoted context omitted.

People love to think that C++ is only used in systems programming, the thing is C++ is used everywhere . FORTRAN is being developed and improved, and new code, most notably in scientific domain, is still being written. What Rust did to C++ is what clang did to GCC. Wake the giant up. Rust will go nowhere, but it's the same for C++. Thinking that C++ will just fade to black is wishful thinking.

Since C++ still evolves and changes, I guess greenfield C++ projects in the future can limit themselves to a subset of the newer improved language thereby C++ will continue living by that way as well.

The C++ community is talking about evolving in the following ways in this space:

  1. contracts
  2. profiles
  3. successor languages
  4. borrow checking
The idea of a "subset of the language" is one that's often talked about, but there seems to be an explicit rejection of the idea of a subset, at least by several important committee members. It's not clear to me why this is the case.

Re: I Hope Rust Does Not Oxidize Everything

#153

Post by falcolas »

jltsiren wrote: post #26
noelwelsh wrote: post #3

Rust is certainly not the last word in systems programming languages, but it's an huge leap forward from C and C++. To be honest, it's a sad reflection of our industry that it's taken this long to get basic safety + ML circa 1975 language features into this niche. If things had turned out a little bit different we could all have been using OCaml for the past few decades.

My favorite hypothesis here is that programming language enthusiasts are too different. They are incapable of convincing the average programmer of the merits of their favorite language, because their way of thinking is different. Arguments they find convincing are not convincing to the average programmer. Progress happens incrementally with small steps. Existing languages get new features. New languages get popular,…

> Arguments they find convincing are not convincing to the average programmer

I think one problem is believing there exists an "average programmer". It's easy to think in averages (or medians), but the reality is that there is no average person, and exactly one median person.

Realizing that every single person is different is important, because you then start to work in more discrete niches. It's going to be much easier to appeal to "programmers who write X in Y with the following constraints" than it will ever be "programmers who write in Y".

Or to bring this closer to the topic of discussion, you'll never convince game developers to drop C++ in favor of rust using the same arguments as you'd use to convince a service developer to drop C++ for rust.

Re: I Hope Rust Does Not Oxidize Everything

#154

Post by steveklabnik »

yencabulator wrote: post #144
rascul wrote: post #132

Earlier quoted context omitted.

This might be useful https://doc.rust-lang.org/reference/tokens.html#punctuation

That doesn't seem to explain 'lifetimes or turbo:: , though.

The page linked for :: explains the turbofish.

That said, you're right that it could use a row for the lifetime syntax.

Re: I Hope Rust Does Not Oxidize Everything

#155

Post by gavinhoward »

rapsey wrote: post #16
usrnm wrote: post #5

Within Rust is a smaller, simpler, safer language struggling to get out

Without a GC? No there is not. You are welcome to try of course, but unless you have a PhD in type theory I doubt your chances.

Author here.

Yao is already fully designed. And while I haven't updated its example file [1] to include everything, it would only be a max of two or three times bigger.

This includes generics, an equivalent to Zig comptime, something like traits but more powerful, a solution to the expression problem, etc.

The solution is structured concurrency.

The only reason I am not working more on Yao is because I worked on it for three years at full tilt (because I constantly refactor to eliminate tech debt), and I am burned out.

But adding a new feature takes only about two hours max; I just add a new client-defined keyword.

[1]: https://git.yzena.com/Yzena/Yc/src/branch/master/src/yao/exa...

Re: I Hope Rust Does Not Oxidize Everything

#156

Post by SAI_Peregrinus »

jltsiren wrote: post #26
noelwelsh wrote: post #3

Rust is certainly not the last word in systems programming languages, but it's an huge leap forward from C and C++. To be honest, it's a sad reflection of our industry that it's taken this long to get basic safety + ML circa 1975 language features into this niche. If things had turned out a little bit different we could all have been using OCaml for the past few decades.

My favorite hypothesis here is that programming language enthusiasts are too different. They are incapable of convincing the average programmer of the merits of their favorite language, because their way of thinking is different. Arguments they find convincing are not convincing to the average programmer. Progress happens incrementally with small steps. Existing languages get new features. New languages get popular,…

I agree, though a big issue is that at some points progress can't happen without breaking backwards-compatibility. If the problem to be solved is that something is allowed which shouldn't be, then backwards-compatibility will prevent progress.

C & C++ allow quite a few things they shouldn't need to allow to accomplish their goals. They'll never stop allowing those things, so they'll never improve in certain ways.

Rust has a strong backwards-compatibility guarantee, and it has run into this issue with its standard library already. The edition system means the language can break compatibility in some cases, but the standard library can't. I suspect this will eventually prevent necessary incremental change, as it has for C & C++.

Re: I Hope Rust Does Not Oxidize Everything

#157

Post by fxtentacle »

ttfkam wrote: post #118
fxtentacle wrote: post #105

Earlier quoted context omitted.

I'd guess most services where performance matters are in the background. And this particular C++ service is only accessible over internal LAN, to be used by other back-end servers. I agree with you that if ha-proxy and nginx didn't exist yet, they would be prime candidates for being implemented in Rust. But now that they already exist and reliably work, I'm not sure there is enough pain for them to get replaced anyti…

> I'm not sure there is enough pain for them to get replaced anytime soon. https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t... https://blog.cloudflare.com/pingora-open-source

That sounds like a great project :) but

1. "Pingora is Not an Nginx Replacement" https://navendu.me/posts/pingora/

2. you still put it behind ha-proxy https://github.com/cloudflare/pingora/issues/132

3. https://github.com/cloudflare/pingora says "Pingora keeps a rolling MSRV (minimum supported Rust version) policy of 6 months." so for anyone who dislikes the "constant upgrade treadmill", this won't help much.

So my summary would be that Pingora is a great Rust library which one day might be used for replacing nginx and/or ha-proxy.

But the main advantages of Pingora - which are the reason why CloudFlare is using it now - have nothing to do with Rust. Obviously, a software architecture designed in 2022 can take advantage of modern hardware in a way that an architecture from 2004 cannot. (Yes, nginx is that old). Intel's TBB library brought "work-stealing" to C++ around 10 years ago. The other big improvement in Pingora is moving from multi-process to multi-threading pools. Again, C++ had thread pools for years.

So Pingora is probably great and it's written in Rust. But the business benefits that it brings aren't coming from Rust. They are coming from the fact that it's a modern architecture.

Re: I Hope Rust Does Not Oxidize Everything

#158

Post by yencabulator »

steveklabnik wrote: post #154
yencabulator wrote: post #144

Earlier quoted context omitted.

That doesn't seem to explain 'lifetimes or turbo:: , though.

The page linked for :: explains the turbofish. That said, you're right that it could use a row for the lifetime syntax.

If you know where to look, you will find it. If you don't, you don't.

For someone new to Rust, I don't see why you'd expect them to expect to see a "path separator" between the function name and it's call in x.collect::>(). A more likely path to discovery is via the Generics link (discovered from " syntax in context of const values, and that isn't actually very helpful for understanding.

Post reply on HN