I don’t know what part of that is supposed to be an insult.

And the article may have talked of such stark differences, but I didn’t. I’m just saying that the resource usage is noticeably lower.

Yeah, you need to do tree-shaking with JavaScript to get rid of unused library code: https://developer.mozilla.org/en-US/docs/Glossary/Tree_shaking

I would expect larger corporate projects to do so. It is something that one needs to know about and configure, but if one senior webdev works on a project, they’ll set it up pretty quickly.

Major depressive disorder affected approximately 163 million people in 2017 (2% of the global population). The percentage of people who are affected at one point in their life varies from 7% in Japan to 21% in France.

https://en.wikipedia.org/wiki/Major_depressive_disorder#Epidemiology

This isn’t Reddit. You don’t need to talk in absolutes.

Similar to WittyShizard, my experience is very different. Said Rust application uses 1200 dependencies and I think around 50 MB RAM. We had a Kotlin application beforehand, which used around 300 dependencies and 1 GB RAM, I believe. I would expect a JavaScript application of similar complexity to use a similar amount or more RAM.

And more efficient languages do have an effect on RAM usage, for example:

• Not using garbage collection means objects generally get cleared from RAM quicker.
• Iterating over substrings or list elements is likely to be implement more efficiently, for example Rust has string slices and explicit .iter() + .collect().
• People in the ecosystem will want to use the language for use-cases where efficiency is important and then help optimize libraries.
• You’ve even got stupid shit, for example in garbage-collected languages, it has traditionally been considered best practice, that if you’re doing async, you should use immutable data types and then always create a copy of them when you want to update them. That uses a ton of RAM for stupid reasons.

Yeah, gonna be interesting. Software companies working on consumer software often don’t need to care, because:

• They don’t need to buy the RAM that they’re filling up.
• They’re not the only culprit on your PC.
• Consumers don’t understand how RAM works nearly as well as they understand fuel.
• And even when consumers understand that an application is using too much, they may not be able to switch to an alternative either way, see for example the many chat applications written in Electron, none of which are interoperable.

I can see somewhat of a shift happening for software that companies develop for themselves, though. At $DAYJOB, we have an application written in Rust and you can practically see the dollar signs lighting up in the eyes of management when you tell them “just get the cheapest device to run it on” and “it’s hardly going to incur cloud hosting costs”.
Obviously this alone rarely leads to management deciding to rewrite an application/service in a more efficient language, but it certainly makes them more open to devs wanting to use these languages. Well, and who knows what happens, if the prices for Raspberry Pis and cloud hosting and such end up skyrocketing similarly.

More Bs means it’s softer, so more graphite will get onto your paper when you draw a line, which makes it darker.

More Hs means it’s harder, so less graphite. The advantage is that it doesn’t get used up as quickly and you can draw finer lines, although the latter is kind of a given either way, since you’re using a mechanical pencil.

It might genuinely taste different to you, and not just be a matter of preferences. There’s gene variations that alter the taste: https://www.bbc.com/news/health-50387126

Personally, I also found that it’s something you have to get used to. I used to barely eat greens and wouldn’t feel terribly great, if I did.
Then, earlier this year, I spent a month eating lots of greens. I’m guessing my gut microbiome adjusted, because yeah, now I can eat a whole salad bowl for a meal and if I don’t have greens at home for a few days, I will start to feel unwell.

I mean, there is a reason why that is so pervasive. It makes you set up the dev environment and figure out how to run a program, which is a step that you cannot skip.

Of course, you should go for a slightly more complex project afterwards.

I’d guess, it’s a variation of this problem: https://en.wikipedia.org/wiki/Four_color_theorem

To be fair, you can also somewhat steer whether it will take off as a dev, by how you promote it and how much time you take to make it easily usable by others. Many devs really don’t care to have their passion projects take off, because it means you’ll likely spend less time doing your passion thing, more time doing user support.

Hmm, interesting, thanks!

Yeah, I get called a tankie on the regular now, just because my user account is on .ml and I still don’t actually know what it’s supposed to mean. Apparently, I’m supposed to have political opinions on topics that I’m significantly more ignorant on than the people who call me that.

Yeah, but anyone willing to implement shaders for Luanti can just contribute it to the game itself. Then you wouldn’t need to do anything to get the support.

I mean, Firefox Reader View is probably the closest you will get…

Yeah, I also use the Lemmy webpage on my phone. In particular, I want to be able to come back to posts later, when more of a discussion has unfolded, which is where browser tabs work really well.

I have never heard a guy decline a girl because she is poor.

I mean, I’ve never heard it said explicitly, and our still-largely-partriarchical society does expect and therefore respect penis-havers to bring home the money. So, it doesn’t matter that much, with how much money the person without the penis starts out with.

But I do think class differences implicitly still play quite a big role.
To some degree as part of secondary factors, for example you might look for an educated, physically fit partner, which a poor person cannot afford to take the time for.
To some degree, you just won’t ever get to know certain poor people, because they might not be able to afford the same hobby as you, or shopping at the expensive store etc…

But even if you do meet someone and they could tick your preferences, it is easy to dismiss their interest outright as just being about money, if you can tell that they have less of it than you.
Even in a patriarchical society, you don’t particularly want to be the guy where friends and family snicker that you’re being used…

Yeah, as I’m implementing this, I’m also now noticing how problematic that crate split is.

If you want to generate code which uses (non-generated) types that your crate provides in its public API, you have to re-export the macro from a separate crate that also re-exports the types.
That in itself is clunky, but it’s just complexity for the implementer, not the user, so it’s fine.

But where it stops being fine is that this means you cannot easily provide a usage example in the macro’s documentation.
If you try to use it like normal, it has to generate code referring to your API crate, which will not be defined in your macro crate, so the documentation test won’t compile.

So, basically your choices are:

• Do some hacky horseshit, where you try to re-define the public API in the usage example.
• Provide a usage example, which is not checked for compile errors.
• Provide a usage example on the module that re-exports the macro rather than on the macro itself.
• Don’t provide a usage example.

And yeah… if you’ve coded Rust for long enough, you will recognize these patterns of bad/missing usage examples, which is particularly problematic, because proc-macros are rarely terribly obvious to use. Really hope they can fix this sooner rather than later.
As far as I can tell, it would even be a valid fix, if editors and such consistently showed the documentation declared on top of the re-export, then you could write out your usage example there.

Canned tomatoes + salt 🙃

I always thought Wostershersauce was supposed to be BBQ-ish. 😅