271–280 of 300 posts
Well Rust seems like a nice enough language if blog posts are anything to go by. But I really cannot unless we something like RustPython and Rython to replace CPython and Cython. (If anybody does write a new Python distribution on rust I named if first)
Someone has already done the honors: https://github.com/shinglyu/RustPython
Earlier quoted context omitted.
Can you be specific about which languages you include in the category of "fast and SAFE"?
There are so many: Pony, ATS, Sing#, Spec#, Felix, Gordon, Æminium, DPJ (Deterministic Parallel Java), Kilim, Haller and Odersky. A lot of more linear type languages, like PRFJ or OIGJ. See e.g. http://www.doc.ic.ac.uk/~scd/fast-cheap.pdf I'm not sure about Factor yet, but it looks good and beats Rust in performance and features also.
Earlier quoted context omitted.
the cool thing about rust is that you can use it for real-time programming, one example being DSP/audio. it often means no locks, nothing blocking, no dynamic allocation (malloc and most other allocators do not provide upper bounds of execution time), no recursion, and others. haskell is not tailored for that. of course there are other domains for which haskell is top-nocth and rust falls flat.
Minor nit: I believe that you can get memory allocators that provide upper bounds of execution time. But it won't be the default allocator in most languages. Also, you need an allocator that cannot ever fail to return a valid block. Even if you have all that, it still makes it much harder to prove that your worst-case timing is fast enough. So, yeah, no allocations in situations like that. Allocate at start-up, and r…
Earlier quoted context omitted.
I made a claim of zero runtime overhead after directly quoting the context of automatic memory management. So are you suggesting that claim in such a context is false, citing BDDs as some example, or are you taking my claim to be more broad than the context warrants, and so are arguing a strawman?
> I made a claim of zero runtime overhead after directly quoting the context of automatic memory management. And that's what I was referring to. BDDs inherently require Rc /Arc (as long as you want to be memory-safe, at least) and therefore incur significant overhead (reference counting is one of the most expensive forms of automatic memory management). I use BDDs as an example, because there's no way to work around…
"Zero-cost abstraction" means "You couldn't have coded it any better yourself." If the problem requires a certain amount of overhead, than an implementation of that solution is considered zero-cost. Rust can't change the laws of math.
Maybe Bjarne should have called it the "Zero additional-cost abstraction" instead; I think it'd clear the principle up a lot.
Earlier quoted context omitted.
You can write large C++ programs that are quite safe, using only higher level abstractions (no pointers or explicit memory management). This doesn't require any fancy new C++; code written to C++98 (first ISO C++ standard) will do it just fine. For exmaple, in C++, we can put two strings together to make a new string without worrying about whether we have a buffer large enough to hold the result, and whether null ter…
I fully agree, but you cannot oblige everyone that touches the code to have the same care, and so the typical "C with C++ compiler" idioms sneak in, thus decreasing overall safety. This is specially the case in the majority of enterprise software that doesn't use any kind of static validation tooling, or CI builds.
If you can't enforce that certain rules be enforced in a C++ program, you also can't enforce that someone won't sneak C++ modules into a code base written in another, safer language.
> doesn't use any kind of static validation tooling, or CI build
Or, also: a review tool for rejecting stuff that is against the project's explicit coding guidelines.
Earlier quoted context omitted.
I fully agree, but you cannot oblige everyone that touches the code to have the same care, and so the typical "C with C++ compiler" idioms sneak in, thus decreasing overall safety. This is specially the case in the majority of enterprise software that doesn't use any kind of static validation tooling, or CI builds.
> you cannot oblige everyone that touches the code to have the same care If you can't enforce that certain rules be enforced in a C++ program, you also can't enforce that someone won't sneak C++ modules into a code base written in another, safer language. > doesn't use any kind of static validation tooling, or CI build Or, also: a review tool for rejecting stuff that is against the project's explicit coding guideline…
In Java and .NET projects you can easily ensure that, and that is a common scenario in some of our customers.
The machines are provided locked down by IT with the project sanctioned tools, including the configuration for in-house Maven and NuGET repositories.
No native code compiler gets installed, servers are configured to disallow unsafe code.
Any library not available requires a change request to the IT team.
Earlier quoted context omitted.
> you cannot oblige everyone that touches the code to have the same care If you can't enforce that certain rules be enforced in a C++ program, you also can't enforce that someone won't sneak C++ modules into a code base written in another, safer language. > doesn't use any kind of static validation tooling, or CI build Or, also: a review tool for rejecting stuff that is against the project's explicit coding guideline…
> you also can't enforce that someone won't sneak C++ modules into a code base written in another, safer language. In Java and .NET projects you can easily ensure that, and that is a common scenario in some of our customers. The machines are provided locked down by IT with the project sanctioned tools, including the configuration for in-house Maven and NuGET repositories. No native code compiler gets installed, serve…
Stuff you don't want in C++ code can be rejected by a pre-commit hook which scans code. That header can't be #include-ed, that crazy operator can't be used, etc.
Also, with open source compilers, you can implement your own warnings. (Been there, done that; in the role of an embedded distro/kernel/toolchain person some years ago, I hacked g++ with custom warnings).
If there is something we don't want in C++, and it doesn't "grep" well, we may be able to diagnose its presence in the compiler and treat that as an error.
Earlier quoted context omitted.
> you also can't enforce that someone won't sneak C++ modules into a code base written in another, safer language. In Java and .NET projects you can easily ensure that, and that is a common scenario in some of our customers. The machines are provided locked down by IT with the project sanctioned tools, including the configuration for in-house Maven and NuGET repositories. No native code compiler gets installed, serve…
With that environment and people, we could easily enforce C++ rules in the same way. Stuff you don't want in C++ code can be rejected by a pre-commit hook which scans code. That header can't be #include-ed, that crazy operator can't be used, etc. Also, with open source compilers, you can implement your own warnings. (Been there, done that; in the role of an embedded distro/kernel/toolchain person some years ago, I ha…
Earlier quoted context omitted.
With that environment and people, we could easily enforce C++ rules in the same way. Stuff you don't want in C++ code can be rejected by a pre-commit hook which scans code. That header can't be #include-ed, that crazy operator can't be used, etc. Also, with open source compilers, you can implement your own warnings. (Been there, done that; in the role of an embedded distro/kernel/toolchain person some years ago, I ha…
Not really, the part you are missing is that it is easier and cheaper not to have C or C++ compilers available at all.
Earlier quoted context omitted.
Even if your claim is correct, the existence of some programs that cannot be expressed with memory-safe zero overhead abstractions still doesn't entail your original claim. As you just said, you can use Rust's unsafe escape hatch to preserve your desired performance where it's critical and you haven't lost anything from C/C++, but you can still enjoy the safety benefits where unsafety is not needed. And BDDs expose a…
> Even if your claim is correct, the existence of some programs that cannot be expressed with memory-safe zero overhead abstractions still doesn't entail your original claim. As you just said, you can use Rust's unsafe escape hatch to preserve your desired performance where it's critical and you haven't lost anything from C/C++, but you can still enjoy the safety benefits where unsafety is not needed. I'm not compari…
There are potentially many unsafe approaches, and possibly even some safe ones.
> The entire Wirth family of languages qualifies, too. Or Eiffel [1]. Or Fortran [2]. Or Modula-3 [3]. As do more recent languages such as Nim [4] and D [5].
[1] Doesn't support expressing stack allocation patterns, which are essentially to achieving true zero-cost abstractions.
[2] Oh yeah, that'll be easy and maintainable to program.
[3] Doesn't support 64-bit Windows. Verbose like Ada. Abstraction is weak compared to Rust. Also doesn't support expressing stack allocation.
[4] Nim requires a GC, so not zero cost. It also has surprising runtime semantics. For instance, fields that are are guarded by a clause raise runtime exceptions. These would require different cases which are checked for exhaustiveness statically in Rust.
[5] D is not memory safe for non-trivial programs if you're not using the GC.
Clearly you and I have a different understanding of zero-cost abstraction.
> In addition, parametric polymorphism cannot ever have a zero-cost abstraction (or rather, the term has no meaningful definition in this context), because you pay for it either in runtime overhead (shared generics) or code size (specialization).
Code size is not a problem when discussing zero-cost abstractions. Honestly, it just seems like you're grasping for something to nitpick on.
> I also wouldn't bring up syntactic and semantic costs; that's throwing stones while sitting inside a glass house. Rust is probably one of the worst offenders in this regard.
I have no idea what you're talking about. Once they removed all the special syntax for pointer types years back, Rust is very readable to anyone from a brace-based language tradition.