Challenges for Rust
ncameron.org
ncameron.org
Edit: also, "features" are sometimes a headache. Just spent ~one day trying to figure out how to build cross-platform static binaries when bunch of libraries depend on openssl-lib. Ended up using "features" to disable it and enable "rusttls" instead, but had to also disable the default features and figure out exactly which ones I needed.
2) spawn_blocking is your friend.
Yeah, that's the problem :) Not all libraries I want to use, uses Tokio. What about those? Was that really the plan with async in Rust, that I'll get to chose between two ecosystems and if I chose one, I cannot use the other?
Then just put Tokio in the standard library so there is at least some resemblance of consistency in the ecosystem.
Same story can happen with time/decimals/database drivers.
However pulling it into std would probably kill the library because backwards compatibility guarantees.
For example, Tokio has the concept of "unstable" features, which have stronger stability guarantees than Rust nightly. First, you can use them with the stable rust compiler, second we guarantee that unstable features will not break across patch releases. This may seem small, but it lets us experiment with new functionality and get real world usage. Many of our users cannot use Rust nightly but can use Tokio unstable features.
I didn't imply anything about Tokio. I just wish some libs didn't need to be bikeshedded (like async runtime, time, decimal, etc.)
AFAIK there are no libraries that aren't compatible with tokio or without a direct tokio equivalent. The sad reality is that tokio dominates so hard that it's pointless to even try any other runtime.
The lack of interoperability between runtimes creates a winner-takes-all situation, which creates a vicious cycle for async-std: fewer people use it, so it has fewer crates supporting it, so it's harder to write software depending on it, so fewer people use it.
If you're bothered by the runtime fragmentation situation, use tokio. Fragmentation doesn't exist for tokio users (there are 10 tokio crates for every 1 async-std crate).
One big usability improvement for features is the addition of cargo-add which can be help in editing features with its table of whats activated.
The next is making it more explicit which optional dependencies are optional features but this requires crates to update to rust 1.60 and make some changes.
Something we are discussing is changing `defaut-features = false` and re-adding what you want to opting out of each default feature. With the current behavior it can be a pain to re-enable what you want and crates can't move existing behavior to a feature without a breaking change.
I’d be generally in favor of such a change as this is what I use for all of my projects when I start out. I find it much more comfortable to deliberately opt in to things that I need as I find that I need them.
The biggest pain point I’ve experienced is for features that are performance based when I am writing an application instead of a library. It’s hard to know that those exist, and that I probably do want them, I just don’t require them.
This made feature discovery much easier for me. Previously, I would often inspect the Cargo.toml for crates I wanted to use to see what features might or might not be useful, now it's all done with 'cargo add'.
So Rust has the same problem as C# has that mixing async/sync may have some quirks and edge cases?
and you have lengthy guides how&when to use one method[0]
[0] https://devblogs.microsoft.com/dotnet/configureawait-faq/
I think that tooling helps with stuff like this. I can’t imagine writing Rust code without the help of rust-analyzer but the training material you see always seems to focus on the language and being agnostic about tooling. Editors and their extensions are so important when you are learning a language but newbies are expected to stumble upon the right ones by chance. It seems to be considered bad taste to steer beginners in one direction or the other when it comes to tooling.
> “There are a lot of crates and finding the right one for the job requires a lot of effort or being very involved with the community.”
My approach to to this it to look at the download counter (but then you need to know what to look for) and to ask friends in the community which kind of sucks for beginners. I’ve never really seen how I could benefit from something like copilot but if it could analyse my code and tell me that some of it could be replaced by calls to a popular crate then I would find that useful. As long as it wasn’t intrusive and didn’t make me feel bad.
For example, you find a crate that seems to do what you need. 1) are you sure it has high enough quality? 2) Is the license compatible with your needs? 3) What long term guarantees exist for API stability? 4). Is it actually maintained?
All of this needs checking off. If you don't do them, your project will be a sprinter, not a marathon runner, as dependency addition is cheap but dependency maintenance is a slow burning major cost.
The transitive dependencies make it worse, as they need independent vetting.
This cost is acceptable for major libs, but the zillion 100-line left pad ish libs have to go.
I'd love to have some standard rust guarantee declaration, including at least the declaration of the author's intent. You won't maintain something or won't stabilize an API? Fine, your project, your rules. But don't make me hunt for that info.
I have no problems with major libraries, and I understand why rust is sometimes slow to stabilize things, even if ut is sometimes frustrating to see the thing you need in there but not ready for prime time.
But minor libraries or deep dependency chains are another thing.
So my hope is to have a few big libearies, subscribing to some standard of stability. You can then make an informed choice between the exciting bleeding edge or the boring stable world.
I need to rm -rf node_modules regularly. Cargo works every time.
Node makes breaking changes regularly and intentionally. Rust releases are checked against all crates-io crates to avoid breaking anything.
JS has dynamic typing, monkey patching, and a drama around modules. Rust has very clear and strict library interfaces.
Cargo is much more reliable than the npm client. Has lock files that work. Left-pad scenario has been fixed at npm long time ago, and has never been possible at crates-io.
With 3rd party libraries is hit and miss regarding cross platform portability.
The basic things have been solved by libraries that everyone generally prefers to use.
Wanna write a JSON parser? You can, but there's a library for it. And so on.
For the purpose of learning the basics, you can either disregard the library, or you can write an app that uses a bunch of libraries.
The nice thing about well-solved problems in libraries is that you don't have to learn how to write those things if you don't want to
I tried Rust, wrote a raytracer and a GameBoy emulator to learn the language. But I still find it VERY hard and slow to write on a daily basis. You can't just test anything with it. Either you thought the whole project well at the beginning, or you'll need to rewrite everything from the start.
I understand Rust is meant to be clean, no undefined behaviours, everything explict. But as a C programmer, that's just the opposite of what I am accustomed to.
Are there documentations, books, tutorials, whatever, that explain to someone like me how Rust works from a C expert's perspective ?
(To be clear, my brain is NOT a clean slate, and I think we are legion. I've spend sometimes days to understand how to clear a Rust compiler error, and it ends with the copy of a whole megabyte of a structure because I don't think how I should think in Rust)
It’s almost as if you need to completely unlearn behaviours before you can learn the “the rust way”.
I think the standard path is this “book” (GitHub repo): https://github.com/nrc/r4cppp
In a way it is like meeting an old friend, a kind of Ada/Modula-2/Object Pascal coupled with the borrow checker and more curly friendly syntax.
You are so lucky. I used around +12 langs, professionally, and learning Rust was the biggest slap on the face I ever faced.
The major breakthrough on my learning was understand that Rust make A LOT of things easier, but start doing a fully formed system/app was not the way.
ie: Get to know the real small stuff.
Rust is: structs, enums, traits, iterators.
Then learn the idioms:
https://rust-lang.github.io/api-guidelines/
The most key thing about Rust is that everything revolves around trait and trait composition. For example. if you look at:
https://doc.rust-lang.org/src/alloc/string.rs.html#366-368
You will wonder "where is all the functionality to deal with Strings???".
And the answer is that that is not on Strings, but around several traits. Then you start seeing that traits everywhere, and suddenly, you see that learn X here means you already know how do Y there.
Then, you start doing apps/systems, and now it will fly!
And based on all this copying a megabyte might be perfectly A-OK. Computers are fast, life is short, keep structs simple because they can get problematic (https://matklad.github.io/2020/12/28/csdi.html).
That's actually a good start for just making things work but yes, maybe you can try to optimize that away much as you would in C. E.g. you can use std::borrow::Cow<> to abstract across "owned" and "borrowed" data, so that copies only happen when necessary.
Looking at job posts the language has minimal traction so why all this fuzz? Are there really that many people willing to throw in their time and energy to a tech stack that won't pay the bills? Or is it just a critical mass of fans creating all that fuzz? I don't get it but it really tires me out and I believe I'm not alone in it.
Anyway. To the point. Rust biggest challenge IMHO is job market. Untill it justifies the time investment for the millions of us that need to pay the bills it simply is not worth the effort. Being a dificult language to work with (as in at the other end of niceness like say Ruby) it is not even justifyable as a hobby lang.
I guess atm it's more of virtue signalling really. I write rust therefore i must be a good dev. Yeah. So are the haskell guy next door.
Anyway. Just my 2 cents.
Obviously, there's a growing number of people who use Rust professionally, but that's not even the point to argue. Why would people need to "justify" their hobbies? Of course, it's perfectly fine if you don't care about the craft beyond "pay[ing] the bills". But others might, especially on a site called "Hacker News". Maybe let them discuss stuff they find personally interesting, whether those interests are "justified" according to your opinion or not.
There may not be a ton of jobs compared to making web sites. But that's a totally different world from where Rust is strong. Deep in the stack, Rust is a pretty big player already and will be even more important in the future. People working down there would profit from learning Rust, not just to be attractive for new jobs, but because they will most likely find uses for it in their current job.
Rust excites me because programs written in it can have similar memory safety to GC'd languages, but have similar runtime characteristics to C++ programs. I can use it to solve the same problems I previously needed C++ to solve, and also new problems where bullet-proof memory safety is a requirement.
I've been a quiet cheerleader for the language for the past 10 years because it's been the only language with community momentum that fits the niche that I care about. But I won't be hurt if some other language with similar runtime and safety characteristics to Rust replaces C++; I'll consider that a win.
I bitch about it because it's fucking annoying, but that didn't stop me from learning it well. My principles come above being a sycophant, but not above knowing the compiler stack on the language I'll be mostly writing in 3-5 years.
Do things like appealing inclusivity affect the quality of a programming language? To turn that issue into an issue at all and then prioritizing it feels like transitioning into PR and marketing, jobs fit for organizations that are "foundation" and have "boards of directors" and other bureaus.
Again, these sort of things are all new to me. I don't know what things were like in the programming world last year, let alone 20 years ago.
Can someone with intimate knowledge of Rust or other high-profile languages interpret what I'm saying and clarify it for me? Thank you..
Some of Rust's best contributors are queer, and likely would have left if the community had lower standards.
On the internet, nobody knows you're a dog. If you want to do something cool, I don't care if you're male/female/nonbinary/black/... You can be an purple with orange speckled snail, for all I care.
Now I've seen how e.g. some female gamers were treated, and it wasn't pretty. You should be able to play a game online, without being invited for sex or screamed at every few minutes. That kind of behaviour is very clearly not OK.
But neither is it OK for people to scream their sexual preferences around and demand my attention for it. Go ahead, fuck with who you want, but leave me out of it. Give me the permission to not care about your gender identity. Starting to scream at people because they think 'people who menstruate' is ridiculous, that's also not OK.
So please, do something cool, react if you notice something not OK. But also care for individuals, leave room for multiple opinions and don't start a witch hunt for any minor or even imagined faux pass. Live and let live.
There is also a huge amount of imposter syndrome kicking about. It's important to garden new contributors of all kinds to make sure the best people can grow. While I have no data, I'd easily believe that dogs and snails have way more and severe imposter syndrome than cis white hetero males. So if we do want to make sure that all kinds of people can break through there's little harm in keeping tabs on the issue.
There are probably other impediments to contributing that I don't even know about. They should also be found and addressed, right?
In the 50s, 25% of software engineers were female; now, it's, what, 3%. Why is that?
The "meritocracy" position focuses on who can produce the best code _now_. What if we take a longer view?
I would love it if we planted the idea in 9-year-old girls' heads that Computer Programmer is a job they could do. That way, in 15 years, we'll have a broader talent pool.
I'm skeptical that is quantifiable. But would the "meritocracy" advocates accept some level of token hiring, at some level of reduction of quality now, in search of a greater meritocracy and greater quality in future?
Of course everyone should be able to choose the job they like. I am not going to purposely plant any ideas in anyone boy or girl. Let them sample everything and choose what they like. I am not going to push them.
And a level of token hiring to have more females? Sorry, that's nonsense. Why would someone female not be able to be the best? If you're scared of bias, put some woman in the intervieuw and ask them to review candidates. I've seen genius level woman who would program circles around most males(and most females). It is insulting if you think woman need lowering standards before they have a chance, even short term.
BTW, the biggest producer of 'female equals dumb' style jokes was a female programmer in my last job. Most of us males just ignored her when she started like that.
In the UK, women aren't taking CS degrees. That's why I mention pedagogy. There's something in my country's culture that is planting the idea that girls don't code. "Planting ideas" is also the basis of teaching - it doesn't imply "pushing them" and it isn't opposed to "letting them sample".
I haven't come across any female devs at all in my company. We have diversity of skin colour and sexuality but not sex. So we haven't got any females to sit in on technical interviews.
Please, don't straw-man me as suggesting that female devs cannot be the best. My point is that there _aren't any_ female devs, and it looks like it's because girls _aren't interested_ in becoming devs, and here at least that is due to social conditioning afaics. You really missed my point there.
Keen to know what's different in your locale.
But there is a bigger movement around woke/lgbt, especially in the USA, and political parts of ict groups are very much subscribers to this view. I think it's weird for rust to even have stats about it, just like I would think rust to be weird to have stats about who is a coffee/thea/cola/nonternary drinker. It should not be relevant.
Feel free to write about your preferred drink in your Twitter profile. If you personally come over to me, I'll make sure to have that drink in my house, otherwise I'll perform the noble art of not giving a fuck.
Rust community is small and thus mostly welcoming, plus there were lots of non-binary programmers.
Did that change while I wasn't looking?
> Rust's diversity numbers are terrible. They are even terrible compared to the tech industry, which is terrible to begin with.
I guess they have real numbers about it, but did not share.
I am also surprised because the Rust Foundation staff itself seems pretty "diverse"[1] (at least the male/female rate... nearly everyone seems white though), yet it seems they still didn't manage to make the Rust community as diverse. I guess you can't just "wish" things into existence... systems programming has always been (mostly white/asian) male-dominated and Rust can't change that by itself.
See here for more information: https://old.reddit.com/r/rust/comments/vhvb4m/2021_annual_su...
The FLOSS community, by and large, is also known to be a lot less diverse than the tech industry as a whole. I'm pretty sure that both are significant factors. OTOH, it's quite likely that Rust is already doing better than the C/C++ community on these metrics, which is perhaps the more meaningful comparison.
The organization, sophistication, and effectiveness of the Rust marketing vehicle would trivially win political contests as big as a United States Senate race.
vi/emacs, c/c++/java flame wars are as old as dirt, just like left/right politics in any polity you care to name with ballot stations. But where I live in the US, e.g. MAGA (or it's prototype "Tea Party") was Something New, and those that failed to realized that we'd changed paradigms got, pardon my francais, fucking clobbered.
The various books are great free learning resources, the auto generated documentation is top notch, the compiler is incredibly friendly.
I feel like the few conflicts got resolved pretty well.
A percentage of people leaving OSS unpaid work is to be expected.
There is just a brief mention of diversity in the article - but please don't bring diversity into this. We need qualified and dedicated people at the helm, not gender / race tokens.
We need diversity of opinion not people - and the conflict we had are a proof we have plenty of that.
But now a set of Americans seem dedicated to shoehorn it in. It seems bizarre that everyone from Donald Trump to King Charles to a Polish farmer are seen as identical and homogeneous in their race-based politics as just "white".
My comment was more an observation on how others act, rather than how I act.
Times change, but some problems remain.
Obviously it's not the Rust (or broader IT) community's sole responsibility to solve every kind of social ill, but it seems enough people have experienced problems that show that there's room for improvement.
Though it's not something that is a homogeneous problem. So it's unsurprising that a large part of the community just doesn't see it.
I agree. Its like the whole "master/slave" brouhaha.
The Americans just became obsessed over renaming anything anywhere that used the term.
Meanwhile, the rest of the world doesn't make dumb extrapolations. They understand that calling one server "master" and one server "slave" does not mean you're some sort of right-wing racist nutter.
I'm sure if you took at trip to the African continent and visited various countries and asked those who actually live there about it, they'd much rather you talk about how they can get more financing for their organisation, how they can get more robust and affordable internet connectivity .... or indeed how they can get a COVID vaccine, especially seeing as the patents were not lifted and the promises of donations never materialised in any significant number.
But no, the Americans are too busy with political correctness and willy-waving sending billionaires and their rockets into space.
(Though they like to parade open source's impact as their impact https://socialimpact.github.com/ )
However the community did it because it was asked to do it by people. It was fairly easy to do, it was clear and well defined. So why not? The ask was very likely sincere, even if it was useless in the grand scheme of things. Should the community (git maintainers, various project maintainers) score every request based on its social impact or take requests at face value? (I'd argue that they have to do a little bit of both, and if something is a low-hanging fruit, eg. big impact low effort, then why not do it?)
My 7 year old niece looked over my shoulder as I was writing this and said "kill!?" with a look of disgust! Disgust! I suspect that this reaction is typical of many females getting started in computing. Could it be a small part of why there are so few women in computing?
My niece gets very excited when she sees me use commands she knows like ls, cd, cat (especially cat!). The fact that she could grow up to become a DBA and won't have to talk about "dumb slaves" is something I celebrate. It's not nearly as important as <insert whataboutism here> but it's progress.
(If you or someone you know has been victimised because they're comfortable with existing terminology then I'm sorry for that, really. If you feel that changing terminology is a waste of time that is OK. If you don't want to rename your branches then no-one should give you a hard time about it.)
> 2 Diversity and inclusion
> Despite being known for having a welcoming and friendly community, Rust's diversity numbers are terrible.
It is crucial to be human and treat everyone with 23 chromosome pairs as our proper theological equivalent, yes.
However: Diversity, Equity, and Inclusion (DIE) is a Maoist hell[1] that we all must either reject or be pulled down into.
You are cautioned.
[1] https://amgreatness.com/2022/09/16/the-maoism-of-wokeism/
According to https://en.wikipedia.org/wiki/List_of_organisms_by_chromosom..., the following qualify for that:
- https://en.wikipedia.org/wiki/Reeves%27s_muntjac
- https://en.wikipedia.org/wiki/Nilgai
- https://en.wikipedia.org/wiki/Parhyale_hawaiensis
More importantly, not all humans have 23 chromosome pairs (https://en.wikipedia.org/wiki/Aneuploidy)
OK, your pedantic exception, too. Yuh got me.
THE "Inflation Reduction Act" (IRA) is another example.
Voting occurs in ~2 months. Study up and participate accordingly.
Technical challenges are a lot of things but mostly a pretty unimpressive build-time improvement over C++. An explicit choice to limit the generalized effects system to "we can get a lot of JS people on board" is already showing age.
The political challenges are, ugh, more complicated. It's everything from the PagerDuty response times on every relevant forum by a person of the exact right seniority to respond to anyone expressing even the slightest skepticism to the big blocks of people resigning en masse and publicly (https://developers.slashdot.org/story/21/11/27/0123211/rusts...) over "Core Team" heavy-handedness, to the still-intriguing mystery of who is paying thousands of people to care more about this than their spouse.
Linear and affine typing do in fact interact, and yes there’s been a ton of research on it, the papers are there for anyone to read.
And if Rust was marketed as a promising research vehicle, then have at it!
But it’s not, it’s marketed (very successfully or I wouldn’t care) as “and you will do nothing, because you can do nothing”.
Affine typing can get fucked compared to big sloppy arenas if that makes it easier to mutate a variable without talking to the network. That’s a bigger safety and correctness concern full stop.
People talk about Rust and it’s borrow checker like it’s the x86_64 ABI or something: it’s not. It’s a vocal and enthusiastic community with non-trivial but still-optional buy-in at the big shops.
We can still collectively just ditch it if we want. The borrow checker is still asking for permission to exist: C textual header includes are asking for foreguveness.
Now we were all making 2 million dollars a year on the low end, so we were certainly compensated, but even then, nothing to brag about.