Notably absent from said list of languages: Google's Go
Memory Safe Languages in Android 13
441–450 of 606 posts
Re: Memory Safe Languages in Android 13
#442Notably absent from said list of languages: Google's Go
Hardly notable. Go is an application langage and managed runtime. Android already has that.
Re: Memory Safe Languages in Android 13
#443Earlier quoted context omitted.
This isn't primarily about replacing existing software. There are plenty of engineers that argue for continuing to use memory-unsafe programming languages. New projects written in C are being started every day. This is the exact equivalent of physicians continuing to use unsafe medical procedures, and what's worse, many of those engineers defend their dangerous practices by claiming there is no real danger in the fir…
> This isn't primarily about replacing existing software. There are plenty of engineers that argue for continuing to use memory-unsafe programming languages. > New projects written in C are being started every day. But it is mostly about existing software, even if its not about replacing existing software. I write C++ code every day. I hate it, and I'd rather not. But I use C++ libraries written by my teammates, and…
> > if the programmer is "smart enough".
> Can't defend this, but tbh I've never heard it.
Take a look at this comment: https://news.ycombinator.com/item?id=33824934
> Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them.
It is a somewhat common attitude in this type of thread.
Re: Memory Safe Languages in Android 13
#444Earlier quoted context omitted.
Which memory-unsafe language is more productive and has faster time -to-market than any managed language?
I'm pretty confident that systems programming (you know - moving data around) is easier with raw memory access compared to managed languages.
Is this a joke? Systems programming is a lot about accessing APIs, dealing with all sorts of intricacies like interrupts, different execution contexts, and managing memory as you said.
If you write in C and your program is complex enough, you will spend a lot of time just chasing segfaults and concurrency bugs and getting it to work the first time you write it. If your systems programming is in userspace, that's sort of fine. But if you're in kernel or on bare metal, the cost of debugging goes up by an order of magnitude. There's no debuggers on bare metal, and nobody can tell you how your program crashed—the device just stops responding, that's it.
That's why safe languages make even more sense in these restricted environments. If you get twice fewer memory safety bugs while you're getting your program to work, that can reduce your development time like 5-6 times.
Re: Memory Safe Languages in Android 13
#445Earlier quoted context omitted.
Easy localizable via grep, and not full of UB and memory corruption issues, which is what the 70% of unsafety issues due to memory corruption on C, C++ and Objective-C relate to. At some level of the stack some Assembly or compiler intrisics are needed, not at every line of code.
Jikes is the one I'm most familiar with and people working on its runtime absolutely suffered from UB and memory corruption issues... obviously not throughout the whole standard library but that's not the case for other JVMs either. In fact the Jikes people found it nicer to work in Rust than in Java on components like the garbage collector, because it was a better fit for working safely with this kind of code and th…
Since when Jikes uses Rust?
Also bootstrapting a language always requiring using its subset for low level layers, apparently not an issue that many parts of C, C++ cannot be implemented only with what ISO provides on the standard.
Re: Memory Safe Languages in Android 13
#446Earlier quoted context omitted.
This isn't primarily about replacing existing software. There are plenty of engineers that argue for continuing to use memory-unsafe programming languages. New projects written in C are being started every day. This is the exact equivalent of physicians continuing to use unsafe medical procedures, and what's worse, many of those engineers defend their dangerous practices by claiming there is no real danger in the fir…
I'm one of those people who still write in C, and I like the experience. I've had a lot of fun, and haven't been burned by it, although statistically it's likely that I will be at some point. I've tried a lot of languages in the past, and am currently not willing to dive into a whole new ecosystem, re-learn all the best practices, and unlearn what's worked very well for me with sometimes no good replacement. Best pra…
It's not even about languages. Just using valgrind or sth similar as a part of CI would solve A LOT of issues.
Re: Memory Safe Languages in Android 13
#447Earlier quoted context omitted.
This isn't primarily about replacing existing software. There are plenty of engineers that argue for continuing to use memory-unsafe programming languages. New projects written in C are being started every day. This is the exact equivalent of physicians continuing to use unsafe medical procedures, and what's worse, many of those engineers defend their dangerous practices by claiming there is no real danger in the fir…
I'm one of those people who still write in C, and I like the experience. I've had a lot of fun, and haven't been burned by it, although statistically it's likely that I will be at some point. I've tried a lot of languages in the past, and am currently not willing to dive into a whole new ecosystem, re-learn all the best practices, and unlearn what's worked very well for me with sometimes no good replacement. Best pra…
Implementing a linked list in Rust is somewhat challenging because of the safety issues that arise. Luckily you don't have to, there's one in the standard library: https://doc.rust-lang.org/std/collections/struct.LinkedList....
The equivalent of a generic memcpy is probably something like a .clone() call on a generic type that implements Clone.
Re: Memory Safe Languages in Android 13
#448Earlier quoted context omitted.
> We should not bury C++ prematurely before answering the question - "what else is as fast and efficient as to replace it for OOP?" We have an answer: Rust. It's no longer premature, bury it.
How's Rust at doing OOP these days? (Assuming we're in a domain or situation where OOP is a good choice, of course.) I would love to know about any projects that do OOP well in Rust.
IMO Rust has most of the best bits of OOP (the ability to encapsulate functionality in an object with private fields and present a restricted public interface), without the bad bits (inheritance, and complex soups of objects all holding pointers to each other that make code flow hard to reason about)
Re: Memory Safe Languages in Android 13
#449Earlier quoted context omitted.
Semmelweis is ancient history. He was active at a time when regulations and "best practices" simply weren't a thing anywhere. Surgeons resisting checklists is new to me. Do you have a reference other than a TV show? My understanding until now was that checklists are extensively used in medicine.
Here are a couple articles to start pulling threads on > Despite all the evidence, Gawande admits that even he was skeptical that using a checklist in everyday practice would help to save the lives of his patients. > "I didn't expect it," Gawande says with a chuckle. "It's massively improved the kind of results that I'm getting. When we implemented this checklist in eight other hospitals, I started using it because I…
That first quote (as well as the rest of the article) supports the view that people tend to underestimate the usefulness of procedures they are not yet using and especially to overestimate their own abilities.
It also shows that social pressure is the opposite of what it was in Semelweiss time, even people who feel they are above such things start using them (and then some of them get convinced that they were wrong).
The part you quoted from your second link directly contradicts your claim that most surgeons don't think it improves safety (even if the 54.7% is among the 93.6% that use it that still gives 51% that think it improves safety).
Re: Memory Safe Languages in Android 13
#450No language can fix maliciously poor design. cough Pixel unlock cough . Maybe separate your views with a layer of security...
wow yeah i wonder why they even bothered writing this whole article, good point