I advise training programmers instead of throwing them in front of a screen without any training. Companies these days provides no training at all. When I was hired over 40 years ago, I spent plenty of time being trained for my first 3 months. Now, nothing, and you if you want to train a new person, you do it on your own time.
I wonder of part of the issue is that 40 years ago, people typically stayed much longer with companies. (I actually don't know what the norm was. My dad was an EE for the defense industry, and IIRC he worked for 3 different employers over his career.)
The Case for Memory Safe Roadmaps
171–180 of 427 posts
Re: The Case for Memory Safe Roadmaps
#172Their "Appendix: Memory Safe Languages" lists: C#, Go, Java, Python, Rust & Swift
what do we do about javascript?
On that note, try valgrind on existing javascript engines, you might be "entertained". (I certainly was, but that was some years back.
Re: The Case for Memory Safe Roadmaps
#173Earlier quoted context omitted.
As someone who has worked in C/C++ on teams for a while. My personal opinion is that safe C++ programmers never use pointers - put everything on the stack and use (usually const) references. But I've really got to ask - at that point do you really want to program in C++ anymore or is it just better to use a safer language that removes pointers entirely?
Do "references" even exist in C? Aren't they a C++ thing? How do you manage heap allocations without ever touching a pointer?
Re: The Case for Memory Safe Roadmaps
#174But how are we going to trade stocks in nano seconds without C++?!
High speed fiance is mostly done in Java and Haskell, because mistakes are expensive. (And yeah, it's one of the very few fields that Haskell enters the list.)
Re: The Case for Memory Safe Roadmaps
#175Their "Appendix: Memory Safe Languages" lists: C#, Go, Java, Python, Rust & Swift
It's unfortunate that there's no mention that not all these languages are equally safe. Go isn't memory safe when using goroutines. See: Golang data races to break memory safety: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
Do you have a single example in the last 14 years of memory safety exploit using the Go runtime? I'm talking about public and known exploit not ctf and the like.
Re: The Case for Memory Safe Roadmaps
#176Earlier quoted context omitted.
Fortran is probably as bad as C, and Ada isn't truly memory safe - they link to Ada/Spark which is but that doesn't seem to have much widespread use. https://www.adacore.com/about-spark
Isn't Ada/Spark in avionics the main use case for Ada these days? So, huge share of a tiny market?
Hasn't it always been? I'm no expert but always assumed that it was used basically military and avionics, and perhaps other safety critical equipment.
Re: The Case for Memory Safe Roadmaps
#177I advise training programmers instead of throwing them in front of a screen without any training. Companies these days provides no training at all. When I was hired over 40 years ago, I spent plenty of time being trained for my first 3 months. Now, nothing, and you if you want to train a new person, you do it on your own time.
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.
Re: The Case for Memory Safe Roadmaps
#178Re: The Case for Memory Safe Roadmaps
#179Re: The Case for Memory Safe Roadmaps
#180I advise training programmers instead of throwing them in front of a screen without any training. Companies these days provides no training at all. When I was hired over 40 years ago, I spent plenty of time being trained for my first 3 months. Now, nothing, and you if you want to train a new person, you do it on your own time.
"intentional training" (my term) is one of the most under utilized levers to pull for a team or organization to level up. Your observation aligns with my anecdotal experiences with teams, and it's sad to be honest. The pushback I've received is something I'd categorize as "cart before the horse" - executives want to know exactly what will be achieved with such effort before approving any expenditure. The teams I've b…