Comment by HL33tibCe7
9 months ago
> The problem you're having is only a problem because you haven't tried hard enough.
You just need to read another 50,000 word fasterthanlime essay. Then you'll not have problems any more.
> That being said, there is an overwhelming force in the Rust community that when anyone mentions they're having problems with Rust the language on a fundamental level, the answer is "you just don't get it yet, I promise once you get good enough things will make sense".
Not only this, but they openly mock other language communities for not drinking the koolaid.
I like Rust, and the Rust community, and fasterthanlime, for what it's worth. But I think these points raised in the article are very much valid.
Parts of the Rust community are toxic indeed, but I've been around long enough to recognize the same pattern in communities of other hot programming languages or frameworks in their up-and-coming phase.
There's something about the new hot language/framework/paradigm that always attracts the type of people who wrap their identity up in the hot new thing. They take any criticisms of their new favorite thing as criticisms against themselves, and respond defensively.
What I see now in certain Rust communities feels a lot like what I saw in Golang communities in the early days. I had similar experiences when React was the new kid on the block, too.
Some of these communities/forums are just inhabited by people who thrive on dunking on noobs all day long. The good news is that they tend to get bored and move on when the next new thing comes out.
I'm already seeing this in my local Rust community as the chronically online people are moving on to Zig now. They even use one of the Rust discords to advertise their Zig meetups and proselytize about Zig at every opportunity. Eventually they'll get bored and move on.
> > That being said, there is an overwhelming force in the Rust community that when anyone mentions they're having problems with Rust the language on a fundamental level, the answer is "you just don't get it yet, I promise once you get good enough things will make sense".
I don't fully agree with this assessment. In my experience, Rust community members who arrive with well thought out complaints or suggestions are welcomed by the people who like working on programming language fundamentals. You can nerd snipe a lot of Rust enthusiasts by showing up with a difficult problem involving tricky parts of Rust, which will often result in some creative solutions and discussions.
On the other hand, Rust communities are inundated with people trying to write Rust as if it was their old favorite language. I've spent a lot of time trying to get people to unlearn habits from other languages and try to adopt the Rust way of doing things. Some people refuse to let go of paradigms once they've used them for years, so doing things the Rust way isn't going to work for them. I've worked with enough people who spent more time fighting against Rust than trying to adopt Rust ways of doing things that I've also reached the point where I don't engage once I see the conversation going that way. Can't please everyone.
"On the other hand, Rust communities are inundated with people trying to write Rust as if it was their old favorite language."
This is perfectly understandable if you view languages as tools. If the new tool can't do something the old one did, then you'll have questions about using it. A great example is inheritance - if inheritance is missing, that's a negative for me. I don't care about the philosophy, I just want to use the tool to produce programs better and faster. If it's missing features, that's a negative point.
> What I see now in certain Rust communities feels a lot like what I saw in Golang communities in the early days. I had similar experiences when React was the new kid on the block, too.
Go was released in 2012, Rust in 2015. Are you saying we are still in the early days of Rust?
> Go was released in 2012, Rust in 2015. Are you saying we are still in the early days of Rust?
Release dates mean very little. Golang had rapid adoption early on. Rust only recently became one of the fastest growing languages. Golang stabilized a lot of things about the language and library early on. Rust still has a lot of common features gated behind nightly.
There is a fun tool for comparing the number of PRs on Github by language that shows the difference: https://madnight.github.io/githut/#/pull_requests/2024/1
So yes, I think we're in the early days of Rust.
Ruby was released in 1995 and didn't really have its heyday of developer hype until Rails came along a decade later. Python didn't start gaining serious traction for about a decade after its 0.9.0 release either. Go's immediate uptake seems like an outlier in programming language lifecycles.
Yes.
C was invented in the '70s and only got standardized 20 years later.
And Rust's ~20 years is young in systems lang terms (the alternatives, C and C++, are 50 and 40 years old).
And nobody had TikTok back then.
4 replies →
> Parts of the Rust community are toxic indeed, but I've been around long enough to recognize the same pattern in communities of other hot programming languages or frameworks in their up-and-coming phase.
Yeah. I think there’s also a weird way that newcomers get treated when they join a community. When you’re a newcomer to Rust, you probably have some preconceptions about how Rust should work based on the other languages you know, and you’re probably running into a lot of the same problems with Rust that everyone else has (e.g. borrow checker).
Most of the community is just kinda tired of the discussion and tired of answering the same questions, so they don’t interact with the noobs at all. That means that the people who, as you say, “thrive on dunking on noobs all day long”, are the primary point of contact for noobs.
Finding a decent programming community these days is a pain in the ass. The cool people, i.e., the people working on cool projects and getting shit done, are mostly busy and not hanging out with anybody.
> Parts of the Rust community are toxic indeed, but I've been around long enough to recognize the same pattern in communities of other hot programming languages or frameworks in their up-and-coming phase.
I would say that in general, this type of attitude permeates a lot of software engineering, and even engineering and science as a whole. When I speak with people in other fields, particularly more creative ones, the discussions are so much more improvisational and flowing. Discussions with software developers, engineers, and scientists have this very jerky, start and stop "flow" to them as you meet resistance at each step. I honest to god have had people telling me no or shaking their head no before I ever finished my question or statement, much less before they even understood it.
> There's something about the new hot language/framework/paradigm that always attracts the type of people who wrap their identity up in the hot new thing. They take any criticisms of their new favorite thing as criticisms against themselves, and respond defensively.
You're spot on about the coupling of someone's identity with it. Rust especially seems to also have this never-ending gold rush to be the next framework and library everyone uses, which creates a very competitive landscape. And it seems most frameworks and libraries get 80% of the way and then fizzle out once people realize Rust isn't a magical language that solves all your problems.
Conversations that people have in science and engineering are more analytical and pessimistic, where they try to clarify and set the boundaries.
This is the opposite of creative and optimistic conversation, where you break boundaries between things to create something new.
The attitude to be analytical in conversations comes from the fact, that software engineers usually do creative part of their work alone, and use communication for analytical part (code review, requirement clarification, etc). For some creative people it's natural to do creative work together, especially in music, so it's easier for them to adopt a creative attitude in conversations.
2 replies →
unrelated: the word "toxic" is meaningless nowadays e.g., "dunking on noobs" is more specific.
Rust is a language with a very high mental cost to use effectively. It requires some fundamental paradigm shifts in the way you write software, hence it's a hard language to be productive in.
For some tasks, the tradeoff is worth it. Some individuals are naturally very inclined to use it.
But for most people, for most tasks, it's simply not the right tool. It's not a general purpose language by any stretch of the imagination.
If there were only two programming languages in the whole world, just two, no more; one better fitted for OS kernels and one better fitted for game programming, which one would be considered a general purpose language?
I would argue, OS programming is definitely more general than game programming. Rust is great for OS related tasks, math, deep learning n other stuff, and maybe not so great at GUIs, or even bad at that, or just inconvenient as the article points out.
That means, it should be used for general stuff, and for programming games should be used a niche language, like Lua, Python etc. Especially for fast iteration and experimentation, break things and move lightning fast, typed languages are in disadvantage for sure, compared to untyped/weakly typed.
I would argue that OS kernel programming is actually a very specialized niche of software engineering; it demands near iron performance, fine control down bit level granularity, perfectly deterministic memory manipulation, flawless security and maintainability, and all at the same time. These are conflicting requirements and meeting them naturally spills over into decreased productivity, which is acceptable because OSes are well engineered and evolve over decades.
If C or Rust would not be available, you could still write your kernel in a well documented assembly dialect - some people still do - and then complete your OS userland in some garbage collected/interpreted/WASM abomination. But it's unlikely you could write Microsoft Word or a modern browser in assembly.
And this I think is true for games too, since, other than the performance requirement, they don't need the other features of Rust and are quite tolerant of failure. They also tend to be unwieldy beasts hard to design cleanly because the internal world simulation would become ever more complex, imposing weird data access patterns etc. If your online play code suddenly requires access to some internal "tank fuel" state, in C you would just pass the pointer and pray to the goods of rock and roll it's still valid at access time; a garbage collected language would at least give you that; but in Rust, you are looking at a complete refactoring of the entire "tank" module to make the new access pattern fit the ownership model.
As the post explains, this will kill quick iteration, which I think is a very general need of most programmers.
>> The problem you're having is only a problem because you haven't tried hard enough.
And it actually does work that way with Haskell, in my experience. There's a big hill to get over where you flail against the type system, IO monad and all, and then you realize that, while Haskell's type system isn't perfect, being able to say
is really pretty powerful, and being able to search for functions by type signature is just plain convenient.
But Haskell isn't for every problem in the way Rust is apparently made out to be. For example, I've seen some posts about developing games in Haskell, but it isn't common, and nobody would try to push a game developer into using Haskell.
> being able to search for functions by type signature is just plain convenient.
It's certainly not all the way there, but now that we are over the mostly empty promises of encapsulation and (worse) trying to model the world with classes, but grouping by that implicit first argument type for discoverability is exactly what OOP is, in this age of post-OOP.
The "you're not trying hard enough" position reminds me a lot of the Scala community's disdain for java-in-scala-syntax: if you don't use it like an almost-Haskell you're on your own (1). Here, I think Rust is actually more open: I don't read too much of the community, but most of what I saw seemed to be quite welcoming to the idea of placating the borrow checker with refcounting when "the rust way" fails to sufficiently click.
((1) but with Kotlin having taken over the entire not-almost-Haskell part of scala it's not an issue anymore: is has its niche and it fills it well, no more taking over the entire JVM while also magically converting everybody into an almost-Haskellian)
Maybe https://dev.epicgames.com/documentation/en-us/uefn/verse-lan... is as close as we're going to get to game dev Haskell.
Agree. Some languages like Haskell have a steep learning curve, until you grok it. Then you have a big productivity gain.
But this article is seeming about someone that has put in the time, has written a lot of Rust, and now says, it wasn't really worth it.
What does this after do with the topic?
I'm comparing one unusual language (Rust) with another language (Haskell) and examining why the first gets push-back whereas the second gets more positive mentions.
They both have a single odd idea that's hard to wrap your head around at first, Rust's borrow checker and Haskell's type system with its enforced immutability by default, and which intentionally drives program design, in that both languages demand you write your program such that the static analysis can prove it's valid, but Rust's borrow checker seems to get more people throwing their hands up and leaving the language than Haskell's type system does.
Haskell's type system can be a bit inexpressive, sometimes, too, and there are language extensions which address some of this, but it seems to hit more of a sweet spot where, in most programs, if the type system is forbidding something, you really do have some kind of error in your thinking leading to inconsistent code. Plus, it enables design instead of just forbidding, because you know that any function which is valid in the type system is at least sensical to use in a given context.
this reminds me of Lispen of ye olde.. wait untill it clicks, man!
He mentions Common Lisp as something he did a game in, and you can see the link he praises https://www.youtube.com/watch?v=72y2EC5fkcE as basically a very well-developed Lisp image approach with timetravel debugging etc aimed at game dev. So the implicit comparison to Lisps is sort of a big undercurrent to this whole article.
A lot of the stuff he mentions he wants I kept thinking "Oh, you want common lisp!"
I dabbled in some game dev in CL and loved it. I think the ideal would be low level engine, lisp on top driving it. If you could do it without the FFI barrier slowing things down a crazy amount, it would be the killer combo.
Lisp is pretty normal if you're accustomed to, like, Python: It's a GC'd procedural language.
Haha, nice one! :-)
(can only assume you're joking)
11 replies →
Yeah, this hits hard. Despite being proficient in a bunch of languages in college, I could just never wrap my poor brain around Lisp.
That’s sort of different, right? Rust is just another systems language. Lisp is the language that nobody knows but everybody secretly believes is better than their language of choice.
This was my biggest problem with rust, the community is, at a surface level friendly, but the moment you try to say something against the grain you get met with some of the most insufferable people ever. I tried to mention a problem with a lint on the official forms and the replies were so condescending (from regulars at that too). And at no point did they try to understand the issue, they just assumed I was dumb/new/doing something wrong.
The attitude is perhaps not surprising from a community whose unofficial tagline is "Rewrite it in Rust".
Sounds like a no-true-Scottsman fallacy
[dead]
>> The problem you're having is only a problem because you haven't tried hard enough.
>You just need to read another 50,000 word fasterthanlime essay. Then you'll not have problems any more.
I'm reminded of a line from Hachiman in Oregairu: "Something is only a problem when someone makes it a problem."