101–110 of 244 posts
Nowhere does it call out Rust by name. Go / Zig / Pony / Haskell are all valid contenders.
But I have always used Pascal for that. It has memory safe strings and arrays with refcounting, so long as one avoids using other features like pointers, classes, inline assembly, it is perfect.
Earlier quoted context omitted.
I would call C++ a memory safe language that has more than a superficial resemblance to C. Rust makes is more obvious when/where you are intentionally opting out, but most C++ memory bugs are where someone opted out of the modern C++ way to use the C way. (including new/delete as the C way).
> I would call C++ a memory safe language C++ is not, in any sense, a memory safe language.
To be fair actually using those features of C++ instead of the C legacy is still catching on. Most instructors aren't even teaching it.
Using C in C++ is like using unsafe everywhere in rust - you can do it, but you lose all the advantages.
Earlier quoted context omitted.
Go, Pony and Haskell all have complex runtimes and a GC, which makes them unsuitable for embedding into other applications or exposing them as widely usable libraries. Rust, Zig, and to a certain extent D or Nim without GC, can easily expose a C API and have a minimal runtime. But the others do not provide the same guarantees as (safe) Rust with the borrow checker. All very cool languages in their own right, but memo…
Nim is not using GC anymore [1], is memory safe and support formal methods [2] It's also introducing isolation [3] to provide safe multithreading similar to Rust's sendable. [1] https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... [2] https://nim-lang.org/docs/drnim.html [3] https://github.com/nim-lang/RFCs/issues/244
> ORC is Nim’s all-new cycle collector based on ARC. It can be considered a full-blown GC since it includes a local tracing phase (contrary to most other tracing GCs which do global tracing). ORC is what you should use when working with Nim’s async because it contains cycles that need to be dealt with.
Sooooo unless you
> disable the GC and do manual memory management, but then you lose access to most of the stdlib
you still have to run a memory-managing runtime
Earlier quoted context omitted.
I based my comment on Jens Gustedt's article [1] about adding a "defer" mechanism in standard C. Clearly, the C committee works hard on improving the language and they are in the process to standardize important features, such as lambda functions, auto, typeof (like C++'s decltype more or less), and so forth. In my humble opinion, "defer" can mild the buffer / memory overflow, but of course not permanently remedied i…
Defer seems more like a solution to making cleanup easier and less error prone, preventing memory/fd/mutex leaks. It wouldn't significantly improve memory safety IMO. Adding a "slice" type with checked bounds (something basically every C codebase in existence ends up reimplementing somehow) would be a much greater improvement IMO. But overall even though I still use C almost daily, I'm a bit skeptical of the committe…
I hate the mess that c++ is. It started out with a object based programming paradigm with c like syntax. Then generics/templates were added. Then we have modern c++. It's 3 different languages crammed into one. The c++ committee has a serious case of nifty-itis.
Earlier quoted context omitted.
> I would call C++ a memory safe language C++ is not, in any sense, a memory safe language.
Then you don't know anything about C++, only the C legacy it is built on. Modern C++ has good data structures and good memory management. To be fair actually using those features of C++ instead of the C legacy is still catching on. Most instructors aren't even teaching it. Using C in C++ is like using unsafe everywhere in rust - you can do it, but you lose all the advantages.
Would not be cheaper to fix those unsafe languages, such as C, and offer safe mechanisms that could be used upon need? Why spend thousands, if not millions of dollars, on rewriting existing codebases when they could help fixing the existing toolset and make it safer? I don't get it.
To me this idea sounds a lot like "why do we need IPV6? Why not keep IPV4 and add a few bytes?" except it's effectively almost the same amount of breakage. Either you're C-compatible or you're not. Making C memory-safe by adding extra annotations to allow for static zoning/borrow checking is possible, but the churn involved is probably not much different than rewriting in a different language. See Cyclone for instanc…
[DJB disagrees](https://cr.yp.to/djbdns/ipv6mess.html). Quote:
>The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.
> Either you're C-compatible or you're not.
If we take this black and white approach then we must say that C++ is not C compatible just like Ada isn't C compatible.
The reality is that C++ being broadly a superset of C was integral to its adoption, even though that compatibility isn't perfect. It enabled easy incremental porting of projects.
This is really just a nit though. I do agree with your conclusions.
Nowhere does it call out Rust by name. Go / Zig / Pony / Haskell are all valid contenders.
Or Ada or Wuffs But I have always used Pascal for that. It has memory safe strings and arrays with refcounting, so long as one avoids using other features like pointers, classes, inline assembly, it is perfect.
Edit: here's the link, interesting idea. https://github.com/google/wuffs
What is left out of the title is that they do not provide funding to the current authors/maintainers of these open source projects. Instead, they fund an organization that will rewrite these tools. Correct me if I’m wrong, but that’s my understanding of the rather terse article. I would rather have the original maintainers funded and still in control of the many pieces that form the basis of the major Linux distribut…
At least for curl the project leadership is closely involved, as evidenced by a related article on Stenbergs blog [1] and the ISRG annoucement [2], which mentions funding Stenberg directly and is actually linked from this anouncement... Please don't make statements like that without doing a minimal amount of effort to verify. [1] https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyp... [2] https://www.abetteri…
And from link #2 that you posted, I see they talk about the curl stuff, but also show a bunch of repos with tools rewritten from scratch, e.g. https://github.com/ctz/rustls
So I really cannot draw a conclusion one way or the other.
Normally I’m an optimist, but after the recent chromium misunderstandings, I am going to err on the cynical side.
Would not be cheaper to fix those unsafe languages, such as C, and offer safe mechanisms that could be used upon need? Why spend thousands, if not millions of dollars, on rewriting existing codebases when they could help fixing the existing toolset and make it safer? I don't get it.
I based my comment on Jens Gustedt's article [1] about adding a "defer" mechanism in standard C. Clearly, the C committee works hard on improving the language and they are in the process to standardize important features, such as lambda functions, auto, typeof (like C++'s decltype more or less), and so forth. In my humble opinion, "defer" can mild the buffer / memory overflow, but of course not permanently remedied i…
__attribute__((cleanup)) gcc/clang extension already works without extra blocks. GLib has been using it for a while https://blogs.gnome.org/desrt/2015/01/30/g_autoptr/
Nowhere does it call out Rust by name. Go / Zig / Pony / Haskell are all valid contenders.
Although I find it interesting that Common Lisp gets left off these lists. It's memory-safe (with GC of course), has great integration with existing C libraries via CFFI, has a formal spec, has a solid library ecosystem, supports a "mostly-functional-but-imperative-if-you-need-it" programming style, has optional/gradual compile-time type checking, and at least one open/libre implementation generates fast native code (SBCL).
Might as well throw OCaml in the mix too, since it has all of the above minus the formal spec.