> “We have to make things easier without losing the advantages that Rust has for its core focus of systems programming. Reducing the need for explicit lifetimes, making the borrow checker more powerful, not overcomplicating the trait system, focusing on user experience, and avoiding becoming a huge language will all help.”
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.
Top problem for me as a relative Rust beginner (couple of months of Rust) right now: Mixing async/sync code. The ecosystem seems very split across how to handle things, and async code doesn't work well with sync code, and vice-versa. Some libraries assume runtimes to be available, others that there is no runtime. One async library is incompatible with some other async libraries because they use different runtimes. It's a whole mess.
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.
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.
Tokio is 1.0 since 2020 and they declared to maintain backwards compatibility for a minimum of 5 years. Tokio already made backwards compatibility guarantees and it hasn't been killed so far.
It isn't a question of backwards compatibility, it is just way easier to iterate / evolve in a crate than it is in stdlib.
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.
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.
Library using async-std instead of tokio for example, which there are plenty out there. Search on crates.io and you'll see. Many support tokio nowadays, but there are still some out there that doesn't. And because of the closed nature of Rust libraries, it's not easy to patch it in there without having to fork the library.
I'm very familiar with the crates ecosystem (I run https://lib.rs). I know there are libraries for async-std specifically, but my point is that AFAIK all of them have equivalents for tokio, e.g. you can't use `surf` with tokio, but there's `reqwest` and others. I'm not aware of any "killer app" existing that would be forcing anyone to use async-std (and if there was one, it'd get forked and converted to tokio ;)
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).
Rust is worse, because at least .NET doesn't require going hunting for an async runtime that is compatible with all 3rd party dependencies, and all graphical debuggers know how to step through async code.
> 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.
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.
> Something we are discussing is changing `defaut-features = false`
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.
Sorry, I was meaning the opposite. We'd be deprecating it and making it unavailable in future editions. Instead you have to opt out of each default feature.
> 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.
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'.
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.
Exactly, I remember when the internet was heralded as a step against racism by removing any bias you normally see - like skin colour, accent, etc.
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".
People keep wanting to have profile pictures of their "real" selfs and talk about their private life with the same people they write code with. That didn't use to happen. Back in the day, there wasn't even any avatars, just emails! Then people started using nicknames, that was fine. And first when avatars appeared, we used images of something else. Myspace and Facebook brought up the whole "I have to be the same person I'm online as I'm in the real-life" syndrome, and now we have what you described above.
You can still be anonymous in open source projects. My experience is that nobody cares about your background or ethnicity or (at least) wants to know about your background/ethnicity. If you're a valuable contributor you will be respected instantly. Also if you're serious about wanting to learn (and have a fairly good foundation of basic skills) you will find people willing to help you. So if you're really worried about being discriminated against, but are serious about becoming a better programmer, just stay anonymous on github.
I know this (this very account is one anonymous profile of mine) and many others know this. But bigger and bigger slice of the whole internet ecosystem is moving from "anonymous internet profiles" into "my real life profile but on the internet". Platforms are even starting to enforce that policy as well.
My comment was more an observation on how others act, rather than how I act.
I like the idea of not bringing "irl" problems in cyberspace, but at the same time I can't help but worry that this does not address the root cause and will only perpetuate and normalize these problems. What we need is a change in the consciousness of the people, one should not think of the negative things that can occur by using their face as a an avatar, in this day and age we should not have such problems. But yes on a level meritocracy should be the goal, your code should be what matters.
Aaand back in the day before that it was US middle class guys (and some gals) working in offices.
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.
> But now a set of Americans seem dedicated to shoehorn it in.
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.
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.)
Every day there seems to be 2 or 3 posts about Rust in HN. I really don't get it.
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.
> 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.
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.
The point of a language isn't to provide lots of jobs, but to be a tool that solves business problems, and Rust excels in a niche where there are no other serious players, writing safe and performant code. It has plenty of traction in that niche, look at AWS Firecracker or Cloudflare's Pingora that was unveiled just this week.
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.
The dynamo of the Rust marketing machine is as much a mystery to me as it is to you, but while I might gripe a bit on the way (and I do), it's pretty clear at this point that you'd better know it well if you want to be conversant in the randomly sampled piece of code 3-5 years from now.
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.
I've spent much of my career writing C++, which I consider an even more difficult language to work with than Rust. But even so, it gets used a lot for problems where performance or a low memory footprint are more important than developer productivity or memory safety.
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 don't agree at al with his analysis of the crate ecosystem. I'd love to see either the standard library grow considerably or some semi-standard major libs to appear.
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 haven't written a lot of Rust, but every time I do I find myself trying to do something rather basic, google around a bit, only to have people telling me to just install crate so and so. While I do see the advantages of this and all, it also stops me from learning the basics.
Disregard the crate, write your own thing. Then have a look at the crate and compare notes. That’s how you learn. Just pretend they don’t exist for a while. This attitude has some other uses, too.
You need to communicate clearly that you are doing these things as a learning exercise, not just because they're a requirement for something bigger that you're actually trying to do. People try to be helpful by saving you unnecessary work, not realizing that the work is your actual goal.
It's worth reinventing the wheel for the purpose of learning those low-level bits, if that's something you want to learn. For example, I feel like every week I see a new NES or Gameboy emulator posted on /r/rust
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
The way Cargo pins dependencies always makes me nervous. One of the "new crates" on crates.io has a dependency that is 3 years out of date, rather than depending on the newest version.
It just makes me wonder how many bug fixes aren't getting propagated, potentially spreading serious issues. I realise that the C way of "packages that aren't kept up-to-date just break" is less than ideal, but after the Log4J thing happened I'm wary.
The rather small stdlib of Rust is a learning from Python: Python's stdlib really does have "everything and the kitchen sink", but lots of modules will have caveats like "do not use urllib2, use requests from PyPI instead". The biggest reason for this is that the stdlib has a much stronger backwards-compatibility guarantee than any library, so any bad API choice is set in stone forever until Python decides to do another major version bump. (And we all remember how smoothly the last one went.)
I understand very well. The JDK has the same problem. But both are in better shape than the node ecosystem.
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.
crates.io isn't npm. A lot of mess in npm is specific to npm, Node and JS.
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.
Insane that something like "Diversity / Inclusion" is ranked as second when there are real issues with Rust (I say, as a Rust programmer that enjoys the lang).
> 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.
> 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.
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.
They have real numbers, and they did not share. Several questions about it were included in the annual survey of 2021, but they chose not to share these numbers with the community, claiming "an over-abundance of caution" as their reasons. One possible stated consequence for sharing these numbers was "some anti-lgbt group finds the data, decides the numbers are significant, and starts targeting local Rust meetups". Now that the article claims that the numbers are "even terrible compared to the tech industry", this hypothetical consequence seems rather silly.
It's with a grudging sort of respect but nonetheless a massive respect that I acknowledge that Rust is the best-marketed thing on the Internet in my 30 years on it.
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.
I'd love to be able to go to a model of: You like Rust? Welcome!
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.
I don't understand what you're talking about. I've never come across someone in the Rust community screaming their sexual preferences, unless you think the occasional person mentioning it in their Twitter profile is a big problem.
I am not aware of anything specific in the rust community, and don't think I've ever read someone's twitter profile.
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.
There is an enormous and probably diverse online peanut gallery for Rust. I think the concern is more about the diversity of contributors - many of these people meet in person. So the dogs and purple with orange speckled snails will be found out as such. Making sure people feel safe both online and in meatspace is important.
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?
To be honest, all jobs Ive done had plenty of woman in tech. I've had a woman in tech be my manager or my director. I've never counted stats, and maybe they tend to be more in analytical roles, but a female dev was never that abnormal for me. Maybe the 3% is more of an us thing?
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.
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.
unless I misinterpret your last paragraph, but isn't the solution to that mystery is the fact that not everyone has a spouse? (also many spouses don't need the attention, so folks are free to spend it on oxidizing the world? :))
So (darkly) funny story: when I was like one of eight people with a pager (so to speak) on Instagram’s total stories served per minute/hour/whatever: there were a few of us losers who missed that the servers were more than a little stressed on a Tuesday, and it took especially long to find out because everyone else was doing one of the most important things they’d do all year: it was Valentine’s Day, of course there were a lot more posts than usual.
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.
The interactions of "generalized effects" with the Rust affine types and tne borrow checker are quite non-trivial. This explains why Rust does not use effects better than any explicit choice; building an effect system that works naturally with the language is a research-level question that hasn't been tackled as of yet.
It’s unclear from your comment if you’re talking about what Haskell calls “applicative” effects (sequenced but independent in which subsequent computation) or “monadic” (sequenced but the previous effectful computation can determine the next).
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.
"DIE" can be a bad thing or a good thing, depending on what is it exactly. Is it a mandate for certain outcomes (which leads to the great leap forward culling and such) or is it a sincere push to look at the pipeline ("STEM pipeline", but obviously it's not just about STEM), look at the actual problems of actual disadvantaged people. (And what are the actual effective solutions for those problems ... and very importantly the broader community must not ignore the mental health aspect of this, which affects both the advantaged and disadvantaged, and both sides need some training to be able to adapt and manage the changes with ease.)
This is what conspiracy brain does to someone. It must be that I “called in” someone; that we’re coordinated, when to anyone that’s paying attention, there’s clearly bad blood between burntsushi and I, given that he resigned as a mod from the project over protest from my team’s leadership and I haven’t exactly been non-vocal that I think it’s a good thing the moderation team quit.
No, it can’t be that even despite of that, in that thread he is still correct, and we are both professionals, and therefore don’t bring petty shit into hacker news threads. He’s still right in that thread regardless of interpersonal bullshit.
I stand by my assertion that editing a comment after a reply is authored to make the replier look stupid in hindsight is a coward's move.
I give you respect for posting under your real name and having a long history on the site, credit where due, and I hope I've for the most part brought out substantial issues that demonstrate real thought on the issues at question.
But fuck me, the HN community deserves an apology for that bullshit, an apology I've issued many times when I got too heated, but an apology owed nonetheless.
It'd be nice to squeak in a legitimate PLT argument from a mover and shaker: is Blow way off on doing a huge, bump-allocated arena every time he hits a `CALLQ`? I think that sounds just obvious enough to be what the GCC/Linux people have been trying to do with resounding failure in the "growable stack"/nobody cares column for a decade now.
Arenas are great. He’s not wrong that they’re great. He is (was?) wrong that somehow Rust makes them not possible, or bad to use, or something. rustc makes extensive use of them, in my understanding, even.
He could use the endorsement of someone with your gravitas saying on the record that his (controversial) default is the better default.
No one is saying that everyone will be served well by the default, but virtual memory is a great deal cheaper than physical DRAM on every conceivable platform for Jai or Rust, and him blowing it off in big chunks to avoid compiler/borrow-checker errors for the same cost in core without a bitchy compiler is a win in the leathered hacker's book.
Why can the Haskell people, and the C++ people, and the Python people, and everyone except the Rust people say: we missed vector, we missed modern TLBs, we missed clock-rate forecasts not one but twice, like all those other people have.
Are you saying that the vector data structure is stupid?!
And, moreover, that it's an opinion shared by the python and c++ communities? I'd love to see evidence of that. I'd also love to read arguments about why Vec/vector is stupid, it's certainly the first time I read that.
No one in the C++ community is like, great, in order to keep shit working we’ve got to honor this ABI where we can’t do SSO.
No one in the Haskell community is like great: linked lists as the fundamental data type is just awesome on modern x86.
The people in the Python community are like great: we just broke everything and took a decade doing it, because we were emphatically wrong about ASCII being a given.
The people in the Rust community say nothing like this: Rust isn’t wrong: you’re wrong. Which is going to get progressively weirder as we move back to ASICS more weird than GPUs.
I’m enheartened to hear that someone (e.g. you parent) has some grasp on reality on this, but I’ve been in this game long enough to see a decade of progress dunked over CORBA and XML, which had nothing like the mindshare or organic buy-in this Rust stuff does.
This is true fanaticism, and I don’t know about you, but I’m going to miss being retired for it’s consequences for the least fun decade of a career that included Visual Basic.
What percentage of new software will actually be affected by this? My guess is that it will still be most practical to write lots of software in an imperative style, and Rust will let us do that more safely and efficiently than other popular languages. For the problems that really need to be solved through custom ASICs, we have things like the Haskell-inspired Clash [1]. I doubt that the hype around Rust, and even the most misguided Rust boosters, will impede progress on that front.
Ah, thank you for explaining, that makes sense. I think rust people (the ones I know anyway) don't think rust is perfect, or the end-it-all language. There already are a few warts (I'd say async really doesn't have the best ergonomics), but the language is a bit young for the community to find some really big issues?
The fact that `?` is baked in for Option/Result is a pragmatic choice that allowed rust to ship in 2015, not 2035, when the research on mixing effect systems and borrow checker is done. There were already enough innovations tokens in rust 1.0, and moving the needle forward on memory safety and decent type systems is having a positive effect on all the other languages in that space (Zig, Carbon, now C++/C++2…).
> He is (was?) wrong that somehow Rust makes them not possible, or bad to use, or something.
I think the more meaningful question is whether local arenas are idiomatic enough in Rust. Of course, custom allocators are not the easiest thing to use in C++, either.
And there are other semi-related things, such as allocating and initializing pinned objects in-place, for which Rust is still lacking a good story as the Rust-for-Linux folks have pointed out recently.
I think the more germane question is whether or not Rust is in any sense modern on hardware architectures that have changed their 5 year outlook twice in the past three? 2nm with tiles and backplane power is already a radically different landscape than AMD’s current leading edge big-L3, high-core arch.
The fucking arrogance. It is not the world’s job to accommodate Rust. It’s C’s job to work out whether Rust works out or not.
This seems to be a total non-sequitur from the previous comment. What does this have to do with arenas versus other memory allocation strategies? And in what way are hardware architectures being expected to accommodate Rust?
For as long as sequential locality is the order of the day, bump allocators are on average going to stomp stack/heap dichotomies like C++ or Rust. By huge, huge, constant factors.
I’m proposing Jai (and John) as plausibly more in touch with a rapidly-changing hardware landscape than Rust by definition practically ever could be without another round of pre-1.0 “everything is broken always”.
Were you earnestly asking that question in good faith because you didn’t read the multiple siblings about Jai and arenas vs affine? Or are you just part of the gang tackle?
> Were you earnestly asking that question in good faith
Yes, because although I read the whole thread, I didn't get the connection between arenas and the rapidly changing hardware landscape. Now I want to learn more. And, as someone who merely uses Rust in some projects and thinks it's likely to be the least bad alternative for some others, I have no problem contemplating that Rust might have chosen a suboptimal default allocation style. I think the borrow checker is still a good thing though, and don't understand how it could be fully replaced by arena allocation.
While downvoting is normally a healthy expression of “this is a low-value comment, let’s bury it under more insightful comments”, which is the intended purpose.
“Blow is right on arena-by-default” is the real point of controversy there. I think it’s obvious, but am open to contrary opinion.
Carl/Yehuda/Tom profiteered off an exceptional ability to forecast language cults: maybe differ with that.
But I’ve really teed up things that one can concretely disagree with: I’ve done this intentionally to deprive the arrows of any tangible meaning, as well-travelled commenters do.
Rust is working on support for local allocators. They're not far from being enabled to support memory arenas (and even local, pluggable GC!) just as well, or even better than any other language in current use.
Please take my reply in the spirit of someone being replied to very unreasonably but who doesn't count you in that group:
Many languages, probably most notably among them C++, have implemented varying degrees of what we might call "custom allocator policy".
This is a rather extreme case of a generally over-applied maxim: "defaults matter".
While it is completely possible to do a custom bump-allocator (which is the only kind of allocation on the table if you need to be fast without the help of `tcmalloc` or `jemalloc`), it's sufficiently high-friction that most write their own vector rather than doing the language lawyer thing of doing a "custom allocator".
What John Blow proposes, quite reasonably if not obviously to me, is making a call-frame level arena in which all "heap" allocations are just past the last one, basically burning "reclaim opportunity" in light of the abundance of evidence that no one ever cares about memory that `jemalloc` has already done fragmentation around.
> but this "Rust Thing" is legitimately scary in the way that MAGA politics is legitimately scary: we've mobilized people in large numbers in a cause that they don't understand.
What exactly are you scared of? What is the bad outcome that will come from more software being written in Rust? Are you scared that important projects will be derailed by a successful campaign to rewrite large amounts of code in Rust? Or something else? The fact that promotion of Rust pattern-matches against a scary political movement isn't, IMO, reason enough to be scared.
To be clear, I'm not part of any coordinated Rust marketing effort. I just like what I've seen of Rust so far, I want to write more of it (edit: particularly in contexts where I currently use Electron or server-side web frameworks based on less efficient language runtimes), and I think enthusiasm about Rust is justified.
Rust boosters are already actively rewriting PLT history to where `?`-notation is an innovation, not a syntax for a somewhat broken, highly limited notion of effects distinct from computation. There are effect contexts not only richer, but critically more important than `Either`, e.g. `StateT`.
If Rust had the momentum of a typical over-hyped programming language I'd be merely interested. The insane "better than a politician" marketing creates risks I can't even foresee, and the ones I can are all very, very bad.
> Rust boosters are already actively rewriting PLT history to where `?`-notation is an innovation
To be clear, are they actually denying the influence of Haskell and other languages, or are they just saying that `?` notation is something new in their experience, and better than what's available in current popular languages? IMO, there's nothing wrong with the latter.
> not a syntax for a somewhat broken, highly limited notion of effects distinct from computation. There are effect contexts not only richer, but critically more important than `Either`, e.g. `StateT`.
So are you concerned that the hype around Rust will prevent people from discovering Haskell and using it in situations where it would be an even better choice? I guess that could happen, but IMO promoting something less dangerous than C and C++ on the one hand, and more efficient than JavaScript on the other, that people will actually be willing to use for real projects today, is important enough to justify that risk.
> risks I can't even foresee, and the ones I can are all very, very bad.
The Rust Core Team is neither ignorant nor stupid. Furthermore you can't find one of them that doesn't know both Haskell and Idris well I more than suspect at this stage in the proceedings.
They are completely aware of the necessity of separating effects from computations if one truly wanted to create a "safe" programming language that was in the critical path of the mainstream. Actually doing this is a fairly high bar modulu all the memory-safety nonsense in the talking points deck. It would create roughly no people who had a low-friction migration path from TypeScript to Rust, which is diametrically opposed to having a menacing mob at ones disposal.
Rust is halfway between the polar points articulated by Paul Graham: it's neither designed for it's serious users (though they pretend to like it) nor it's audience who it openly condescends to.
As for the scary effects of having a programming language committee control more votes than 4chan on internet forums in general: yeah I don't know how that's going to play, but I'm pretty sure I'm not going to like it.
> It would create roughly no people who had a low-friction migration path from TypeScript to Rust, which is diametrically opposed to having a menacing mob at ones disposal.
Having a low-friction migration path from TypeScript also enables more programmers to write reliable, efficient software. I hope that the number of programmers quietly doing this will grow to eclipse the number posting to forums. We must not get so caught up in forum drama that we forget that increasing the quantity of good software in the world is what's most important.
I hope that those of us who sold our souls for money while knowing full well the history around Therac-25 aren’t eclipsed by a generation who gave even more for a friggin badge on Reddit.
Rewriting TypeScript code in Rust (or writing what would have been TypeScript in Rust instead) is in no way morally analagous to Therac-25. This is the kind of claim that Haskell programmers make on the basis that they believe Haskell prevents faults (providing no specific evidence - in contrast to Rust, which draws on numerous data showing that memory safety is a serious concern) in computer software. The core problem in Therac-25 was exactly this - the programmers thought they were very good at writing software (when they were not) and decided to remove the hardware safety restrictions (which they should have not done, even if they were really good computer programmers). It wasn't about type systems, it was about hubris and real-world hardware.
It's an innovation compared to most other languages in common use. We should celebrate the fact that Rust is bringing advanced PL features to a mass audience, especially given that it's far from clear how to unify all of those features within a single "effects" framework.
As I have on numerous occasions. I routinely celebrate Rust as the language popularizing the notion of "constraints as power", search for it if your don't believe me, but I with equal frequency get Flying Fucking Rust Gangbang Battalion attacked for stopping short of "Rust is the programming language of the God Emperor himself".
You’ve brought up two points that I will address separately:
- I move comfortably through the compiler and standard library of Rust, so I’m not mobilized by a lack of understanding
- I’m terrified of this level of fanaticism from people who have only a superficial understanding of Rust, or it’s pedigree, or the historical precedent of particular technology fetishism.
I had to check that the handle here was the same one I had a reasonable discussion with the other day. Holy moly, your comments are completely unhinged. Absolutely certifiable.
> @burntsushi
I get notified when you do this. It would be fantastic if you never did it again. Please.
I wouldn't advertise that I have a script hooked up to Hacker News.
I'll say @burntsushi when I please, thank you.
Klabnick got flagged below showdead when he mouthed off on this same thread. That's the Rust Community when their temper gets high. My temper also gets high. I apologize when I'm explicitly cited for going out of bounds, which I do. So cite an example (or ten) of me going out of bounds and I'll acknowledge it.
Citing the fact that Carl and Yehuda cited to me in person that they planned to monetize the Rust phenomenon is not hate speech, it's hear say, but everyone believes me, including you.
I'm a C programmer, I began in ~1995, and I mostly wrote C for my entire career/hobby stuff, apart from assembly, and Python for scripting purposes.
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)
I had to learn some low level memory models before I could really grok rust. I understood a bit of C++ but it wasn't until I found the talk about memory structures for rust/c++ that I really caught on. I can understand why knowing existing programming techniques might cause a struggle.
The Rust way to do low level programming is easier for those that bring some experience from Wirth languages approach to systems programming, instead of being tainted by C.
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.
> it ends with the copy of a whole megabyte of a structure
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.
Took me 9 months of trial and error in 2018-19, trying it on and off again, before I could understand how to do with rust. Just writing a few programs weren't enough for me to understand, because I was just using what I knew and not what I needed.
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).
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!
I wish that more developer communities followed the OpenBSD model of (what my impression is) not necessarily caring about community, inclusiveness or popularity. I'm new to programming so take my observations with grains of salt. But I'm disheartened by the (over)-politicization/commercialization of programming and development in some respects.
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..
Has any language solved the dilemma of the monotonically growing language in a satisfactory way? Or do we just abandon every language after 20-30 years of feature accretion? (That may in fact be the best solution)
130 comments
[ 4.2 ms ] story [ 215 ms ] threadI 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.
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).
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/
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'.
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.)
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.
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.
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.
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.
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 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.
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.
[1] https://foundation.rust-lang.org/about/
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.
See here for more information: https://old.reddit.com/r/rust/comments/vhvb4m/2021_annual_su...
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.
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.
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.
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.
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.
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.
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.
> 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.
No, it can’t be that even despite of that, in that thread he is still correct, and we are both professionals, and therefore don’t bring petty shit into hacker news threads. He’s still right in that thread regardless of interpersonal bullshit.
I give you respect for posting under your real name and having a long history on the site, credit where due, and I hope I've for the most part brought out substantial issues that demonstrate real thought on the issues at question.
But fuck me, the HN community deserves an apology for that bullshit, an apology I've issued many times when I got too heated, but an apology owed nonetheless.
No one is saying that everyone will be served well by the default, but virtual memory is a great deal cheaper than physical DRAM on every conceivable platform for Jai or Rust, and him blowing it off in big chunks to avoid compiler/borrow-checker errors for the same cost in core without a bitchy compiler is a win in the leathered hacker's book.
Why do you people always need to be right?
Catch a Rust person saying this is fucked full stop and it's too late to fix it.
Find me that one.
And, moreover, that it's an opinion shared by the python and c++ communities? I'd love to see evidence of that. I'd also love to read arguments about why Vec/vector is stupid, it's certainly the first time I read that.
No one in the Haskell community is like great: linked lists as the fundamental data type is just awesome on modern x86.
The people in the Python community are like great: we just broke everything and took a decade doing it, because we were emphatically wrong about ASCII being a given.
The people in the Rust community say nothing like this: Rust isn’t wrong: you’re wrong. Which is going to get progressively weirder as we move back to ASICS more weird than GPUs.
I’m enheartened to hear that someone (e.g. you parent) has some grasp on reality on this, but I’ve been in this game long enough to see a decade of progress dunked over CORBA and XML, which had nothing like the mindshare or organic buy-in this Rust stuff does.
This is true fanaticism, and I don’t know about you, but I’m going to miss being retired for it’s consequences for the least fun decade of a career that included Visual Basic.
What percentage of new software will actually be affected by this? My guess is that it will still be most practical to write lots of software in an imperative style, and Rust will let us do that more safely and efficiently than other popular languages. For the problems that really need to be solved through custom ASICs, we have things like the Haskell-inspired Clash [1]. I doubt that the hype around Rust, and even the most misguided Rust boosters, will impede progress on that front.
[1]: https://clash-lang.org/
The fact that `?` is baked in for Option/Result is a pragmatic choice that allowed rust to ship in 2015, not 2035, when the research on mixing effect systems and borrow checker is done. There were already enough innovations tokens in rust 1.0, and moving the needle forward on memory safety and decent type systems is having a positive effect on all the other languages in that space (Zig, Carbon, now C++/C++2…).
I think the more meaningful question is whether local arenas are idiomatic enough in Rust. Of course, custom allocators are not the easiest thing to use in C++, either.
And there are other semi-related things, such as allocating and initializing pinned objects in-place, for which Rust is still lacking a good story as the Rust-for-Linux folks have pointed out recently.
The fucking arrogance. It is not the world’s job to accommodate Rust. It’s C’s job to work out whether Rust works out or not.
I’m proposing Jai (and John) as plausibly more in touch with a rapidly-changing hardware landscape than Rust by definition practically ever could be without another round of pre-1.0 “everything is broken always”.
Were you earnestly asking that question in good faith because you didn’t read the multiple siblings about Jai and arenas vs affine? Or are you just part of the gang tackle?
Yes, because although I read the whole thread, I didn't get the connection between arenas and the rapidly changing hardware landscape. Now I want to learn more. And, as someone who merely uses Rust in some projects and thinks it's likely to be the least bad alternative for some others, I have no problem contemplating that Rust might have chosen a suboptimal default allocation style. I think the borrow checker is still a good thing though, and don't understand how it could be fully replaced by arena allocation.
“Blow is right on arena-by-default” is the real point of controversy there. I think it’s obvious, but am open to contrary opinion.
Carl/Yehuda/Tom profiteered off an exceptional ability to forecast language cults: maybe differ with that.
But I’ve really teed up things that one can concretely disagree with: I’ve done this intentionally to deprive the arrows of any tangible meaning, as well-travelled commenters do.
Dumbass under pseudonym.
Many languages, probably most notably among them C++, have implemented varying degrees of what we might call "custom allocator policy".
This is a rather extreme case of a generally over-applied maxim: "defaults matter".
While it is completely possible to do a custom bump-allocator (which is the only kind of allocation on the table if you need to be fast without the help of `tcmalloc` or `jemalloc`), it's sufficiently high-friction that most write their own vector rather than doing the language lawyer thing of doing a "custom allocator".
What John Blow proposes, quite reasonably if not obviously to me, is making a call-frame level arena in which all "heap" allocations are just past the last one, basically burning "reclaim opportunity" in light of the abundance of evidence that no one ever cares about memory that `jemalloc` has already done fragmentation around.
What exactly are you scared of? What is the bad outcome that will come from more software being written in Rust? Are you scared that important projects will be derailed by a successful campaign to rewrite large amounts of code in Rust? Or something else? The fact that promotion of Rust pattern-matches against a scary political movement isn't, IMO, reason enough to be scared.
To be clear, I'm not part of any coordinated Rust marketing effort. I just like what I've seen of Rust so far, I want to write more of it (edit: particularly in contexts where I currently use Electron or server-side web frameworks based on less efficient language runtimes), and I think enthusiasm about Rust is justified.
If Rust had the momentum of a typical over-hyped programming language I'd be merely interested. The insane "better than a politician" marketing creates risks I can't even foresee, and the ones I can are all very, very bad.
To be clear, are they actually denying the influence of Haskell and other languages, or are they just saying that `?` notation is something new in their experience, and better than what's available in current popular languages? IMO, there's nothing wrong with the latter.
> not a syntax for a somewhat broken, highly limited notion of effects distinct from computation. There are effect contexts not only richer, but critically more important than `Either`, e.g. `StateT`.
So are you concerned that the hype around Rust will prevent people from discovering Haskell and using it in situations where it would be an even better choice? I guess that could happen, but IMO promoting something less dangerous than C and C++ on the one hand, and more efficient than JavaScript on the other, that people will actually be willing to use for real projects today, is important enough to justify that risk.
> risks I can't even foresee, and the ones I can are all very, very bad.
What are some of those risks you can foresee?
They are completely aware of the necessity of separating effects from computations if one truly wanted to create a "safe" programming language that was in the critical path of the mainstream. Actually doing this is a fairly high bar modulu all the memory-safety nonsense in the talking points deck. It would create roughly no people who had a low-friction migration path from TypeScript to Rust, which is diametrically opposed to having a menacing mob at ones disposal.
Rust is halfway between the polar points articulated by Paul Graham: it's neither designed for it's serious users (though they pretend to like it) nor it's audience who it openly condescends to.
As for the scary effects of having a programming language committee control more votes than 4chan on internet forums in general: yeah I don't know how that's going to play, but I'm pretty sure I'm not going to like it.
Having a low-friction migration path from TypeScript also enables more programmers to write reliable, efficient software. I hope that the number of programmers quietly doing this will grow to eclipse the number posting to forums. We must not get so caught up in forum drama that we forget that increasing the quantity of good software in the world is what's most important.
You seem to be mobilized by Rust quite a lot.
- I move comfortably through the compiler and standard library of Rust, so I’m not mobilized by a lack of understanding
- I’m terrified of this level of fanaticism from people who have only a superficial understanding of Rust, or it’s pedigree, or the historical precedent of particular technology fetishism.
> @burntsushi
I get notified when you do this. It would be fantastic if you never did it again. Please.
I'll say @burntsushi when I please, thank you.
Klabnick got flagged below showdead when he mouthed off on this same thread. That's the Rust Community when their temper gets high. My temper also gets high. I apologize when I'm explicitly cited for going out of bounds, which I do. So cite an example (or ten) of me going out of bounds and I'll acknowledge it.
Citing the fact that Carl and Yehuda cited to me in person that they planned to monetize the Rust phenomenon is not hate speech, it's hear say, but everyone believes me, including you.
So let's hear a legitimate complaint?
Mostly just trolls. Most sensible people have issues with trolls, e.g., https://lobste.rs/u/soc
I hope you learn to interact more positively and constructively with your surroundings.
Until then, please go away.
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
https://youtu.be/rDoqT-a6UFg
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.
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.
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).
https://cliffle.com/p/dangerust/
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!
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.