Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

961–970 of 1001 posts

Re: A Sad Day for Rust

#961

Earlier quoted context omitted.

I don't like contempt culture either but there's a balance to be made here - if you let everyone do everything and encourage them all as special snowflakes that can't create anything crappy, a community will also go to shit. In this case it does sound like people initially were very nice and tried to give the author very polite suggestions on improvement, and it was only after the author being extremely dismissive[1]…

> initially were very nice and tried to give the author very polite suggestions on improvement, and it was only after the author being extremely dismissive[1], not admitting to his own flaws, not wanting to learn from others, and abusing his own power in shutting down valid discussion, that things turned nasty. Yes, nice comments such as >seriously? Please just stop writing Rust. You do not respect semver, you do not…

That was after the author was extremely dismissive with "this patch is boring". Seriously, who says that??

Re: A Sad Day for Rust

#962

Earlier quoted context omitted.

> “ 2. Open source participants are volunteers and owe you nothing.” Absolutely not. They are compensated with prestige, enjoyment, decision-making power, future employment rewards, and sometimes even money, all of which was their choice to pursue through their labor and time spent on the open source project. The users of open-source projects, upon which the projects themselves depend, are also not obligated to anyth…

>> “ 2. Open source participants are volunteers and owe you nothing.” > They are compensated with > prestige, That seems associated with the popularity of a project which is largely outside the control of an author. So: how could one publish code (just in case it's useful to somebody else, which seems to be a nice thing to do) and opt-out of the popularity contest? > enjoyment, People can have the same enjoyment with…

> “ That seems associated with the popularity of a project which is largely outside the control of an author.”

Huh?

Re: A Sad Day for Rust

#963
post #519

Earlier quoted context omitted.

People have a right to become angry. They absolutely don't have any right to override the will of a project maintainer. By the way, isn't this a great opportunity? The code is open. Fork it. Seize the day. Become a better maintainer, and build a community around your fork. Ensure the community needs and wants are aligned with yours. Steer that ship. Gain prestige. And money, maybe. If someone is a bad maintainer, the…

> People have a right to become angry. No. You have a right to be annoyed , and then fork the project if you want. You do not have a right to become angry unless you're paying for it.

No, you do have the right to be angry, even for something you’re not paying for. Absence of a financial agreement does not mean dissolution of basic community norms.

Re: A Sad Day for Rust

#964
post #697

Earlier quoted context omitted.

> “ 2. Open source participants are volunteers and owe you nothing.” Absolutely not. They are compensated with prestige, enjoyment, decision-making power, future employment rewards, and sometimes even money, all of which was their choice to pursue through their labor and time spent on the open source project. The users of open-source projects, upon which the projects themselves depend, are also not obligated to anyth…

> Seems everyone believes there is large team behind actix with unlimited time and budget. (Btw thanks to everyone who provided prs and other help!) For example, async/await took three weeks 12 hours/day work stint, quite exhausting, and what happened after release, I started to receive complaints that docs are not updated and i have to go fix my shit. > enjoyment Riiight

I think your quoted comment just proves the point. Without community complaint / critical response, there isn’t incentive for the implementer to do the thing the community needs.

If you do X for enjoyment and it actively hinders some other group because they needed Y and using personal priorities to rank addressing X instead of Y is an egregious violation of community norms, people will take action to bring down the enjoyability of doing X and raise the enjoyability of doing Y, like complaining about X and thanking you for Y.

Re: A Sad Day for Rust

#965

Earlier quoted context omitted.

> “ 2. Open source participants are volunteers and owe you nothing.” Absolutely not. They are compensated with prestige, enjoyment, decision-making power, future employment rewards, and sometimes even money, all of which was their choice to pursue through their labor and time spent on the open source project. The users of open-source projects, upon which the projects themselves depend, are also not obligated to anyth…

I didn't think I would see a "I will pay you with exposure" argument.

Why? That’s the most likely type of reward you would get from a successful open-source contribution, and should be factored in to consideration of what is a priority.

Re: A Sad Day for Rust

#966
post #414

Earlier quoted context omitted.

Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients: https://medium.com/@shnatsel/smoke-testing-rust-http-clients... Skimming this, the author doesn't really like any of them. Note, however, the long list of issues reported at the end of the article. Here is the first one I clicked on: https://github.com/algesten/ureq/issues/24 The maintainer is happy to get the report, and has an exchange w…

> Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients: Interesting. I'm being led to believe that the actual problem lies in HTTP itself: it is too convoluted to be safely implementable and should be replaced with something else for security-critical applications. (Or in general.)

But this is a problem Rust creates for itself. HTTP is safely implementable in most modern languages without any unsafe code because they're all garbage collected. For instance, Java has a mechanism also called Unsafe that lets you bypass the language's safety features, but I've never encountered an HTTP client that uses it because performance is fine without that. And the JVM developers have been working for years on safe but performant constructs that can replace the uses of Unsafe that do exist in the community, mostly, cases where very precise control over memory and concurrency constructs are needed in high performance servers.

Re: A Sad Day for Rust

#967

I love Rust and use it daily. Unsafe isn’t something you live without, you just avoid unless there’s a decent reason. Setting aside actix-web, the community has this really annoying obsession with not using unsafe anywhere. You’re not replacing decades of computing overnight, though, and it’s not the end of the world if it’s there sometimes. It often feels like newcomers and zealots preaching the unsafe issue, too. I…

I think the issue with Rust and unsafe is that people can't really handle and don't really want ambiguous shades of grey. Rust is harder to use than C or even C++, let's put that out there at the start. It expects a high degree of developer effort and skill, in return it gives memory safety without a garbage collector.

But if the Rust ecosystem has developed in such a way that most popular libraries don't actually give you guaranteed memory safety, then this quid-pro-quo breaks down. Now you're making a lot of effort to use the language and in return you get ... maybe sorta safety, some of the time? That's a rather difficult tradeoff to weigh up. How unsafe is the Rust ecosystem, really? As a Rust outsider I had thought it was used only very rarely and mostly in the standard library, by way of analogy to the Java ecosystem where that's the case. From this situation it sounds like it's widely used, and often for unclear reasons. So does using really Rust deliver the advertised benefits?

The fact this question even has to be asked is going to upset the Rust community because Rust is like most non-JVM languages, it has very poor interop with other codebases which makes it reliant on building a large community to be sustainable. The Rust community has to make Rust as attractive as possible for its own competitive survival. High profile libraries that undermine Rust's only value proposition is therefore a self-destructive trend. Actix Web gets great TechEmpower benchmarks, but at the cost of undermining that whole community's marketing pitch. Not surprisingly things get heated.

As for Reddit, I don't think that's the problem. Reddit is just threaded discussions with a large userbase. There are plenty of languages with active reddits and way less drama than Rust seems to have. Java, Kotlin, C++, Swift etc all have big subreddits and all have had zero community dramas that I remember in recent years. The issue is pretty clearly something related to Rust and its userbase. My guess is it's a combination of small size, lack of interop and the Mozilla leadership setting bad examples. There was a huge Rust drama a few years ago where they went ballistic and censored an entire discussion from Reddit because they appointed as their community manager a feminist ("kill all men" being one of her slogans) who had just finished creating a massive idpol drama in the NodeJS community, and not surprisingly the community didn't like it. That sort of immature move is something you don't see from more professionally managed languages.

Re: A Sad Day for Rust

#968

I've written a lot of Rust code that's in production in web, messaging and telephony contexts. I considered using Actix early on, but as soon as I saw the large amount of unsafe code, I stopped considering it at all. I did not go on the Internet and try to convince other people not to use it. I did not complain at the maintainer that he should manage his project differently. I just didn't see why a library doing what…

What do you use now? Warp?

I've been in the process of switching to tonic for the last few of weeks. Based on hyper/tower and has async/await support. It's a gRPC server rather than HTTP, so I've been using it with grpc-gateway to provide an HTTP OpenAPI v2 interface.

It has automated quite a few things I found dull to do in other server frameworks, from the gRPC .proto file I can generate:

- Rust server request/response types and request handler stubs. - grpc-gateway files and an OpenAPI v2 json spec. - Client side typescript types and request/response handlers from the OpenAPI spec.

So now the process of adding a new endpoint is much less time consuming and involves writing less repetitive and error prone code. As mentioned above I've only been using it a few weeks but so far it has been great, easier to use than actix-web and felt no less responsive.

Re: A Sad Day for Rust

#969

I have been complaining about Rust's "unsafe" for years. There's too much "unsafe" code because there are things that you either can't express, or are very hard to express, in safe Rust. I've pointed out partially initialized arrays and backlinks as key trouble spots. Both are potentially fixable. I've gotten back complicated excuses for not dealing with these design problems. There was a serious denial problem in th…

I’m replying to your message using software written in C, so do you think that it might be a little bit unfair to call it “broken”? I suppose I’d agree if you’re making a general argument that most of the software we use is broken to some degree, but it has an entirely different meaning to directly tell someone “Your library is broken”.

Are you? All web browsers I know of are written in C++ and always have been. In modern C++ you don't use char* to mean "pointer to byte array of unknown size", you use std::vector. Moreover Chrome actually uses garbage collected C++ (they call it Oilpan).

Re: A Sad Day for Rust

#970
post #892

I've written a lot of Rust code that's in production in web, messaging and telephony contexts. I considered using Actix early on, but as soon as I saw the large amount of unsafe code, I stopped considering it at all. I did not go on the Internet and try to convince other people not to use it. I did not complain at the maintainer that he should manage his project differently. I just didn't see why a library doing what…

I'm curious what you'd recommend instead for async pgsql requirements as a Rust web framework. Actix seemed interesting, but I didn't know about the masses of unsafe. These too eliminate it, because it'd be able to crash/break a cluster that uses deliberate unsoundness for its serialization/deserialization needs in the vain of speed (timely-dataflow), allowing memory issues to spread (at least in theory)... I thus ca…

We use tokio-postgres. Previously we had our own connection pool implementation, but we recently switched to deadpool.
Post reply on HN