4 ms·

In the world of graphics programming, you've got: - continuing accumulation of documentation and utility libraries from Khronos - excellent learning materials

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/KhronosGroup/Vulkan-Utility-Libraries https://github.com/cg-tuwien/VulkanLaunchpad https://github.com/cg-tuwien/VulkanLaunchpad https://cescg.org/our-services/an-introduction-to-vulkan/ https://cescg.org/our-services/an-introduction-to-vulkan/ Until I see professionals get funding to build, maintain, document, and create training materials for Rust bindings, I'm going to continue to assume there will not be movement in that sector. I don't think industry is going to throw away the C++ ecosystem and build greenfield projects on a foundation of hobby projects.

natsucks 3y ago
important comment.
synergy20 3y ago
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.
- vlod 3y ago
  > I actually decided to stay with to c/c++ for the rest of my career. Care to expand?
  - nextweek2 3y ago
    I’m not op of course, but from a career perspective you have to make choices based on what will give you the most opportunities in the future. Right now Rust is technically safer language but it doesn’t have the same amount of job postings and career opportunities as C++. That’s just an inertia problem. The conundrum is if you jump in early and risk the language becoming yet another language or do you wait and see. I haven’t coded C++ in 4 years, but my understanding is that the language is evolving to answer the threat Rust poses to it.
- pjmlp 3y ago
  Only because there weren't affordable compilers, everyone was cloning UNIX, and there weren't goverment mandates for the industry at large. There are still COBOL and Fortran developers, C and C++ won't go away tomorrow, even if the goverment says so, but it will be harder to use them in security clearance contexts, similar to hazardous goods.
angiosperm 3y ago
Importantly, if you look at lists of "C/C++" security holes, you find it is almost all C security holes. So when they write "C/C++" they are hoping you won't notice they are lying to you. The residue of holes in C++ code is about the same as JS, Python, etc. So just eliminating C and C-like constructs gets you to the same level of security as the other languages.
- worthless-trash 3y ago
  The way you have phrased this is very disingenuous. > Importantly, if you look at lists of "C/C++" security holes, you find it is almost all C security holes. So when they write "C/C++" they are hoping you won't notice they are lying to you. As these "C-isms" are part of the base language, and you cant 'opt out', this means the base language is still included in the lists. Most C++ applications still linked (and used symbols from) the system libc runtime. I do not write C++ with any regularity, because I like my C footguns and dont want additional layers of footguns in my code. last time I tried writing C++, it allowed you to use after free, access raw memory pointers with no validation, iterate off the end of arrays and integer overflow and underflow, all without using "C" style constructs. Maybe it has changed, maybe C++ is now not as insane as it used to be and smart auto magic pointers solve everything. I'd love to read about how modern C++ solves these issues, do you have any resources ?
  - rcxdude 3y ago
    modern-ish C++ has some tools that can make it easier, but fundamentally it's still unsafe, it's still proven pretty difficult to write a large C++ codebase without memory safety issues. (that said I would still personally prefer C++ to C, though the recent updates to the standard contain at best very small improvements from my point of view)
- pjmlp 3y ago
  Those C security holes are C++ security holes, since the day C++ decided to be a TypeScript for C.
pjmlp 3y ago
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.
- BaculumMeumEst 3y ago
  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.
  - pjmlp 3y ago
    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.
eternityforest 3y ago
In theory, I love the idea of rust. I'd probably like actually using it on real projects... but I don't have any use case. My only interactions with compiled languages all have legacy constraints, or involve someone else's project. ESP32 seems to have lots of Rust support work happening, so I can very easily imagine switching in a few years though. If I had a reason to write a new performance-critical non-embedded app I'd probably use Rust.

natsucks 3y ago

important comment.

synergy20 3y ago

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.

vlod 3y ago
> I actually decided to stay with to c/c++ for the rest of my career. Care to expand?
- nextweek2 3y ago
  I’m not op of course, but from a career perspective you have to make choices based on what will give you the most opportunities in the future. Right now Rust is technically safer language but it doesn’t have the same amount of job postings and career opportunities as C++. That’s just an inertia problem. The conundrum is if you jump in early and risk the language becoming yet another language or do you wait and see. I haven’t coded C++ in 4 years, but my understanding is that the language is evolving to answer the threat Rust poses to it.
pjmlp 3y ago
Only because there weren't affordable compilers, everyone was cloning UNIX, and there weren't goverment mandates for the industry at large. There are still COBOL and Fortran developers, C and C++ won't go away tomorrow, even if the goverment says so, but it will be harder to use them in security clearance contexts, similar to hazardous goods.

angiosperm 3y ago

Importantly, if you look at lists of "C/C++" security holes, you find it is almost all C security holes. So when they write "C/C++" they are hoping you won't notice they are lying to you. The residue of holes in C++ code is about the same as JS, Python, etc. So just eliminating C and C-like constructs gets you to the same level of security as the other languages.

worthless-trash 3y ago
The way you have phrased this is very disingenuous. > Importantly, if you look at lists of "C/C++" security holes, you find it is almost all C security holes. So when they write "C/C++" they are hoping you won't notice they are lying to you. As these "C-isms" are part of the base language, and you cant 'opt out', this means the base language is still included in the lists. Most C++ applications still linked (and used symbols from) the system libc runtime. I do not write C++ with any regularity, because I like my C footguns and dont want additional layers of footguns in my code. last time I tried writing C++, it allowed you to use after free, access raw memory pointers with no validation, iterate off the end of arrays and integer overflow and underflow, all without using "C" style constructs. Maybe it has changed, maybe C++ is now not as insane as it used to be and smart auto magic pointers solve everything. I'd love to read about how modern C++ solves these issues, do you have any resources ?
- rcxdude 3y ago
  modern-ish C++ has some tools that can make it easier, but fundamentally it's still unsafe, it's still proven pretty difficult to write a large C++ codebase without memory safety issues. (that said I would still personally prefer C++ to C, though the recent updates to the standard contain at best very small improvements from my point of view)
pjmlp 3y ago
Those C security holes are C++ security holes, since the day C++ decided to be a TypeScript for C.

pjmlp 3y ago

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.

BaculumMeumEst 3y ago
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.
- pjmlp 3y ago
  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.

eternityforest 3y ago

In theory, I love the idea of rust. I'd probably like actually using it on real projects... but I don't have any use case. My only interactions with compiled languages all have legacy constraints, or involve someone else's project. ESP32 seems to have lots of Rust support work happening, so I can very easily imagine switching in a few years though. If I had a reason to write a new performance-critical non-embedded app I'd probably use Rust.