Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Case for Memory Safe Roadmaps

nsa.gov

Post reply on HN
Print view View original

391–400 of 427 posts

Re: The Case for Memory Safe Roadmaps

#391

Post by pjmlp »

BaculumMeumEst wrote: post #224

In the world of graphics programming, you've got: - continuing accumulation of documentation and utility libraries from Khronos - excellent learning materials from the community - tons of legacy code all using C++. https://github.com/KhronosGroup/Vulkan-Utility-Libraries https://github.com/cg-tuwien/VulkanLaunchpad https://cescg.org/our-services/an-introduction-to-vulkan/ Until I see professionals get funding to buil…

Hence why goverment regulation, when laws come into place, Khronos and friends will get going.

It is no accident that Khronos has security critical certified subsets of OpenGL and Vulkan.

Re: The Case for Memory Safe Roadmaps

#392

Post by vlod »

synergy20 wrote: post #366
BaculumMeumEst wrote: post #224

In the world of graphics programming, you've got: - continuing accumulation of documentation and utility libraries from Khronos - excellent learning materials from the community - tons of legacy code all using C++. https://github.com/KhronosGroup/Vulkan-Utility-Libraries https://github.com/cg-tuwien/VulkanLaunchpad https://cescg.org/our-services/an-introduction-to-vulkan/ Until I see professionals get funding to buil…

The industry did not abandon C and C++ for Ada in the past, likely it will do the same to Rust. Not to mention C and C++ are both evolving and their toolchains are getting much better nowadays. After using Rust for a while, I actually decided to stay with to c/c++ for the rest of my career.

> I actually decided to stay with to c/c++ for the rest of my career.

Care to expand?

Re: The Case for Memory Safe Roadmaps

#393

Post by datameta »

dylan604 wrote: post #223
datameta wrote: post #208

Earlier quoted context omitted.

There might be a layer of humor you didn't pick up on.

or that this hype about the tech replacing programmers is not going to pan out. so maybe it is you who didn't pick up on something? to be able to provide commentary on a joke does not mean the joke was missed

it is possible that I missed out on what the other commenter meant but I wasn't trying to be derisive

Re: The Case for Memory Safe Roadmaps

#394

Post by BaculumMeumEst »

pjmlp wrote: post #391
BaculumMeumEst wrote: post #224

In the world of graphics programming, you've got: - continuing accumulation of documentation and utility libraries from Khronos - excellent learning materials from the community - tons of legacy code all using C++. https://github.com/KhronosGroup/Vulkan-Utility-Libraries https://github.com/cg-tuwien/VulkanLaunchpad https://cescg.org/our-services/an-introduction-to-vulkan/ Until I see professionals get funding to buil…

Hence why goverment regulation, when laws come into place, Khronos and friends will get going. It is no accident that Khronos has security critical certified subsets of OpenGL and Vulkan.

You are more optimistic than me. I would guess that if Khronos does not support Rust by that point, anyone in industry who is affected will adopt Carbon or whatever other path of least resistance brings them into compliance, and whatever that option is will take off.

Re: The Case for Memory Safe Roadmaps

#395

Post by vips7L »

trealira wrote: post #355
remexre wrote: post #341

Earlier quoted context omitted.

> In Java, the compiler inserts null checks before every single dereference and throws an exception for null references. Doesn't OpenJDK install a SIGSEGV handler, and generate the exception from that on a null dereference? (AFAIK, a lot of runtimes for GC'd languages that support thread-based parallelism do so anyway, because they can use mprotect to do a write barrier in hardware.)

> Doesn't OpenJDK install a SIGSEGV handler, and generate the exception from that on a null dereference? I thought I had read that they explicitly don't do that, but I can't find it anymore. You may be right. I should have checked before saying that. > (AFAIK, a lot of runtimes for GC'd languages that support thread-based parallelism do so anyway, because they can use mprotect to do a write barrier in hardware.) That…

> I thought I had read that they explicitly don't do that

This is exactly what they do: https://shipilev.net/jvm/anatomy-quarks/25-implicit-null-che...

When this happens it'll cause a deoptimization and recompilation of the code to include the null check rather than rely on the signal handler repeatedly.

Re: The Case for Memory Safe Roadmaps

#396

Post by pjmlp »

BaculumMeumEst wrote: post #394
pjmlp wrote: post #391

Earlier quoted context omitted.

Hence why goverment regulation, when laws come into place, Khronos and friends will get going. It is no accident that Khronos has security critical certified subsets of OpenGL and Vulkan.

You are more optimistic than me. I would guess that if Khronos does not support Rust by that point, anyone in industry who is affected will adopt Carbon or whatever other path of least resistance brings them into compliance, and whatever that option is will take off.

Khronos already has some Rust related stuff going on, it is no accident that WSGL looks as it is.

Right now the only C++ wannabe replacement that is as far ahead as Rust is Circle, and it is a big political issue with the community, unfortunately.

Forget about Carbon, Hylo or Cpp2.

Re: The Case for Memory Safe Roadmaps

#397

Post by hsbauauvhabzb »

citrin_ru wrote: post #177
hsbauauvhabzb wrote: post #77

Earlier quoted context omitted.

Sure, but even the best programmers can write buffer overflows and other memory issues. Not that average shops have any interest in actually training people, though.

Best programmers tend to work on the most complex software though. There are small and relatively simple C/C++ programs around which have no know memory issues (but a person with minimal viable knowledge can introduce new bugs even there and that's where training would be useful).

Sure and for every small and simple application there’s are hundreds of terrible apps. I actually think memory safety is a pretty poor measure (in my isolated world I rarely see C code).

I see plenty of php logic which is far more likely to be publicly exposed and generally of a terrible quality.

Re: The Case for Memory Safe Roadmaps

#398

Post by hulitu »

School-Cotton wrote: post #181
jvanderbot wrote: post #151

Earlier quoted context omitted.

Why are C and C++ considered the same, in these conversations? C++ at least has tools to make life significantly more safe. I can write a buffer overflow in any language, and on the scale of difficulty, ASM-C-C++-Rust-Python covers my experience (from easiest to fuck up to hardest). Yet nobody is calling for us to rewrite everything in python. Why is the line drawn at Rust? It's perfectly simple to trash memory in Ru…

Rust is memory safe by default, with unsafety as an optional feature that you basically never need to use unless you’re writing extremely low-level code, need absolute maximum performance, or are interfacing with libraries written in other languages. C++ is unsafe by default. Of course it’s just as easy to write bugs in unsafe Rust as it is in C++ (actually, it’s probably even easier), but defaults matter.

Who operates crates.io ?

Re: The Case for Memory Safe Roadmaps

#400

Post by School-Cotton »

hulitu wrote: post #398
School-Cotton wrote: post #181

Earlier quoted context omitted.

Rust is memory safe by default, with unsafety as an optional feature that you basically never need to use unless you’re writing extremely low-level code, need absolute maximum performance, or are interfacing with libraries written in other languages. C++ is unsafe by default. Of course it’s just as easy to write bugs in unsafe Rust as it is in C++ (actually, it’s probably even easier), but defaults matter.

Who operates crates.io ?

It’s owned by the Rust Foundation.
Post reply on HN