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

371–380 of 504 posts

Re: Getting Past C

#371

Post by kbenson »

nurettin wrote: post #351
eridius wrote: post #341

Earlier quoted context omitted.

The huge discussion about Rust is because that's literally what this post is about. It's titled "Getting Past C" and most of the post is about considering Go or Rust as the future language for the project. And, not surprisingly, a lot of people think Rust is a great choice for this (and I agree).

The title is Rust-bait so let's all chant rust! Rust! RUST! Oh but there are only three tentative mentions of Rust in it and this entire comment section is corroded. Just compare the two pages in a browser with ctrl-f rust

I'm not sure where you're under the impression that the number of times something is explicitly mentioned corresponds directly to the number if times it's being discussed, which is what is implied by your suggestions to search for occurrences of the name. The whole article is about future plans for NTPsec, and the work going into making it so it can be converted to a new language later. The article is about the relative merits of different languages for this task, and Rust is one of the languages. Of course Rust is going to be talked about in the comments. The only odd thing here is that Go isn't talked about more in the comments, not that Rust is talked about a lot.

Re: Getting Past C

#372

Post by rtpg »

userbinator wrote: post #275
jdmichal wrote: post #66

Earlier quoted context omitted.

Obviously, one can program C to do anything, and write all the provably safe abstractions wished. But, that's not really the point. The point is that doing such is not the default. It requires engagement and knowledge of the programmer, especially on distributed projects with loose communication, such as many open source projects. And it only takes one programmer mistake to bring the whole house of cards down. Why al…

Why allow programmers to make mistakes? For a philosophical counterpoint: Why allow anyone to do anything that might possibly be incorrect, harmful, or otherwise perceived by some to be negative? I've looked at a lot of the talk surrounding "safe/secure languages", "safe/secure programming", etc., and yet every time I've heard people preach about the benefits, I feel like I just vehemently disagree. At a very deep an…

You can still be clever in Rust. You just have to try harder and explicitly say "I'm trying to be clever" here. You might make a mistake, of course. But if you need it, the option is there.

There is no philosophical beauty in typos or off by one errors. You are not being stifled when your compiler points out to you that, no, "coutn" is not a variable currently in scope. If we have a static proof that what you just did will never work, why would you still want to do it?

And if you had a reason, you still have a way to do it.

If you're trying to be clever, you need to prove that you know what you're doing.

Re: Getting Past C

#373

Post by kbenson »

lacampbell wrote: post #355
kbenson wrote: post #330

Earlier quoted context omitted.

We seem to be talking past each other. I created a bit of sample code ot show exactly what I'm talking about, it's at https://gist.github.com/kbenson/fbc585d6a6144a2a9f1ef340b913... . The basic idea is that sometimes you might want a pointer to an array item, if that item is complex, not just a copy of it, as there's no need to be wasteful if it's a fairly large struct. Any pointers to that array might be invalidated…

You're right, to an extent we are talking past each other. I totally understand how your code can cause a dangling pointer. But you are using a raw C array, which completely goes against what I've been poorly trying to explain in this thread. What I am advocating is something like this: https://gist.github.com/anonymous/32df4da4949a6c1067c2be8f20... so TL;DR, if you don't want to deal with copying structs, malloc the…

> if you don't want to deal with copying structs, malloc them then push them to the dynamic array

So, manually manage their memory allocation, but allow dynamic allocation of the array of pointers? Sure, there are some cases where that's useful, but if you're already managing memory for the structs themselves, you can probably just manage the memory for the array at the same time.

> Else if you push a struct value on the ray, return struct values.

So, like I said, "not allowing pointers to array items".

You can do this, but you aren't just making array access a little safer, you're also restricting quite a bit of what you can do for efficiency. If I'm going to throw away the ability to use pointers for efficiency, why am I even using C in the first place? I should just write it in some other language from the start. Presumably I used C because there was a need for that efficiency.

Re: Getting Past C

#374

Post by xorxornop »

e3b0c wrote: post #354

Rust has some very desirable properties to me. Writing Rust programs from scratch is not as scary as I've heard of from the internet either. The documentation is excellent, the compiler diagnostic messages are very helpful and the notorious borrow checker didn't stand in my way that much. And I love Cargo and Cargo.io. I have some projects where Rust is the saner choice than Go or other GC based languages. That said,…

