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

Rust is not a good C replacement

drewdevault.com

Post reply on HN
Print view View original

191–200 of 213 posts

Re: Rust is not a good C replacement

#191

Post by village-idiot »

detaro wrote: post #160
Sir_Cmpwn wrote: post #28

Earlier quoted context omitted.

I'm offering you an olive branch here. You can pile on the snark, or you can take my offer to issue a correction to my article. Edit: found the hostility. Fine, I won't issue a correction. I didn't find Steve's arguments entirely correct and I was willing to add a note to the page letting him share his perspective so the reader could make up their mind. Now I'm less open to that.

> Edit: found the hostility Share for those following along at home?

Someone disagreed with him, apparently.

Re: Rust is not a good C replacement

#192

Post by village-idiot »

Manishearth wrote: post #88
ddevault wrote: post #4

Earlier quoted context omitted.

Thanks for sharing your perspective. My comment was largely based on this discussion: https://github.com/mesonbuild/meson/issues/2173 If you'd like to share a short summary of your thoughts, I'll update the article with your commentary.

I don't see anyone in that discussion who is on the Rust/Cargo teams. I see a bunch of disagreement from people involved in gstreamer/meson (and some other non-team folks), which makes sense, disagreeing with something on your own project isn't external hostility, it's how decisionmaking works.

Also, disagreement != hostility.

Re: Rust is not a good C replacement

#193

Post by Thaxll »

mmstick wrote: post #179
Thaxll wrote: post #154

Earlier quoted context omitted.

My point: - Redox is built in Rust and had serious memory bugs triggered by userspace applications, people claim that we should build OS in Rust because it's "memory" safe, in reality it's much more complex than that

It did not have serious memory bugs. All of the unsafe code in Redox, of which only a small fraction is unsafe, is neatly compartmentalized so that it's easy to audit.

It was a year ago: https://gitlab.redox-os.org/redox-os/redox/issues/1136 https://gitlab.redox-os.org/redox-os/redox/issues/681

And we're talking about a bunch of people randomly clicking / trying things, so imagine what's really inside Redox.

Re: Rust is not a good C replacement

#194

Post by steveklabnik »

jolhoeft wrote: post #176
steveklabnik wrote: post #63

Earlier quoted context omitted.

Part of the issue here is that rustup has not had a dedicated maintainer in a while; we’re working on it.

Is there a link to the maintainer discussion?

I am not 100% sure; I’m not on the tools team, but it’s undergoing a big re-org at the moment. I’d get in touch with them: https://www.rust-lang.org/governance/teams/dev-tools

Re: Rust is not a good C replacement

#195

Post by MuffinFlavored »

steveklabnik wrote: post #135
MuffinFlavored wrote: post #133

Earlier quoted context omitted.

Rust has no particular built-in model for concurrency, but as soon as you want to do anything important with Rust (given the current ecosystem) you're going to run into Tokio, no? It seems to be the community-agreed-upon way to handle concurrency. Does Tokio use polling under the hood?

There are a number of different options. And today, yes, code is tied to one of them. But, and it’s not stable yet, futures and executors, the two traits, are being added to the standard library. This lets your code be generic over executors, and there are already more than just tokio. Including an embedded one, for example. Tokio wraps epoll/kqueue/iocp.

> But, and it’s not stable yet, futures and executors, the two traits, are being added to the standard library.

Is this implementation going to wrap epoll/kqueue/iocp?

Would you say Tokio has any drawbacks/flaws/design choices yo aren't a fan of?

What are the popular choices other than Tokio?

Re: Rust is not a good C replacement

#196

Post by jefftime »

nimmer wrote: post #165
mjw1007 wrote: post #151

Earlier quoted context omitted.

I don't think they count as a "better C" for this purpose. I'm thinking of something aiming at the niche that C currently fills. Having a garbage collector doesn't fit that, and Nim doesn't look small (anything with both destructors and exceptions is getting into complications rather beyond C).

Regardless, I use Nim when I need the performance and memory footprint of C. GC is optional.

Can you use the standard library without GC?

Re: Rust is not a good C replacement

#197

Post by adamnemecek »

glangdale wrote: post #189
adamnemecek wrote: post #35

Earlier quoted context omitted.

Also their development process is too slow. Like it would be impossible for me to pitch a new feature to cpp. I can imagine adding a new feature to rust (not that I would but I like that there’s the option).

I'm appreciating the irony of you complaining that "C++ features don't work together" but also saying that the process of putting new features into C++ should be faster . :-)

There's nothing ironic about that. If they had a shorter feedback loop, things could be getting fixed faster.

Re: Rust is not a good C replacement

#198

Post by Rusky »

jhasse wrote: post #182
Rusky wrote: post #161

Earlier quoted context omitted.

Yes, as cquery's README states it has a huge memory overhead because it basically just builds the project and keeps the info around. This is rather like how Visual Studio's C++ IDE support used to work, and it was not fun to wait for re-indexing after making edits. Alternative Clang-based solutions reduce the memory overhead by doing more on-demand computation, more in line with how C# or Java IDEs work, at the cost…

My guess would be that in C# and Java, re-indexing is faster, because those languages have faster compile times in general. Therefore I would put this as a compile time problem. > This also isn't a complete solution for accuracy, as it only really works if you're also building with Clang (or something close enough that Clang can emulate it). Well that's a bit unfair, because we're talking about C++, not a GCC or MSVC…

Yes- but not only are C# and Java faster to compile in general, they're easier to process small pieces of in isolation. C++ requires everything referenced to be declared previously even just to parse. (Modules should help here, at least, eventually.)

But even then, parsing is often required to do complex Turing-complete processing of templates and constexpr, since that determines something's role in the grammar. This forces an accuracy vs performance tradeoff that modules don't help with at all.

So it's not just a compile time problem that happens to affect IDEs, but also an IDE problem, because they can't take nearly as much advantage of the fact that they're only trying to analyze the code, not build it.

And language extensions are hardly unfair. In practice they're used all over the place, and people expect them to work in their IDEs, especially when they're off in some header they didn't write. (Attributes help here, somewhat, when compiler vendors can move extensions into them.)

Re: Rust is not a good C replacement

#199

Post by jhasse »

Rusky wrote: post #198
jhasse wrote: post #182

Earlier quoted context omitted.

My guess would be that in C# and Java, re-indexing is faster, because those languages have faster compile times in general. Therefore I would put this as a compile time problem. > This also isn't a complete solution for accuracy, as it only really works if you're also building with Clang (or something close enough that Clang can emulate it). Well that's a bit unfair, because we're talking about C++, not a GCC or MSVC…

Yes- but not only are C# and Java faster to compile in general, they're easier to process small pieces of in isolation. C++ requires everything referenced to be declared previously even just to parse . (Modules should help here, at least, eventually.) But even then, parsing is often required to do complex Turing-complete processing of templates and constexpr, since that determines something's role in the grammar. Thi…

Makes sense, thanks for the explanation.

> And language extensions are hardly unfair. In practice they're used all over the place, and people expect them to work in their IDEs, especially when they're off in some header they didn't write. (Attributes help here, somewhat, when compiler vendors can move extensions into them.)

It's a C++-as-it-is-used-in-the-wild problem then, not a (ISO) C++ one ;)

Anyway: I myself never had any problems, but all my programs build fine with Clang (as all C++ programs should IMHO).

Post reply on HN