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

171–180 of 195 posts

Re: I Hope Rust Does Not Oxidize Everything

#171

Post by steveklabnik »

fxtentacle wrote: post #157
ttfkam wrote: post #118

Earlier quoted context omitted.

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

> But the business benefits that it brings aren't coming from Rust. They are coming from the fact that it's a modern architecture.

This is moving the goalposts. Your original post said

> I'm not sure there is enough pain for them to get replaced anytime soon.

Yet, here one of them is, being replaced at a company that powers ~10% of the traffic on the Internet.

But beyond that, your links:

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

Here's what the start of the post actually says:

> Think of Pingora as an engine that can power a car while you have to build the car yourself. Nginx is a complete car you can drive. River is a faster, safer, and an easily customizable car.

The title is being pedantic for effect. It doesn't say what you say it's saying.

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

This is an issue opened by someone on an open source repository. They aren't talking about how Cloudflare itself uses it, but about how they want to use it.

> so for anyone who dislikes the "constant upgrade treadmill", this won't help much.

Similar to above, this is moving the goalposts. Sure, that might be true, but it's unrelated to the original topic.

> But the main advantages of Pingora - which are the reason why CloudFlare is using it now - have nothing to do with Rust.

This is not what Cloudflare themselves would say. They chose Rust for very specific reasons when building Pingora: (repeating the link from above) https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t...

> We chose Rust as the language of the project because it can do what C can do in a memory safe way without compromising performance.

Cloudflare has been a vocal proponent of Rust for years now. Many years ago, they suffered a very serious bug, CloudBleed, that Rust would have prevented. And so they've been using Rust instead of C and C++ for a long time.

They of course would also very much agree that the architecture matters, but that doesn't mean that the implementation language doesn't matter either. If they chose to implement Pingora in, say, Ruby, that wouldn't have accomplished their goals.

Re: I Hope Rust Does Not Oxidize Everything

#172

Post by jltsiren »

throwawaymaths wrote: post #123
jltsiren wrote: post #26

Earlier quoted context omitted.

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

> Existing languages get new features That's how you wind up with C++

Or English.

A lot of people used to advocate for using their favorite ancient / artificial languages in international contexts and for communicating important matters. But somehow the C++ of natural languages became dominant.

Re: I Hope Rust Does Not Oxidize Everything

#173

Post by neonsunset »

anonymoushn wrote: post #168
sebstefan wrote: post #151

Earlier quoted context omitted.

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

I don't think so? My reply is that if you can't afford to stall for a really long time, like dozens of frames at 60hz at least, then your choices are often to deal with unsafety in C++, to deal with the GC in .NET, or to write everything from scratch in Rust (including many things for which you would typically use libraries) because idiomatic Rust and the associated ecosystem won't solve your tail latency issues. The…

You can deal with that in .NET the "C++" way too, given that you can write abstractions with structs and generics instead of objects, use malloc and stackalloc, and more. You are not married to GC heap, despite some suggesting otherwise.

Generally speaking 60hz is not a problem but it starts to matter more with the popularity of high refresh rates. There are much more extreme cases like 1000hz game loop in OSU!, which pretty much has to use the same techniques as realtime systems that utilize GC-based language: https://github.com/dotnet/runtime/issues/96213#issuecomment-...

Re: I Hope Rust Does Not Oxidize Everything

#174

Post by hackingonempty »

simon_void wrote: post #72
mstipetic wrote: post #25

Earlier quoted context omitted.

I’m super into elixir now and don’t see myself going anywhere else. Is gleam really that good? What are the advantages? Can I use liveview with it?

As far as I know Gleam is the only strongly typed language on BEAM, which is important to me since I don't like dynamically typed languages. But of course Elixir gets optional types now.

There is also:

Purerl - Erlang backend for PureScript, a few folks are using this in production - https://github.com/purerl/purerl

Caramel - Ocaml for Beam, seems dead - https://github.com/leostera/caramel

and more probably dead projects at https://github.com/llaisdy/beam_languages

Re: I Hope Rust Does Not Oxidize Everything

#175

Post by estebank »

yencabulator wrote: post #147
zkldi wrote: post #36

I'll bite: What specific parts of rust syntax do people find so ugly? I keep hearing this from decent chunks of people who don't write rust, but the language doesn't seem that far off C to me. It's certainly no haskell.

