atzanteol@sh.itjust.works
on 10 Nov 14:42
collapse
I did - it says he’s supporting rust in the kernel.
captain_aggravated@sh.itjust.works
on 10 Nov 18:51
collapse
I do know that Linus is on record with low opinion of C++. I have heard of him compare the cult-like following Rust has with the whole Vim/Emacs tribalism thing.
MajorHavoc@programming.dev
on 10 Nov 23:37
nextcollapse
I have heard of him compare the cult-like following Rust has with the whole Vim/Emacs tribalism thing.
Heh.
I do think the worst thing going for Rust, right now, is the Rust community.
It feels like few specific jackasses from the Java community made the jump to Rust, and no one had the sense to slap them with a newspaper.
Can you be more specific? I’ve had nothing but great experiences from the rust community.
MajorHavoc@programming.dev
on 11 Nov 17:16
collapse
Can you be more specific?
Sure.
I’ve had discussions about my impression that Rust’s build chain can be a bit surly compared to other popular languages.
I don’t particularly mean it as a criticism - of course Rust’s security enforcement comes with more warnings and errors.
But the novel part of the interactions, for me, was Rust community members coming at me with ‘well get gud, newbie’.
These interactions are particularly ironic, given my experiences and specialties. I’m an old school veteran software developer. I have spent over half of my career in dedicated Cybersecurity roles.
These conversations converted me from a mildly interested Rust proponent into a casual Rust critic.
they don’t swipe him at all. I don’t know why his picture is there
Swedneck@discuss.tchncs.de
on 11 Nov 13:00
collapse
because that makes people click
RobotToaster@mander.xyz
on 10 Nov 14:12
nextcollapse
Well now I’m going to have to use it even more.
it_depends_man@lemmy.world
on 10 Nov 14:14
nextcollapse
To address this concern, CISA recommends that developers transition to memory-safe programming languages such as Rust, Java, C#, Go, Python, and Swift.
If only it were that easy to snap your fingers and magically transform your code base from C to Rust.
guy_butterfly_meme.jpg is this unbiased journalism?
Successful_Try543@feddit.org
on 10 Nov 14:33
collapse
As the article is denoted as a comment, it is not its aim to be unbiased journalism.
In contrast to usual articles, comments usually elaborate on the opinion of the jounalist.
FizzyOrange@programming.dev
on 10 Nov 21:53
collapse
I don’t know why you’re being downvoted. It literally starts with the word OPINION in bold red caps.
Successful_Try543@discuss.tchncs.de
on 11 Nov 07:49
collapse
My mind was making one transfer to much, as the opinion clip in German TV news is called comment. There were no additional downvotes after I added the second sentence for clarification.
Ok, and what do you think the memory managers were written in?
Mihies@programming.dev
on 10 Nov 14:28
nextcollapse
I don’t think those are the problem, but rather how they are used. And in case of managed languages like C#, it’s almost impossible to shoot yourself in the foot when it comes to memory management. You still can, if you really wish, but you have to be very explicit in that. 🤷♂️
Who cares? Just like most things your average programmer relies on, they are written by smarter or at least more specialised people to make your job easier. They have learned to write memory-safe code so you don’t have to.
Don’t worry bud, I’ll upvote you. Not everyone is afraid of pointers.
onlinepersona@programming.dev
on 10 Nov 14:22
nextcollapse
Eventually, painfully, slowly, we’ll move to memory-safe languages. It really is a good idea. Personally, though, I don’t expect it to happen this decade. In the 2030s? Yes, 2020s? No.
This. Unless the government starts introducing fines or financial incentives (like fines) to force the use of memory-safe languages, ain’t nothing gonna happen.
thingsiplay@beehaw.org
on 10 Nov 14:31
nextcollapse
But there is context to it:
The report on Product Security Bad Practices warns software manufacturers about developing “new product lines for use in **service of critical infrastructure or [national critical functions] **NCFs in a memory-unsafe language (eg, C or C++) where there are readily available alternative memory-safe languages that could be used is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety.”
It’s for new products that are very important to critical infrastructure and need to be safe as possible. The article writer seem not to be aware of this context:
Take Rust in Linux, for example. Even with support from Linux’s creator, Linus Torvalds, Rust is moving into Linux at a snail’s pace.
Because Linux is the biggest software in the entire world and they do lot of stuff their own way. Rust is integrated slowly for future new projects. It makes sense to move in snail pace. The government doesn’t suggest the Linux project to stop using C entirely. The government “recommends” to start new projects in memory safe languages, if it is a critical software. That makes sense to me.
You see, people who’ve spent years and sometimes decades mastering C don’t want to master the very different Rust. They don’t see the point.
No, totally wrong. C programmers in Linux do not NEED to learn or master Rust. They just need to cooperate. The problem is, that some C programmers refuse to cooperate with Rust. They just want Rust to disappear. That has nothing to do with mastering the language. They refuse to make changes to their C code, so it can cooperate with Rust code via bindings.
After all, they can write memory-safe code in C, so why can’t you?
Nonsense argument, and false too. If that was the case, why do we have memory safe languages? Clearly people make mistake, old and new. Besides Linux is not the only software in the world.
Converting existing large codebases to memory-safe languages can be an enormous undertaking.
Nobody says old code should be rewritten in Rust. Neither the government, nor the Rust programmers in Linux suggest that. It’s not about rewriting code in memory-safe languages, its about new projects.
Either this article is a misrepresentation or misunderstanding. Or I misunderstand the article or government. I don’t know anymore…
They refuse to make changes to their C code, so it can cooperate with Rust code via bindings.
I don’t even think the rust devs where asking for that. They are refusing changes by rust devs that help with rust while making the c code clearer and even refuse to answer questions about the semantics behind the c code. At least as far as I can see from the outside.
…asking the maintainers to lock down APIs which the C devs purposefully leave malleable, in part, to avoid binary blob drivers being feasible.
…asking maintainers to accept code into their subsystem whilst being told, you don’t need to know Rust to an expert level…trust us. Cross language interfaces always have nuance and make good attack vectors. Understandable that maintainers are cautious.
…creating quite a lot of hassle for no a lot of improvement. Systems are only as resilient as their weakest components. The cross language interface is always going to be weak. Introducing a weakness to get improvements probably only succeeds at making the whole weaker.
refalo@programming.dev
on 10 Nov 17:13
nextcollapse
IIRC They were also trying to get kernel devs to let official structure definitions live in Rust instead of C, and got upset when they didn’t want to do that.
the rust devs wanted to CREATE official structure definitions that don’t exist in C so that there was more semantic meaning to the APIs
sukhmel@programming.dev
on 10 Nov 19:01
nextcollapse
What’s the reason to avoid binary blob drivers being feasible? Is that about not being able to use non-free binary blobs in kernel? I don’t quite understand what it even is about
Having binary blobs linked into your kernel is a maintainability nightmare. You’re allowing a third party to link their buggy drivers into the heart of your platform. It breaks any security model you have, and brings with a bunch of bugs that are impossible to debug.
Nvidia were the worst offender and it culminated in this:
Got it. I agree that their drivers are (were?) of exemplary bad quality
But I don’t think that it is realistically possible to drop all the proprietary firmware blobs, and if it’s not maybe it’s better to not actively sabotage something to ‘avoid those being feasible’?
Firmware don’t link to the kernel tho, and the kernel functions aren’t stable so a firmware today would stop working tomorrow because a function was refactored(and all the code in the kernel that depend on that function) for performance or security, and the binary can’t be refactored so it become useless
FizzyOrange@programming.dev
on 10 Nov 21:51
collapse
asking the maintainers to lock down APIs which the C devs purposefully leave malleable, in part, to avoid binary blob drivers being feasible.
No, they were asking them to define the semantics of the filesystem APIs. Those semantics are not encoded in the C API but the Rust devs wanted to encode them in the Rust API to avoid making mistakes.
The C devs didn’t want to, not because of concerns about binary drivers, but because the semantics are already broken. Apparently different filesystem drivers assume different semantics for the same functions and it’s a whole mess. They don’t want to face up to this and certainly don’t want anyone pointing it out, so clearly it must be the Rust devs’ fault for wanting APIs to have consistent semantics.
No, totally wrong. C programmers in Linux do not NEED to learn or master Rust. They just need to cooperate. The problem is, that some C programmers refuse to cooperate with Rust. They just want Rust to disappear. That has nothing to do with mastering the language. They refuse to make changes to their C code, so it can cooperate with Rust code via bindings.
I would argue that’s not the biggest problem, the biggest problem is that for you to refactor a function to work with rust, you need to refactor all the subsystems that rely on that function, and that take time, and you need to explain for the C dev why it need to be done, try to explain that for the amount of C devs in the kernel
Take Rust in Linux, for example. Even with support from Linux’s creator, Linus Torvalds, Rust is moving into Linux at a snail’s pace.
Because Linux is the biggest software in the entire world and they do lot of stuff their own way. Rust is integrated slowly for future new projects. It makes sense to move in snail pace. The government doesn’t suggest the Linux project to stop using C entirely. The government “recommends” to start new projects in memory safe languages, if it is a critical software. That makes sense to me.
Doubly so… Don’t care what the language is, or what the advantages are… Even if there’s a considerable security advantage to a new language… There’s no such thing as a language that’s advantages outweigh the security risks of rushed development to convert decades of tested code.
There’s no such thing as a language that’s advantages outweigh the security risks of rushed development to convert decades of tested code.
Who said or suggested that anyway? Other than bringing this up now. Who says to convert decades of tested code to rushed code of new language?? Do people read the stuff before they reply?
Rust is definitely a really cool language (as someone who has played with it just a little) but it’s quite headache inducing, at least for me at the moment.
itslilith@lemmy.blahaj.zone
on 10 Nov 22:12
nextcollapse
It has a steep learning curve, but it’s super nice to use once you’re over the initial bump
Mostly the ownership model, trying to remember which functions expect borrowed types or not, etc.
The error messages in rust are really good, so I can usually make the code work quickly, but I need to properly understand the reason behind the error in order to learn, so that’s when I get headaches
ScreaminOctopus@sh.itjust.works
on 10 Nov 22:36
nextcollapse
The main issue I have with rust is the lack of a rust abi for shared libraries, which makes big dependencies shitty to work with. Another is a lot of the big, nearly ubiquitous libraries don’t have great documentation, what’s getting put up on crates.io is insufficient to quickly get an understanding of the library. It’d also be nice if the error messages coming out of rust analyzer were as verbose as what the compiler will give you. Other than that it’s a really interesting language with a lot of great ideas. The iterator paradigm is really convenient, and the way enums work leads to really expressive code.
Documentation is generally considered one of the stronger points of rust libraries. Crates.io is not a documentation site you want docs.rs for that though it is generally linked to on crates.io. A lot of bigger crates also have their own online books for more in depth stuff. It is not that common to find a larger crate with bad documentation.
ScreaminOctopus@sh.itjust.works
on 12 Nov 21:16
collapse
One specific example I encountered was ndarray. I couldn’t figure out how to make a function take an array and an arrayslice without rewriting the function for both types. This could be because I’m novice with the language, but it didn’t seem obvious. I ended up giving up after trying to dig through the docs for a few hours and went back to C++.
asdfasdfasdf@lemmy.world
on 11 Nov 01:21
nextcollapse
Why not just use the C ABI?
And what libraries are you referring to? Almost all the ones I’ve used have fantastic docs.
ScreaminOctopus@sh.itjust.works
on 11 Nov 11:35
collapse
In my understanding, you can’t interface with the C abi without using an unsafe block.
FizzyOrange@programming.dev
on 11 Nov 17:28
nextcollapse
You can just use an unsafe block though. Or make a thin wrapper that is just safe functions that inside just have an unsafe block with the C ABI function.
Even if rust had a stable ABI, you would still need that unsafe block.
As someone that have worked in software for 30 years, and deplying complicated software, shared libraries is a misstake. You think you get the benefit of size and easy security upgrades, but due to deployment hell you end up using docker and now your deployment actually added a whole OS in size and you need to do security upgrades for this OS instead of just your application.
I use rust for some software now, and I build it with musl, and is struck by how small things get in relation to the regular deployment, and it feels like magic that I no longer get glibc incompatibility issues.
Maybe tackle that deployment hell instead of band-aiding it with docker?
FizzyOrange@programming.dev
on 11 Nov 17:26
collapse
He is. By using statically linked binaries.
Technically this is conflating two things: bundling dependencies and static/dynamic linking. But since you have to bundle your dependencies to use static linking, and there’s little point dynamic linking if you bundle your dependencies… most of the time they are synonymous.
Exceptions are things like plugins, but that’s pretty rare.
ScreaminOctopus@sh.itjust.works
on 11 Nov 23:48
collapse
Maybe for your use cases that’s OK, but there are many situations where the size and ease of upgrading provided by shared libraries is worthwhile. For example it would suck to need to push a 40+ GB binary to a fleet of systems with a poor or unreliable internet connection. You could try to mitigate this sort of thing by splitting the application up into microservices, but that adds complexity, and isn’t always a viable tradeoff if maximizing compute efficiency is also a concern.
I’m not so sure that dynamic libraries always reduces the size. Specially with libraries that are linked by a single binary.
With static libraries, you can conditionally compile only the features you’re gonna use. With dynamic libraries, however, the whole library must be compiled.
EDIT: just to clarify, I’m not saying that static libraries result always in less size. I’m saying that it’s not a black and white issue.
I don’t get why we’re taking a swing at Linus here. The article only mentions him in relation to the rust for Linux project being slow going. But, it IS going and the US government has only stated that “you need a plan to move to a memory safe language by 2025 or you might be liable if something bad happens as a result of the classics (use after free/double free/buffer overflow/etc.)” but I don’t think Linux would count it’s free software and it does have a plan.
HiddenTower@lemmy.world
on 11 Nov 01:07
nextcollapse
I thought the US Government bought a lot of software in Ada, so I hope they continue with that.
Just add @safe: after your module declaration, and you’ll be safe by default if you don’t want to wait until D3.
Also, unlike in Rust, you can opt-out from RAII with int foo = void;, although it primarily has a performance advantage with arrays, not singleton variables (might be also useful for aquiring an RNG seed in a dumb way).
UnfortunateShort@lemmy.world
on 11 Nov 10:12
nextcollapse
Jep, you got em, it’s all a conspiracy so they poison our mind with the evil tongues and make us corpo slaves with the help of Rust.
Rick_C137@programming.dev
on 12 Nov 15:08
collapse
The US government hates anything that can perform math too fast.
MajorasMaskForever@lemmy.world
on 12 Nov 00:19
nextcollapse
As someone who learned Ada for a defense job years ago, I’ve been wondering how long it was going to take until I saw others comparing Rust to it, both in the sense of the language “safety” goals and the USG pushing for it.
While the rust compiler is leagues better than any Ada compiler I ever had the misfortune of dealing with, the day to day pain that Rust incurs will probably always be a thorn in it’s side
Thanks, lol. I hope they realize soon that Rust is not forced to be used. Also the US government didn’t even talk about Rust only, but memory safe languages and listed Rust as an example.
LovableSidekick@lemmy.world
on 12 Nov 00:36
nextcollapse
yeah No.
rational_lib@lemmy.world
on 12 Nov 06:24
nextcollapse
Imagine if there was a hack so bad that it caused everyone to become unable to develop in C and C++.
Classic “let’s just make the cure worse than the disease” mindset among security enthusiasts.
Imagine if there was a hack so bad that it caused everyone to become unable to develop in C and C++.
Well, there is one that will imply you can only develop using anything that you have bootstrapped yourself, using hardware that you have designed and manufactured yourself, using tools that you have designed and manufactured yourself, using tools that you have designed and manufactured yourself …
threaded - newest
Why the swipe at Linus? He’s been supportive of rust in the Linux kernel.
Maybe read the article…
Anti Commercial-AI license
I did - it says he’s supporting rust in the kernel.
I do know that Linus is on record with low opinion of C++. I have heard of him compare the cult-like following Rust has with the whole Vim/Emacs tribalism thing.
Heh.
I do think the worst thing going for Rust, right now, is the Rust community.
It feels like few specific jackasses from the Java community made the jump to Rust, and no one had the sense to slap them with a newspaper.
Can you be more specific? I’ve had nothing but great experiences from the rust community.
Sure.
I’ve had discussions about my impression that Rust’s build chain can be a bit surly compared to other popular languages.
I don’t particularly mean it as a criticism - of course Rust’s security enforcement comes with more warnings and errors.
But the novel part of the interactions, for me, was Rust community members coming at me with ‘well get gud, newbie’.
These interactions are particularly ironic, given my experiences and specialties. I’m an old school veteran software developer. I have spent over half of my career in dedicated Cybersecurity roles.
These conversations converted me from a mildly interested Rust proponent into a casual Rust critic.
Well I’m sorry that you got shitty responses like that. Which platform(s) was this on?
Java sucked so much though (and still does).
I love programming in Java. It continues to be my language of choice.
Lets have a flame war like back in the day!
:-)
I didn’t understand this. He said the bickering between C and rust devs reminds him of the vim/emacs debate.
There’s no shortage of reasons to not like Linus.
Did… Did you just diss the All Mighty Father, Emperor of Linux on Lemmy?
He did! He did just diss the All Might Father, Emperor of Linux on Lemmy!
Unacceptable! Go get the SIGKILL
kill -9You gotta learn when it’s time for your thread to yield; you shoulda slept; instead you stepped and now your fate is sealed.they don’t swipe him at all. I don’t know why his picture is there
because that makes people click
Well now I’m going to have to use it even more.
guy_butterfly_meme.jpg is this unbiased journalism?
As the article is denoted as a comment, it is not its aim to be unbiased journalism.
In contrast to usual articles, comments usually elaborate on the opinion of the jounalist.
I don’t know why you’re being downvoted. It literally starts with the word OPINION in bold red caps.
My mind was making one transfer to much, as the opinion clip in German TV news is called comment. There were no additional downvotes after I added the second sentence for clarification.
Ok, and what do you think the memory managers were written in?
I don’t think those are the problem, but rather how they are used. And in case of managed languages like C#, it’s almost impossible to shoot yourself in the foot when it comes to memory management. You still can, if you really wish, but you have to be very explicit in that. 🤷♂️
Who cares? Just like most things your average programmer relies on, they are written by smarter or at least more specialised people to make your job easier. They have learned to write memory-safe code so you don’t have to.
More specialized is critical.
You have to understand your domain, what your goal is, how much time and money you have, etc.
God, this old argument… Careful, it’s an antique.
The idea is to minimize memory management and have people who are experts on it deal with it.
AFAIK, the first one was written in LISP.
The one most people push around here was written in Rust. It’s a really great language to write memory managers anyway.
If it’s broke, don’t fix it amiright?!
Don’t worry bud, I’ll upvote you. Not everyone is afraid of pointers.
This. Unless the government starts introducing fines or financial incentives (like fines) to force the use of memory-safe languages, ain’t nothing gonna happen.
Anti Commercial-AI license
But there is context to it:
It’s for new products that are very important to critical infrastructure and need to be safe as possible. The article writer seem not to be aware of this context:
Because Linux is the biggest software in the entire world and they do lot of stuff their own way. Rust is integrated slowly for future new projects. It makes sense to move in snail pace. The government doesn’t suggest the Linux project to stop using C entirely. The government “recommends” to start new projects in memory safe languages, if it is a critical software. That makes sense to me.
No, totally wrong. C programmers in Linux do not NEED to learn or master Rust. They just need to cooperate. The problem is, that some C programmers refuse to cooperate with Rust. They just want Rust to disappear. That has nothing to do with mastering the language. They refuse to make changes to their C code, so it can cooperate with Rust code via bindings.
Nonsense argument, and false too. If that was the case, why do we have memory safe languages? Clearly people make mistake, old and new. Besides Linux is not the only software in the world.
Nobody says old code should be rewritten in Rust. Neither the government, nor the Rust programmers in Linux suggest that. It’s not about rewriting code in memory-safe languages, its about new projects.
Either this article is a misrepresentation or misunderstanding. Or I misunderstand the article or government. I don’t know anymore…
I don’t even think the rust devs where asking for that. They are refusing changes by rust devs that help with rust while making the c code clearer and even refuse to answer questions about the semantics behind the c code. At least as far as I can see from the outside.
The Rust kernel devs are …
IIRC They were also trying to get kernel devs to let official structure definitions live in Rust instead of C, and got upset when they didn’t want to do that.
the rust devs wanted to CREATE official structure definitions that don’t exist in C so that there was more semantic meaning to the APIs
What’s the reason to avoid binary blob drivers being feasible? Is that about not being able to use non-free binary blobs in kernel? I don’t quite understand what it even is about
Having binary blobs linked into your kernel is a maintainability nightmare. You’re allowing a third party to link their buggy drivers into the heart of your platform. It breaks any security model you have, and brings with a bunch of bugs that are impossible to debug.
Nvidia were the worst offender and it culminated in this:
arstechnica.com/…/linus-torvalds-says-f-k-you-to-…
Got it. I agree that their drivers are (were?) of exemplary bad quality
But I don’t think that it is realistically possible to drop all the proprietary firmware blobs, and if it’s not maybe it’s better to not actively sabotage something to ‘avoid those being feasible’?
Firmware don’t link to the kernel tho, and the kernel functions aren’t stable so a firmware today would stop working tomorrow because a function was refactored(and all the code in the kernel that depend on that function) for performance or security, and the binary can’t be refactored so it become useless
No, they were asking them to define the semantics of the filesystem APIs. Those semantics are not encoded in the C API but the Rust devs wanted to encode them in the Rust API to avoid making mistakes.
The C devs didn’t want to, not because of concerns about binary drivers, but because the semantics are already broken. Apparently different filesystem drivers assume different semantics for the same functions and it’s a whole mess. They don’t want to face up to this and certainly don’t want anyone pointing it out, so clearly it must be the Rust devs’ fault for wanting APIs to have consistent semantics.
The rest of your comment is nonsense.
I would argue that’s not the biggest problem, the biggest problem is that for you to refactor a function to work with rust, you need to refactor all the subsystems that rely on that function, and that take time, and you need to explain for the C dev why it need to be done, try to explain that for the amount of C devs in the kernel
Doubly so… Don’t care what the language is, or what the advantages are… Even if there’s a considerable security advantage to a new language… There’s no such thing as a language that’s advantages outweigh the security risks of rushed development to convert decades of tested code.
Who said or suggested that anyway? Other than bringing this up now. Who says to convert decades of tested code to rushed code of new language?? Do people read the stuff before they reply?
How utterly disingenuous. That’s not what the CISA recommendation says, at all.
My friend from university sends me his Rust code snippets sometimes. Ngl it looks like a pretty cool language.
There was also that tldr reimplemention in Rust that is a gatrillion times faster than the original.
I really want to give it a try but I have executive dysfunction and don’t have any ideas of what I could use it for.
fn executive() {}
Rust is definitely a really cool language (as someone who has played with it just a little) but it’s quite headache inducing, at least for me at the moment.
It has a steep learning curve, but it’s super nice to use once you’re over the initial bump
What’s causing the most headache for you?
Mostly the ownership model, trying to remember which functions expect borrowed types or not, etc.
The error messages in rust are really good, so I can usually make the code work quickly, but I need to properly understand the reason behind the error in order to learn, so that’s when I get headaches
The main issue I have with rust is the lack of a rust abi for shared libraries, which makes big dependencies shitty to work with. Another is a lot of the big, nearly ubiquitous libraries don’t have great documentation, what’s getting put up on crates.io is insufficient to quickly get an understanding of the library. It’d also be nice if the error messages coming out of rust analyzer were as verbose as what the compiler will give you. Other than that it’s a really interesting language with a lot of great ideas. The iterator paradigm is really convenient, and the way enums work leads to really expressive code.
Documentation is generally considered one of the stronger points of rust libraries. Crates.io is not a documentation site you want docs.rs for that though it is generally linked to on crates.io. A lot of bigger crates also have their own online books for more in depth stuff. It is not that common to find a larger crate with bad documentation.
One specific example I encountered was ndarray. I couldn’t figure out how to make a function take an array and an arrayslice without rewriting the function for both types. This could be because I’m novice with the language, but it didn’t seem obvious. I ended up giving up after trying to dig through the docs for a few hours and went back to C++.
Why not just use the C ABI?
And what libraries are you referring to? Almost all the ones I’ve used have fantastic docs.
In my understanding, you can’t interface with the C abi without using an unsafe block.
I think there are some crates that wrap the unsafe code for you, e.g. github.com/rodrimati1992/abi_stable_crates/ (I haven’t ever tried it).
You can just use an unsafe block though. Or make a thin wrapper that is just safe functions that inside just have an unsafe block with the C ABI function.
Even if rust had a stable ABI, you would still need that unsafe block.
As someone that have worked in software for 30 years, and deplying complicated software, shared libraries is a misstake. You think you get the benefit of size and easy security upgrades, but due to deployment hell you end up using docker and now your deployment actually added a whole OS in size and you need to do security upgrades for this OS instead of just your application. I use rust for some software now, and I build it with musl, and is struck by how small things get in relation to the regular deployment, and it feels like magic that I no longer get glibc incompatibility issues.
Maybe tackle that deployment hell instead of band-aiding it with docker?
He is. By using statically linked binaries.
Technically this is conflating two things: bundling dependencies and static/dynamic linking. But since you have to bundle your dependencies to use static linking, and there’s little point dynamic linking if you bundle your dependencies… most of the time they are synonymous.
Exceptions are things like plugins, but that’s pretty rare.
Maybe for your use cases that’s OK, but there are many situations where the size and ease of upgrading provided by shared libraries is worthwhile. For example it would suck to need to push a 40+ GB binary to a fleet of systems with a poor or unreliable internet connection. You could try to mitigate this sort of thing by splitting the application up into microservices, but that adds complexity, and isn’t always a viable tradeoff if maximizing compute efficiency is also a concern.
I’m not so sure that dynamic libraries always reduces the size. Specially with libraries that are linked by a single binary.
With static libraries, you can conditionally compile only the features you’re gonna use. With dynamic libraries, however, the whole library must be compiled.
EDIT: just to clarify, I’m not saying that static libraries result always in less size. I’m saying that it’s not a black and white issue.
Of course its rewrite is nearly infinitely faster than the original JavaScript.
oh
lol
didn’t cross my mind that someone would make a CLI program in js
I mean, I’ve done it, but I am a registered dunce cap owner.
Well, so is that guy.
Too bad! Stay in your lane, pinche government!
lol ok.
I don’t get why we’re taking a swing at Linus here. The article only mentions him in relation to the rust for Linux project being slow going. But, it IS going and the US government has only stated that “you need a plan to move to a memory safe language by 2025 or you might be liable if something bad happens as a result of the classics (use after free/double free/buffer overflow/etc.)” but I don’t think Linux would count it’s free software and it does have a plan.
I thought the US Government bought a lot of software in Ada, so I hope they continue with that.
The comment section mentions that conundrum as well… quite interesting.
<img alt="" src="https://lemmy.world/pictrs/image/f27e5170-6398-416d-97cf-e06b1ac4b519.gif">
“Oh, I thought I was coding in Python. Oops!”
Continues coding in C++
Jython’s your Python
Because they want to replace them with more corporate-controlled languages.
<img alt="" src="https://lemmy.world/pictrs/image/2defd6a1-a48e-433b-978d-1fbbc3db2904.jpeg">
Just add
@safe:after yourmoduledeclaration, and you’ll be safe by default if you don’t want to wait until D3.Also, unlike in Rust, you can opt-out from RAII with
int foo = void;, although it primarily has a performance advantage with arrays, not singleton variables (might be also useful for aquiring an RNG seed in a dumb way).Jep, you got em, it’s all a conspiracy so they poison our mind with the evil tongues and make us corpo slaves with the help of Rust.
I don’t see python on your image :)
The US government has more pressing issues I think.
Maybe it can shut the fuck up an let me do my job in contrast to its judicial branch.
What if I told you the judicial branch is doing its job because it was always evil to begin with?
I would say you’re right
well, i’m glad the US government is at least aware what C and C++ are!
The comment thread in that article is interesting. Grep for Ada.
The US government hates anything that can perform math too fast.
As someone who learned Ada for a defense job years ago, I’ve been wondering how long it was going to take until I saw others comparing Rust to it, both in the sense of the language “safety” goals and the USG pushing for it.
While the rust compiler is leagues better than any Ada compiler I ever had the misfortune of dealing with, the day to day pain that Rust incurs will probably always be a thorn in it’s side
Thanks, lol. I hope they realize soon that Rust is not forced to be used. Also the US government didn’t even talk about Rust only, but memory safe languages and listed Rust as an example.
yeah No.
Imagine if there was a hack so bad that it caused everyone to become unable to develop in C and C++.
Classic “let’s just make the cure worse than the disease” mindset among security enthusiasts.
Well, there is one that will imply you can only develop using anything that you have bootstrapped yourself, using hardware that you have designed and manufactured yourself, using tools that you have designed and manufactured yourself, using tools that you have designed and manufactured yourself …
… with your own bare hands.
Need more carrot