421–430 of 504 posts
Earlier quoted context omitted.
No, Rust arrays are not safe by default: https://is.gd/iY5lPQ
I get: thread 'main' panicked at 'index out of bounds: the len is 3 but the index is 4' Looks pretty safe to me.
A panic isn't safe, and if you are going to claim that it is, you can get the same safety in C using gcc and clang features.
Earlier quoted context omitted.
No, Rust arrays are not safe by default: https://is.gd/iY5lPQ
I get: thread 'main' panicked at 'index out of bounds: the len is 3 but the index is 4' Looks pretty safe to me.
A panic isn't safe, and if you are going to claim that itcis, you can get the same safety in C using gcc and clang features.
After reading this post the idea of a C-to-C translator that injects bound checking, etc. comes to mind. Such translator could be used by OS distributions to provide safety in the least intrusive way and possibly completely automatically for many C codebases they have in their repositories. Translating into Go or Rust, on the other hand, cannot scale beyond some individual projects, that decide to undertake such effo…
They are usually used in debug builds though, since they have a 2-3x runtime penalty.
[1] http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
Earlier quoted context omitted.
Or perhaps just some helper functions in C that wrap array and pointer allocation/access to provide sanity checks. Seems like moving to a new language is rather extreme....
Why? Rust includes index checks by default, so you have zero chance of programmer error. And, to boot, it removes the checks when the compiler decides that the code is provably safe.
Earlier quoted context omitted.
Like in C, you are not supposed to pass out-of-bounds indexes to the [] operator. If anyone does so, it's a bug. Rust converts it to a panic, which safely terminates the thread/program, instead of C's undefined behavior. You can also catch this panic at the thread boundary, so other threads in your program can keep running, unless the program was compiled to call abort() on panic.
You still think in C limits of possibilities. Rust could just return Option as a result for [x] syntax.
(The alternative instead of .unwrap() would be to propagate the error, polluting the whole program with code to handle errors which never will happen. And since they will never happen, many programmers would simply start ignoring them - and in the process, they would by accident end up ignoring errors that can happen. Not a good situation.)
Rust is surely fine, and an improvement over C, but its main advantage is that all the rust code is written now, when everyone takes more care about security. It doesn't have to deal with 40 years of bad legacy code written by sloppy developers. You can obtain similar quality in a C modern code-base, using tools like static and dynamic analyzers. In fact, today the hardest issues came from multi-threading. I won't ev…
Which higher-level abstraction to use is a question and depends on the problem at hand; for throughput computing in C, Cilk is perhaps the best today (I guess you could call my own project checkedthreads a bit of a Cilk knock-off.) AFAIK, Rust developers are more interested in higher-level abstractions than Go developers (Go's built-in goroutines being on par with threads in terms of ability of automated debugging tools to flag bugs; perhaps there's work in Go on higher-level abstractions but the vibe I felt, perhaps mistakenly, is that these are non-problems, which I disagree with: http://yosefk.com/blog/parallelism-and-concurrency-need-diff...)
Rust is surely fine, and an improvement over C, but its main advantage is that all the rust code is written now, when everyone takes more care about security. It doesn't have to deal with 40 years of bad legacy code written by sloppy developers. You can obtain similar quality in a C modern code-base, using tools like static and dynamic analyzers. In fact, today the hardest issues came from multi-threading. I won't ev…
I just left a job in which C code was being written from scratch, in 2016. The code was awful. Coverity didn't prevent it from being awful.
Earlier quoted context omitted.
> Moves are runtime moves, so you can still attempt to access the value at compile time. What do you mean by that ? Are you saying the standard decided to make it non-destructive moves ? Then yes, it is a possible scenario for error but also a performance advantage in some cases.
> What do you mean by that ? Are you saying the standard decided to make it non-destructive moves ? You can still access a value after it has been moved out. use-after-move is allowed by the compiler. It places (stdlib) types in an unspecified but valid state (I've seen C++ code reusing these types and assuming that the state after move is something in particular -- it's not). Most optimizations you can do by reusing…
Earlier quoted context omitted.
Same thing with Ada. If you're looking for a safer low-level language with a long track record of successful use by some major players, Ada is the natural first candidate. But as someone else said, Rust has had way better marketing (and is newer, which probably catches some people as well.)
Are there any large non-DoD projects written in Ada that are still used?
Automotive has unfortunately settled mostly on C and build a whole ecosystem around it (Autosar). With all that talk around self driving cars safer programming languages and tools would make a lot of sense.
Earlier quoted context omitted.
This is how I feel. You cut the code to 27%. Great. You C99'd the code. Grand. Now you're going to rewrite the whole danged thing in a new language. Wonderful. This is the sort of stuff I cared about so much as a junior dev. But a user asks, are we there yet?
But adding functionality grows in effort as more code is added. At some point it makes sense to improve a code base so you improve the rate at which you are getting "there". In fact there are a lot of code bases, perhaps most, which simply cannot get there in any sane way and fall short of achieving their goal. You might not care how goals are achieved as a user but as an engineer it's worth exploring and discussing…
Just to be clear - I don't suspect that the things that pretend to replace C are bad, or no good. I've just seen multiple "pretenders to the throne"[1] and what would appear to have happened is that we just moved the pathology around.
[1] please excuse the horrible metaphor.
After a few iterations of that, one begins to think that perhaps this is a distinctly human problem that is not necessarily addressable by improved language systems.
My greatest concern is that I keep seeing people learn the same things, over and over, on the job. There's no real repository of literature to actually address any of this - each engineer appears to have to learn it mostly from scratch.
There's a famous bon mot from pubic choice economics - "something must be done; this is something; this must be done." I just hope all the new crop of languages are not that.
Finally: If you can, and if you can learn the right patterns ( isn't that true of all languages, though?), the thing I have gone to, again and again that is better than test equipment in terms of reliability continues to be Tcl.