@R. L. Dane :debian: :openbsd: @Michael Dexter I think they're talking about the energy usage of running the already compiled code, which is somewhat fair, but decidedly not the whole picture.
@me I figured, but man, that's annoying. It's one thing if it's compiled "once" and run a million times, but when compiling it yourself is the only option (like in the case of a lot of minor projects), rust is decidedly *not* environment-friendly, I don't care what the hype machine says.
@RL_Dane Agree, I've only heard negative comments about #RustLang's build system, too heavy etc., I really doubt it's on the same level as C (measured by compilation speed and HW requirements). I've seen this list one year ago and it's quite old, it definitely needs to be updated. However #Clang will stay no1 and #Python will still be one of the most energy/speed ineffective languages. @me @dexter
@teotwaki Indeed I may, I won't disagree. However the difference in the list between C and Rust seems really weird. I've heard that Rust is already being used for small parts of the Linux kernel development, so it must be really effective while running, but we are talking about energy for compilation, of course. Is Rust as close to Assembler language as C? @RL_Dane @me @dexter
@𝖆𝖒𝖆𝖗𝖔𝖐 🇨🇿🇪🇺 I am by no means an expert on this, but from what I've seen, Rust gives you really tight control (on a level comparable to C) over what the actual machine hardware is doing.
The thing that I think makes compilation more expensive is the amount of checks of your code that have to be done at compile time to make sure it's handling memory safely. These checks are done only at compile time, and do not incur much (if any) of a performance cost at runtime. If I am misinformed on this point, please do correct me.
Like anything else in software development, there are always trade-offs being made. Those decisions tend to be subjective, but there's never a shortage of people with strong opinions about them.
@yar Well, that was my question, I don't know Rust, but I know C (which used to be a high level language, but from today's perspective it's low level, that's why I compared it to ASM even though there's a big difference of course). For example if Rust's memory safety is only secured by automated code checks before compilation then it can be regarded as low-level in this matter, because malloc and free etc. has to be done manually in Rust as well (?) @teotwaki @RL_Dane @me @dexter
@𝖆𝖒𝖆𝖗𝖔𝖐 🇨🇿🇪🇺 Free happens on its own, but at a time predetermined by the compiler. It's a very strange concept and difficult to wrap one's head around, but seems rather elegant in theory.
I haven't used Rust enough to have an actual experienced practical opinion on the matter, though.
I'm trying to NOT be a hater/curmudgeon (or "scrogneugneurd," as I like to call it), but Rust reminds me so much of the classic Homer Simpson meme where he's got all of his fat bound up behind him so he looks like a skinny stud to Marge, but all the fat and wrinkles are pinned to his back with binder clips and clothes pins, lol.
So, Rust makes this amazing object code that can even please the irascible taste/opinion/intellect of someone like Linus Torvalds, but the build process would make a Raspberry Pi beg for mercy.
There's more to making a good language than execution speed and making devs happy with language features. Those are important, but they aren't everything.
One thing I will say is that in the 80s, compilation (even for C) was a very heavy process that required beefy hardware. But by the mid-90s, it became a non-event which was part of the beauty of open source: you could always just compile it yourself, especially with good build scripts, and later, build systems.
So, it's not unprecedented for compilation to be a hardware-heavy endeavour, but... it does go against the grain, at least to me.
cc:ing @sotolf, but please be on your best behavior, brother.
we already have a language that wanted all the features, it's called c++ and rust is well on it's way to join it in complexity. It's also a rather ugly language with half assed functional language features.
Ada is a beautiful language, some things are just a bit annoying with it, which is why I'm mostly on nim and zig, I'm too stupid for c personally, too spoiled with having premade data-structures that I can use.
@cy @RL_Dane @me 16GB of RAM isn't a lot. I thought you might be posting from the 3rd world and maybe it's more expensive there, but you're posting from fucking Hillsboro, dude. You live next to an Intel fab shop. You can afford 16GB ram if you really want to. I'm on food stamps and I could afford 16GB ram if I needed it.
@me @MzAprilDaniels … it is possible to be concerned about other people. My daily driver has 64GB of RAM but I still advocate for developing software that can run on much smaller systems, because I empathize with the huge portion of humanity that still has difficulty with access (not to mention ewaste and resource utilization issues).
Well I do worry about third world countries, but yeah any RAM that I have was pretty much a gift. Intel isn't giving me a dime. Don't know where I'd come up with the... wait why am I remembering it being more expensive? That's like the cost of a pizza. Which I also can't afford, BUT STILL
"Just throw more hardware at it" is a pretty abysmal solution, IMHO.
Some of my machines are fixed at 4GiB of RAM without the ability to upgrade them. I still manage to do wonderful things with those machines... EVEN compile rust code -- with -j1 set 🤣
@cy @RL_Dane @me i haven't yet found specs for the specific model/install that Ritchie's department worked with, but it looks like a bare-bones system would *start* at about $3,000 in 1972 dollars. That translates to somewhere in the ballpark of $20,000 in 2024 dollars.
and that's just the base hardware; it doesn't cover the cost of the necessary training or installation/wiring.
@cy @RL_Dane @me and realistically, there was no way to operate/maintain the thing without paid employees. So implicit in all of this is the cost of funding an entire department of human beings to work on it; that $20k adjusted price tag would have been among the *cheapest* expenses paid for by any entity that bought this machine.
@cy @RL_Dane @me I can compile Rust software on my Raspberry Pi. I don’t do it very often because it’s obviously slow, but so is compiling and linking large software written in C. I am most often compiling Rust on a 10 year old laptop with 8GB of ram and it’s perfectly capable. I would be happier with a faster machine but that’s true for any other language.
@cy I agree that it’s important to keep tools accessible, and large RAM footprint isn’t accessible for a whole lot of people.
But I lifted an eyebrow at your assertion that C was made in a time that there were no privileged “can compile” classes. The 70s and 80s were a time when even access to a computer at all was privileged. Hell, C compilers were expensive and proprietary until 1987.
We do need to be careful not to wall off computing, but democratization of computing is a relatively new phenomenon and IMO nothing is gained by imagining it was somehow better in some imaginary, halcyon past.
In the early 80s there was an alternative: build you own computer. There were plenty of kits and a savvy person could get a system for a lot less money than, say, an Apple //.
Software was a problem--one had to steal compilers because $500 was a lot for a buggy, bare bones compiler with a thin run-time.
"steal" except this was pre-DMCA and the Hacker Menace moral panic laws hadn't yet ruined the rule of law and the Internet in one fell swoop. So it wasn't illegal to use someone's program without paying for it. Bill Gates was famously furious about this, when he was in college and found he couldn't extort people for money.
Take? Need? No reason to use their bogus terminology.
Software was a problem--$500 was a lot for a buggy, bare bones compiler with a thin run-time. People who needed a compiler had to defy the businesses demanding money for it, and many feared to do that, even when it was legal.
javascript has really proven that if you just double down hard enough you can make any language really fast and energy efficient once several mega corporations have thrown lifetimes into making fast runtimes and all the hardware vendors have specifically modified their chip designs to make your language run faster
R. L. Dane :debian: :openbsd:
in reply to Michael Dexter • • •How the heck is JS lighter than Perl?
Get the pitchforks and torches! XD
P.S. What the crap, Rust is #2? Have they ever tried compiling rust?!? It requires its own nuclear reactor!! 😄
Jonathan Lamothe
in reply to R. L. Dane :debian: :openbsd: • •like this
Leonardo Ferreira Fontenelle, R. L. Dane :debian: :openbsd:, Michael Dexter, pixx and prozacchiwawa like this.
R. L. Dane :debian: :openbsd:
in reply to Jonathan Lamothe • • •I figured, but man, that's annoying.
It's one thing if it's compiled "once" and run a million times, but when compiling it yourself is the only option (like in the case of a lot of minor projects), rust is decidedly *not* environment-friendly, I don't care what the hype machine says.
Haelwenn /элвэн/ :triskell: likes this.
𝖆𝖒𝖆𝖗𝖔𝖐 🇨🇿🇪🇺
in reply to R. L. Dane :debian: :openbsd: • • •Agree, I've only heard negative comments about #RustLang's build system, too heavy etc., I really doubt it's on the same level as C (measured by compilation speed and HW requirements).
I've seen this list one year ago and it's quite old, it definitely needs to be updated. However #Clang will stay no1 and #Python will still be one of the most energy/speed ineffective languages.
@me @dexter
Sebastian Lauwers
in reply to 𝖆𝖒𝖆𝖗𝖔𝖐 🇨🇿🇪🇺 • • •@amarok @RL_Dane @me If you’ve “only heard negative things” then you might suffer from selective hearing. Plenty of people are happy with it.
For 95% of projects, Cargo provides an insanely easy and effective bootstrap that C couldn’t even dream of providing.
𝖆𝖒𝖆𝖗𝖔𝖐 🇨🇿🇪🇺
in reply to Sebastian Lauwers • • •Indeed I may, I won't disagree. However the difference in the list between C and Rust seems really weird. I've heard that Rust is already being used for small parts of the Linux kernel development, so it must be really effective while running, but we are talking about energy for compilation, of course. Is Rust as close to Assembler language as C?
@RL_Dane @me @dexter
Jonathan Lamothe
in reply to 𝖆𝖒𝖆𝖗𝖔𝖐 🇨🇿🇪🇺 • •@𝖆𝖒𝖆𝖗𝖔𝖐 🇨🇿🇪🇺 I am by no means an expert on this, but from what I've seen, Rust gives you really tight control (on a level comparable to C) over what the actual machine hardware is doing.
The thing that I think makes compilation more expensive is the amount of checks of your code that have to be done at compile time to make sure it's handling memory safely. These checks are done only at compile time, and do not incur much (if any) of a performance cost at runtime. If I am misinformed on this point, please do correct me.
Like anything else in software development, there are always trade-offs being made. Those decisions tend to be subjective, but there's never a shortage of people with strong opinions about them.
𝖆𝖒𝖆𝖗𝖔𝖐 🇨🇿🇪🇺 likes this.
Yaroslav
in reply to 𝖆𝖒𝖆𝖗𝖔𝖐 🇨🇿🇪🇺 • • •@amarok @teotwaki @RL_Dane @me > Assembler language as C
I bag your pardon, how is that C is closer to assembler than rust?
𝖆𝖒𝖆𝖗𝖔𝖐 🇨🇿🇪🇺
in reply to Yaroslav • • •Well, that was my question, I don't know Rust, but I know C (which used to be a high level language, but from today's perspective it's low level, that's why I compared it to ASM even though there's a big difference of course). For example if Rust's memory safety is only secured by automated code checks before compilation then it can be regarded as low-level in this matter, because malloc and free etc. has to be done manually in Rust as well (?)
@teotwaki @RL_Dane @me @dexter
Jonathan Lamothe
in reply to 𝖆𝖒𝖆𝖗𝖔𝖐 🇨🇿🇪🇺 • •@𝖆𝖒𝖆𝖗𝖔𝖐 🇨🇿🇪🇺 Free happens on its own, but at a time predetermined by the compiler. It's a very strange concept and difficult to wrap one's head around, but seems rather elegant in theory.
I haven't used Rust enough to have an actual experienced practical opinion on the matter, though.
𝖆𝖒𝖆𝖗𝖔𝖐 🇨🇿🇪🇺 likes this.
David Jaša
in reply to 𝖆𝖒𝖆𝖗𝖔𝖐 🇨🇿🇪🇺 • • •Have you already read queue.acm.org/detail.cfm?id=32… ? 🙂
C Is Not a Low-level Language - ACM Queue
queue.acm.orgcy
in reply to R. L. Dane :debian: :openbsd: • • •Jonathan Lamothe
in reply to cy • •@Cy A valid criticism, but how do you know you can trust your compiler? Your OS? Your CPU?
Like I said, there are always trade-offs.
R. L. Dane :Debian:
in reply to cy • • •I'm trying to NOT be a hater/curmudgeon (or "scrogneugneurd," as I like to call it), but Rust reminds me so much of the classic Homer Simpson meme where he's got all of his fat bound up behind him so he looks like a skinny stud to Marge, but all the fat and wrinkles are pinned to his back with binder clips and clothes pins, lol.
So, Rust makes this amazing object code that can even please the irascible taste/opinion/intellect of someone like Linus Torvalds, but the build process would make a Raspberry Pi beg for mercy.
There's more to making a good language than execution speed and making devs happy with language features. Those are important, but they aren't everything.
One thing I will say is that in the 80s, compilation (even for C) was a very heavy process that required beefy hardware. But by the mid-90s, it became a non-event which was part of the beauty of open source: you could always just compile it yourself, especially with good build scripts, and later, build systems.
So, it's not unprecedented for compilation to be a hardware-heavy endeavour, but... it does go against the grain, at least to me.
cc:ing @sotolf, but please be on your best behavior, brother.
sotolf
in reply to R. L. Dane :Debian: • • •sotolf
in reply to cy • • •Mz. April Daniels
in reply to cy • • •Jonathan Lamothe doesn't like this.
calcifer :nes_fire:
in reply to Mz. April Daniels • • •@me @MzAprilDaniels … it is possible to be concerned about other people. My daily driver has 64GB of RAM but I still advocate for developing software that can run on much smaller systems, because I empathize with the huge portion of humanity that still has difficulty with access (not to mention ewaste and resource utilization issues).
// @cy @RL_Dane @dexter
cy likes this.
cy
in reply to Mz. April Daniels • • •Well I do worry about third world countries, but yeah any RAM that I have was pretty much a gift. Intel isn't giving me a dime. Don't know where I'd come up with the... wait why am I remembering it being more expensive? That's like the cost of a pizza. Which I also can't afford, BUT STILL
I might just be full of shit.
R. L. Dane :debian: :openbsd:
in reply to Mz. April Daniels • • •"Just throw more hardware at it" is a pretty abysmal solution, IMHO.
Some of my machines are fixed at 4GiB of RAM without the ability to upgrade them. I still manage to do wonderful things with those machines... EVEN compile rust code -- with -j1 set 🤣
Love your header image, BTW.
Edit: added quotation marks.
sotolf
in reply to Mz. April Daniels • • •cy likes this.
cy reshared this.
James Widman
in reply to cy • • •@cy @RL_Dane @me i was with you up until:
> C was created back before they could create a privileged caste who can feasibly compile stuff.
C was created in 1972 on a PDP-11.
have you priced a PDP-11 from that time?
dbit.com/pub/pdp11/faq/faq.pag…
The PDP-11 FAQ
www.dbit.comcy likes this.
cy reshared this.
James Widman
in reply to James Widman • • •@cy @RL_Dane @me i haven't yet found specs for the specific model/install that Ritchie's department worked with, but it looks like a bare-bones system would *start* at about $3,000 in 1972 dollars. That translates to somewhere in the ballpark of $20,000 in 2024 dollars.
and that's just the base hardware; it doesn't cover the cost of the necessary training or installation/wiring.
one does not simply unbox a PDP-11!
James Widman
in reply to James Widman • • •James Widman
in reply to James Widman • • •cy
in reply to James Widman • • •cassie
in reply to cy • • •calcifer :nes_fire:
in reply to cy • • •@cy I agree that it’s important to keep tools accessible, and large RAM footprint isn’t accessible for a whole lot of people.
But I lifted an eyebrow at your assertion that C was made in a time that there were no privileged “can compile” classes. The 70s and 80s were a time when even access to a computer at all was privileged. Hell, C compilers were expensive and proprietary until 1987.
We do need to be careful not to wall off computing, but democratization of computing is a relatively new phenomenon and IMO nothing is gained by imagining it was somehow better in some imaginary, halcyon past.
// @RL_Dane @dexter @me
cy
in reply to calcifer :nes_fire: • • •Andres Moreno
in reply to calcifer :nes_fire: • • •@calcifer @cy @RL_Dane @me
In the early 80s there was an alternative: build you own computer. There were plenty of kits and a savvy person could get a system for a lot less money than, say, an Apple //.
Software was a problem--one had to steal compilers because $500 was a lot for a buggy, bare bones compiler with a thin run-time.
I like the ethos of OLPC machines.
cy likes this.
cy reshared this.
cy
in reply to Andres Moreno • • •"steal" except this was pre-DMCA and the Hacker Menace moral panic laws hadn't yet ruined the rule of law and the Internet in one fell swoop. So it wasn't illegal to use someone's program without paying for it. Bill Gates was famously furious about this, when he was in college and found he couldn't extort people for money.
en.wikipedia.org/wiki/An_Open_…
open letter written by Bill Gates
Contributors to Wikimedia projects (Wikimedia Foundation, Inc.)Andres Moreno
in reply to cy • • •@cy
Yes, that's why I didn't say "pirate".
"Borrow" didn't seem to capture the annoyance we all had about the price of software.
cy likes this.
cy
in reply to Andres Moreno • • •Take? Need? No reason to use their bogus terminology.
somnule
in reply to Jonathan Lamothe • • •Rune, Prime Neutral
in reply to R. L. Dane :debian: :openbsd: • • •R. L. Dane :debian: :openbsd:
in reply to Rune, Prime Neutral • • •So true... I don't know whether to cheer or weep 😂
cy
in reply to Michael Dexter • • •Jonathan Lamothe
Unknown parent • •