101–110 of 137 posts
Earlier quoted context omitted.
Niche as in “where it makes sense to use it because the strengths of the language support your important goals and the weaknesses don't kill you” as opposed to using it because it's one of the most used languages in the world.
Which emphasizes my point. There are few places where C's strength is not prevalent and its weaknesses won't kill you.
Earlier quoted context omitted.
I don't understand this type of reaction every time the problems of C/C++ are highlighted. Yes, of course the problems can be migitated using tools, but clearly this is not being done or is not as thorough or practical a solution as making it the language's responsibility. There's hoops that you must jump through to make C/C++ safe and clearly this just doesn't happen in practice. The same hoops just don't exist for…
Rust is the right approach since it figures everything out at compile time. But it still has to prove itself. And what is the timeline for a browser completely re-implemented in Rust? 5 years? 10 years? Suggesting that throwing away and rewriting our entire software foundation that has been written in the past 50 years is just silly. To be realistically achievable we need an incremental approach to gradually analyze…
Earlier quoted context omitted.
No need to panic, nobody is coming to take your precious pointer arithmetic away. If you want to write unsafe code, go ahead. But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. We're talking about classes of security bugs that just don't exist in managed languages. Bugs that can't happen in languages like Rust either because it forces programmers to indicate ownership…
> But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. Wrong. You can write perfectly safe code in C++. You seem to have this ridiculous idea that pointer arithmetic is mandatory on C++. "Pointer arithmetic" is not a feature of C++. It's a feature of how computers work. C++ allows you to do it if you want . Memory pools are not a C++ feature, memory pools are part of how…
> So like C++ with unique_ptr, shared_ptr, and RAII?
Ugh... these kinds of extreme posts really piss me off. Yes, C is unsafe. Yes, there are safer higher level languages, but there's a reason C is used. Because it's REALLY freaking fast, and allows you to actually tune how memory is used. The issue with C is not the language itself. It's the complexity of the project. Once a project reaches a certain size, no programmer will be able to keep the entire thing in their h…
> Assuming Chrome is rewritten in Rust or Go, will these security
> issues vanish? Of course not
> 70% of the high-risk bugs in Chrome 44 would have been prevented
> if Chrome were written in a memory-safe language instead of C/C++.
So what language to you propose we use to rewrite all video and audio software? Javascript, Lua, Brainfuck, what? Sure make every numeric value a double, nobody ever wants a char. Don't allow contiguous blocks of memory. Or if you do check every access is within the bounds. Its all safe! Nobody cares that suddenly we can't decode an MP3 in realtime. Are you going to outlaw assembly too? What utter insanity.
I suppose the answer would be Rust or similar because they aim to be as fast as C/++; however, that is currently only a goal and most certainly not the reality (according to some source I read a month or two back that I can no longer find). I also hope to end C/++, but it's simply not time yet.
> (according to some source I read a month or two back that
> I can no longer find).
Earlier quoted context omitted.
Please show me how to implement a graph library without using unsafe in Rust.
I've never actually used Rust myself - I'm just familiar with their goals: so I'm not entirely sure what you are referring to. Just keep in mind that the amount of work done on the various C++ compilers is most likely measured in man-decades, where Rust is probably still man-hours. Do you mean a directed graph or a graphical graph? I've implemented directed graphs in at least two different managed languages (which ar…
> Rust is probably still man-hours.
1. We use LLVM, so all that time is working for us as well.
2. Mozilla has been paying at least 4 people for at least a
few years to write Rust full-time, I would bet we're coming
up on a person-decade of time for Rust. The project has existed
for eight years in total, though four of that was just as a side
project.I'm confused when the author says the DOM is garbage collected only in IE/Blink. How is DOM memory managed elsewhere? At first guess, I thought the JavaScript runtime (which surely always uses garbage collection) would manage the DOM, but I'm guessing that's not actually the case. Who is typically in charge of memory management at that layer?
Is there even an operating system not written in asm/C/C++ to run these "secure" non-C/C++ applications?
Earlier quoted context omitted.
> But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. Wrong. You can write perfectly safe code in C++. You seem to have this ridiculous idea that pointer arithmetic is mandatory on C++. "Pointer arithmetic" is not a feature of C++. It's a feature of how computers work. C++ allows you to do it if you want . Memory pools are not a C++ feature, memory pools are part of how…
> So like C++ with unique_ptr, shared_ptr, and RAII? It is like that, but with stronger guarantees and less overhead.
Smart pointers in C++ are very slim, which overhead are you referring to? And which are the stronger guarantees?
Earlier quoted context omitted.
I don't understand this type of reaction every time the problems of C/C++ are highlighted. Yes, of course the problems can be migitated using tools, but clearly this is not being done or is not as thorough or practical a solution as making it the language's responsibility. There's hoops that you must jump through to make C/C++ safe and clearly this just doesn't happen in practice. The same hoops just don't exist for…
Rust is the right approach since it figures everything out at compile time. But it still has to prove itself. And what is the timeline for a browser completely re-implemented in Rust? 5 years? 10 years? Suggesting that throwing away and rewriting our entire software foundation that has been written in the past 50 years is just silly. To be realistically achievable we need an incremental approach to gradually analyze…