Hmm, I've had a very nice experience using Rusty Code in VS Code. Some useful refactoring functionality is missing for sure, but a lot of that will become possible quite shortly from RLS (Rust Language Server, a la how TypeScript works in VSC), and if your preferred editor has support for the language server spec (it's a open source common spec, not specific to Rust), it will support it at parity, too.

Re: Getting Past C

#375

Post by Manishearth »

e3b0c wrote: post #354

Rust has some very desirable properties to me. Writing Rust programs from scratch is not as scary as I've heard of from the internet either. The documentation is excellent, the compiler diagnostic messages are very helpful and the notorious borrow checker didn't stand in my way that much. And I love Cargo and Cargo.io. I have some projects where Rust is the saner choice than Go or other GC based languages. That said,…

YouCompleteMe on Rust has pretty good JumpToDefinition support for Rust.

You can also use https://github.com/nrc/rust-dxr to index rust code via DXR.

IIRC ctags also works with Rust.

RLS should cover this pretty well too once it happens.

Re: Getting Past C

#376

Post by Manishearth »

arunmu wrote: post #367

I do not contest on the opinion that Rust is a good language, but it slightly hurts me when people club C and C++ together. One can easily write correct by construction code using modern C++. Use of meta-programs allows you to create typesafe constructs. It provides you with zero cost abstractions to specify ownership of resources and ..... One has to just strive to not use the C baggage that comes with it.

C++ is much better, but still not safe. Null still exists. Moves are runtime moves, so you can still attempt to access the value at compile time. Iterator invalidation is still an issue.

Of course, C++ might be "safe enough" for your use cases.

Re: Getting Past C

#377

Post by pjmlp »

arunmu wrote: post #367

I do not contest on the opinion that Rust is a good language, but it slightly hurts me when people club C and C++ together. One can easily write correct by construction code using modern C++. Use of meta-programs allows you to create typesafe constructs. It provides you with zero cost abstractions to specify ownership of resources and ..... One has to just strive to not use the C baggage that comes with it.

> 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 everyone on the team actually cared to write proper C++.

Re: Getting Past C

#378

Post by Manishearth »

steveklabnik wrote: post #349
awinter-py wrote: post #344

Earlier quoted context omitted.

C union declarations should correspond pretty closely to rust enum declarations. It's a surprisingly important feature. Every large codebase I've worked on has clunky workarounds for storing heterogeneous types in collections. Haven't seen a silver bullet; dynamic languages are great at this until you have to scale (either in lines of code, number of types or dataset size) and then they become unmanageable. Static la…

Close, but not quite: unless the type is NonZero, you need space for the tag. c-style unions are in nightly behind a flag; they're not stable yet.

I think they meant that the use case corresponds closely, not the representation. Generally C unions get used the same place Rust unions would in a rust program (not vice versa though), unless they're being used for type punning, which is pretty rare anyway.

Re: Getting Past C

#379

Post by pjmlp »

Manishearth wrote: post #232
Animats wrote: post #202

Earlier quoted context omitted.

There's a lot more unsafe code in Rust crates than there should be. That's a fixable problem. Some stuff from the early days predates the optimizer getting smart enough that unsafe code isn't needed. I wrote on this a few days ago in a Rust topic.

While I now mostly agree with you that there is more unsafe code than there should be, I still maintain that the frequency of unsafe in a deptree is usually still small enough to be practically auditable, ignoring FFI. It could/should be much less, but it's not too bad. I've done such audits a few times and it's not been too hard and taken very little time. Auditing FFI is a whole other challenge, however :(

> I still maintain that the frequency of unsafe in a deptree is usually still small enough to be practically auditable

Not in binary libraries, hence why it is important to have a culture to only use unsafe if it really must be used.

Re: Getting Past C

#380

Post by pjmlp »

kazinator wrote: post #305
zem wrote: post #280

Earlier quoted context omitted.

I think it's a massive programming ecosystem blind spot that "depending on c" is seen as less of a burden than depending on rust

How many chip and SoC vendors provide a Rust toolchain? In the case of C, the answer is basically "about as many as provide a toolchain".

In 2016, yes.

All the way through the 80's up to the early 90's, C toolchains only mattered to those that were working on UNIX workstations and servers. On home computers it was just, yet another language, with compilers generating slower code than junior Assembly programmers.

So of course Rust has to catch up a few decades of market use.

Post reply on HN