Here's my litmus test: read the source aloud. Over the phone to a person who doesn't see your screen, if needed. Did you have an obvious, understandable, and simple pronunciation for everything, that wasn't just reading ASCII characters one by one? Now pretend the other person is a smart and experienced programmer, but has never heard of Rust. How would they write down what you just told them, without any idea of Rus…

    function max with type parameter T
    with arguments
    a of type T and b of type T
    and returns a value of type T
    where T implements trait PartialEq
Vs

    fn max(a: T, b: T) -> T where T: PartialEq

Re: I Hope Rust Does Not Oxidize Everything

#176

Post by estebank »

Avamander wrote: post #45
zkldi wrote: post #36

I'll bite: What specific parts of rust syntax do people find so ugly? I keep hearing this from decent chunks of people who don't write rust, but the language doesn't seem that far off C to me. It's certainly no haskell.

Fishtail, lifetime and closure syntaxes are rather ugly. Just specifically when combined in practice, not alone in isolated examples.

For what is worth, the turbo fish falls from the decision to use for generics (for familiarity for C++ and Java developers) and a desire to make the syntax non-ambiguous (side stepping the C++ problem of having to delay determining if something is a type path or a comparison, mixing parsing and name resolution).

Re: I Hope Rust Does Not Oxidize Everything

#177

Post by yencabulator »

estebank wrote: post #175
yencabulator wrote: post #147

Earlier quoted context omitted.

Here's my litmus test: read the source aloud. Over the phone to a person who doesn't see your screen, if needed. Did you have an obvious, understandable, and simple pronunciation for everything, that wasn't just reading ASCII characters one by one? Now pretend the other person is a smart and experienced programmer, but has never heard of Rust. How would they write down what you just told them, without any idea of Rus…

function max with type parameter T with arguments a of type T and b of type T and returns a value of type T where T implements trait PartialEq Vs fn max (a: T, b: T) -> T where T: PartialEq

Limiting examples to a subset of Rust syntax will produce more readable answers, sure. You have no lifetimes and no borrows, and very limited generics.

Re: I Hope Rust Does Not Oxidize Everything

#178

Post by rustbucket »

pjc50 wrote: post #103
fxtentacle wrote: post #91

Earlier quoted context omitted.

This is not meant as a critique of you, but your comment includes a hint of what bothers me with some Rust evangelists. I would call it "slightly entitled over-optimism". I have a C++ service running in production. It's been in production for 10-ish years with minimal updates. It'll probably keep running just fine for the next 10 years. With that in mind, "the onus on anti-Rust people is now to demonstrate a better l…

> I have a C++ service running in production Is it on a network (or other) security boundary, exposed to attack from the Internet? Is it deployed on millions of machines worldwide? _Those_ are the primary targets for replacement, because the networked environment is a very hostile place, and people are fed up with the consequences of that. Regular announcements of "sorry all your private data has been leaked lol". Co…

[dead]

Re: I Hope Rust Does Not Oxidize Everything

#179

Post by rational_indian »

simon_void wrote: post #148
rational_indian wrote: post #34

Earlier quoted context omitted.

That's the problem with C. It cannot have a sane cargo like system. The language is not built for writing libraries. There is a reason why everyone keeps reinventing the wheel when it comes to datastructures in C. Where is STL for C?

you could use the Zig build system as your C build system. See https://zig.news/kristoff/make-zig-your-c-c-build-system-28g...

Cargo is just half the story. The other half is rust itself. It is an excellent language for writing abstractions.

Re: I Hope Rust Does Not Oxidize Everything

#180

Post by weinzierl »

anonymoushn wrote: post #135
weinzierl wrote: post #66

> First, the syntax. It’s ugly. TO MY EYES! Beauty is in the eye of the beholder, you can't please everyone and you should not exceed your weirdness budget[1]. The decision to please the C++ crowd so much (mainly manifested in later syntax related decisions) would not have been my preference, but it makes sense and there could have been worse decisions. > Second, Third, Fourth, Fifth I feel a lot of this async critic…

> I feel a lot of this async criticism has more to do with how async is used than with Rust itself. Maybe it would be good to have more crates that don't used async or even depend on tokio, but in the end this is on us as a community. No, this is a language design issue. In Lua or Zig the easy way to write a library that speaks websockets produces a library that works with synchronous or asynchronous i/o and with the…

This is being worked on: https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-ge...
Post reply on HN