Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Getting Past C

blog.ntpsec.org

Post reply on HN
Print view View original

411–420 of 504 posts

Re: Getting Past C

#411

Post by anarazel »

rtpg wrote: post #244
sidlls wrote: post #76

Earlier quoted context omitted.

How do you suppose runtime bounds checks are done in Rust? They certainly also incur a performance penalty in not-trivial cases. Also, "safe by grep audit" means "safe according to a human." The argument of course is that it lowers the surface area of what a human must be trusted to verify. I'm still not convinced by that argument, because human error is a thing. And for actual systems programming, "very rare" may no…

"Actual systems programming" mostly does not involve unsafe code. For example, most OS code is _not_ interrupt hooks or malloc but the rest of the OS. Most of Postgres is not reading data quickly, but higher-level abstractions. Large-scale systems programming will always be mostly higher-level abstractions, because that's the only way to write large programs. Name any "systems programming" OSS project, choose a rando…

> "Actual systems programming" mostly does not involve unsafe code.

True. Or slightly rephrased: Most of the unsafe code is centralized to some core pieces.

From the POV of a PG dev: The big problem using something like rust for something like PostgreSQL is its it's portability, stability and uncertainty about where things are going. We do five years of back-branch releases (and for many that's not even enough!). Language and tooling around the new crop of languages simply aren't mature enough for that yet.

Re: Getting Past C

#412

Post by cesarb »

EugeneOZ wrote: post #203
moosingin3space wrote: post #198

Earlier quoted context omitted.

Then use the get() function on an array/slice. It returns an Option so it won't perform an access off the end of the array, and you can catch it.

thanks, I do. Only thing left is explain it to everybody else to avoid panicking in 3-party crates. I really hate when people use panicking just because it's easier than error handling. So it was "surprise" to see such behavior from "[x]" construction.

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.

Re: Getting Past C

#413

Post by lomnakkus »

lacampbell wrote: post #288
dbaupp wrote: post #128

Earlier quoted context omitted.

The lack of generics means your array implementation is either going to either: - be implemented with macros and token pasting, and result in a ton of mental overhead because you'll have a pile of types like array_foo for an array of `foo`s, and array_bar for an array of `bar`s, along with a pile of corresponding `foo * array_foo_get(array_foo, size_t)` and `bar * array_bar_get(array_bar, size_t)` functions. - or, ha…

C macros-faking-generics really aren't that bad (your "unsigned char" case is really easy to solve - use another macro). It's a bit goofy having different types floating around like "array_of_int", "array_of_float", but you can create them in a single line when needed, and once you create them, they work, and efficiently. They're not an ideal solution by any stretch, but it's not the nightmare scenario you envision w…

Having worked in a code base like this (prior to migration to C++11), I'd agree that they're not necessarily a "nightmare", but they lead to code that's so verbose that it tends to really obscure the actual logic of a piece of code. (Especially anything more complicated than a simple array, e.g. associative maps or multi-dimensional arrays, and iteration constructs can be hellish.)

Re: Getting Past C

#414

Post by qz_ »

kqr wrote: post #395
giancarlostoro wrote: post #183

I wish more mention of D would happen. It is compatible with C and C++ libraries and features GC without sacrificing the good things of C and C++. I always loved the idea of Rust and Go but they are nowhere near C or C++ where it matters to me. D fits the bill, otherwise I just use Python. I like being able to design software in my own way as opposed to being told how to do it.

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?

Re: Getting Past C

#415

Post by EugeneOZ »

cesarb wrote: post #412
EugeneOZ wrote: post #203

Earlier quoted context omitted.

thanks, I do. Only thing left is explain it to everybody else to avoid panicking in 3-party crates. I really hate when people use panicking just because it's easier than error handling. So it was "surprise" to see such behavior from "[x]" construction.

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.

Re: Getting Past C

#416

Post by pjmlp »

blub wrote: post #407
pjmlp wrote: post #388

Earlier quoted context omitted.

How would you prevent other developers to write C style code?

Project leadership, coding standards, automated analysis and code reviews . But realistically speaking it might be easier to change tools for a significant number of teams, because the software development community is in general poor at leadership and process. A rewrite seems more approachable for the average (not necessarily average skills-wise) dev compared to a change in attitude, self-reflection and incremental…

Which I seldom see in enterprise projects, specially in companies whose business is unrelated to software development and IT is nothing else than a cost center.

Anything that is optional gets pushed aside.

Re: Getting Past C

#417

Post by silent_hunter »

AgentME wrote: post #319
rafinha wrote: post #251

I didn't understand why rust and go are natural alternatives to C. Wouldn't C++ be a more natural option? (Despite the fact that both go and rust are developed by third party companies)

None of the safety issues brought up about C there are solved by C++. C++ is (nearly) a superset of C, so it inherits all of those issues.

If C++ is "(nearly) a superset of C" why is the C++ standard twice the size of C standard? Of course if we take that 0.505.. ≈ 1, then it is indeed a (nearly) superset.

Re: Getting Past C

#418

Post by pjmlp »

blub wrote: post #403
pjmlp wrote: post #377

Earlier quoted context omitted.

> One has to just strive to not use the C baggage that comes with it. This is why they get clubed together, regardless how much I like C++, I am yet to see the use of C baggage being successfully forbidden in enterprise teams, let alone if there are third party dependencies (which is always the case). So far I have only seen modern, safe C++ being used successfully on a big project I was part of at CERN, where everyo…

Do those enterprise teams use rust / go or have they already moved on to Java and .NET many years ago? :) The enterprise is not the target here.

They have moved to Java/.NET with C++ on "as needed" basis.

Rust and Go also need to match the Java/.NET ecosystems if adoption at enterprise level is a target.

And yes, there are AOT compilation toolchains to native code in Java/.NET available.

Re: Getting Past C

#419

Post by ue_ »

kqr wrote: post #392
Nacraile wrote: post #278

Earlier quoted context omitted.

> I ask this in bad faith: I encourage you to share a single nontrivial codebase which actually creates the abstraction you've described and religiously adheres to using it throughout. As to why this is in bad faith: I'm definining "nontrivial" here to mean using 3rd party APIs - which will operate on C style arrays, not your project specific safe wrappers - and thus by definition won't be "religiously" sticking to s…

> I work on a C codebase that does this […]. Yes, there is quite a lot of NIH. With essentially-uniform use of checked data structures, and an extremely comprehensive suite of automated tests getting run under ASAN (originally Valgrind) […]. This is a complex, >1M SLOC distributed system that has seen several years of production use at this point […]. > > […] it just needs to be done from the start, and then you just…

But Rust still won't warn about an out of bounds access (when accessing using a variable) at compile time, and your code will panic at runtime. This isn't the "safety" anyone ought to be expecting from a language billed incessantly as safe.

Rust, at least in this regard and probably others too, is no better than C, and for me it isn't enough to justify the horrible and complex syntax.

Re: Getting Past C

#420

Post by ue_ »

steveklabnik wrote: post #136
EugeneOZ wrote: post #131

Earlier quoted context omitted.

No, Rust arrays are not safe by default: https://is.gd/iY5lPQ

Panics are definitely safe. They are significantly different than the segfault you'd get out of the C code.

There are tools you can use with C compilers that don't access OOB memory on OOB access. What's your point?

I think I'd rather not have it panic at all. They were making a language from scratch and still didn't solve the crash-at-runtime problem that C has. Instead they just made a common C compiler option default and called it 'safe'.

It's worse than the fact that the Go creators ignored years of research after the year 1970 and didn't implement generics, for no good reason.

Rust's safety is a joke, and so is the idea that a lot of it is anything 'new'. They had the chance to fix it and they didn't. Boo.

Post reply on HN