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

Rust vs C Pitfalls

garin.io

Post reply on HN
Print view View original

111–120 of 379 posts

Re: Rust vs C Pitfalls

#111

Post by caconym_ »

lossolo wrote: post #85
burntsushi wrote: post #80

Earlier quoted context omitted.

None of the unsafe code that Steve linked to had anything to do with searching a file line by line. It has to do with other parts of ripgrep, like determining whether a tty is available or communicating with a Windows console to do coloring. (Hell, ripgrep doesn't even require memory maps, but they are faster in some cases.) Your benchmark proposal is interesting on the surface, but if done correctly, its speed will…

The thing is I don't really care if Go implementation is highly optimized for amd64 like memchr is in C which is also written in assembler and optimized for different platforms. What I care is that simple code written by me is faster without going into C/unsafe code myself. So it's correct, fast, simple and I do not pay with my time to figure out how to make it as fast in Rust. This is the point I am making. Of cours…

> but still a proof that what OP wrote is not valid in all cases.

You are not proving anything until you post your Go code, which you don't seem to have done (please correct me if I'm wrong, I am legitimately curious to see for myself how Go and Rust stack up against each other for this problem). Until then, all you're doing is making vague claims backed up by precisely zero evidence. Why should anyone take you seriously?

Re: Rust vs C Pitfalls

#112

Post by gmjosack »

NoahTheDuke wrote: post #110
plandis wrote: post #43

Earlier quoted context omitted.

For me this is pretty easy. It's about leadership. The leaders of Go foster an attitude of exclusiveness (just like a month ago they wanted to get rid of the Go subreddit in favor of a solely Google owned option of Google groups). The leaders of Rust are very receptive and helpful to new people. They are on IRC / Reddit and many other channels. I'd much rather invest my time into a truly open language and to me, that…

> (just like a month ago they wanted to get rid of the Go subreddit in favor of a solely Google owned option of Google groups) Wow, really? Do you have a link to that discussion? That's wild.

I believe this post was stickied at the top of the golang subreddit for a bit: https://www.reddit.com/r/golang/comments/5eubdp/the_future_o...

It should be a good summary of the event.

Re: Rust vs C Pitfalls

#113

Post by all2well »

gravypod wrote: post #2

If you're fighting, you've lost. The way to convert everyone to Rust you need to be better the the competition. Not just better as in "look at my features that will make your code safer". People may see the value but think "I get on just fine without the borrow checker so it isn't too important". You need to be far better then the replacement by providing the following: * Great Tooling ( IDEs ) * Great Libraries ( Ev…

I mean by that logic, no progress is possible at all in programming languages, because at some point every language had worse tooling than the competition.

I'd say the greatest part about Rust is the community, which realizes all of the issues you've listed, and especially the really tough learning curve for beginners.

Generally, use the right tool for the job. I don't think I'd really want to use Rust in production yet, but it's really great for side-projects and other more experimental things.

Re: Rust vs C Pitfalls

#114

Post by chj »

We are having new languages every year. Instead of debating which language is the best, why can't we invent a way to let components implemented in different languages talk with each other easily? We have pipes, sockets and message queues, but it's never simple enough to glue everything together.

Re: Rust vs C Pitfalls

#115

Post by zerofan »

steveklabnik wrote: post #91
zerofan wrote: post #89

Earlier quoted context omitted.

> How would you have gone about making Strings be "as comfortable as integers"? I would prefer a str be a str be a str, regardless of how you got it. Lowercase type-name and fundamental like an integer. I'm fairly certain I understand why Rust made the choice they did. I've read the forum threads at HN, Reddit, and users.rust-lang, and I've seen previous replies by you and other Rusties, so I hope you won't try to ed…

> so I hope you won't try to educate me No, I'm interested in what tradeoffs you would have made differently. I now understand. Thanks! (I disagree, but at least I understand.) > why this line hangs: It compiles and runs effectively instantaneously for me on Ubuntu under Windows as well, so that's very strange. Maybe file a bug? > I think the uncommented line shows a similar complaint. Yes, there's no constraint on t…

> It compiles and runs effectively instantaneously for me on Ubuntu under Windows as well, so that's very strange. Maybe file a bug?

Follow-up: I tried it with -O (don't know why I didn't think of that earlier), and it runs fine. So maybe the debug version is just generating terrible code, initializing by iterating through 10 billion bounds checks or something?

Anyways, more importantly, it works as I would like and does not behave as a 32 bit integer. I think I understand what you mean by "constrained" now. And clearly, I was wrong.

However, if most un-suffixed integers in real-world programs will become constrained (as you claimed), this further confuses me why i32 is the unconstrained choice. It doesn't seem like something so rare could be enough of a performance problem to justify being anything but the largest supported size.

Re: Rust vs C Pitfalls

#116

Post by atombender »

plandis wrote: post #43
voidlogic wrote: post #3

Earlier quoted context omitted.

On similar note, why Rust over Go? If I look at everything I used to write in C, I'd say 80% is well suited for Go and the rest I would fallthrough to Rust for. For the stuff where having a GC and slightly less control is OK, I don't see why I would want to use Rust. Rust is just much more complex and I prefer to keep it simple stupid (KISS). Basically, Go is good for 90% of what I used to use Java for and 80% of wha…

For me this is pretty easy. It's about leadership. The leaders of Go foster an attitude of exclusiveness (just like a month ago they wanted to get rid of the Go subreddit in favor of a solely Google owned option of Google groups). The leaders of Rust are very receptive and helpful to new people. They are on IRC / Reddit and many other channels. I'd much rather invest my time into a truly open language and to me, that…

> just like a month ago they wanted to get rid of the Go subreddit

To be fair, this was a proposal by a single person on the Go mailing list, and it was in reaction to Reddit's CEO publicly admitting to editing other users' comments. The person who proposed closing the Go subreddit was also under the mistaken impression that the subreddit was hosted by the Go team, which wasn't the case. In the end, there was a lot of discussion, and nothing was deleted. Tempest in a teapot, as usual.

Go has a serious culture problem, but that's not a good example of it.

Re: Rust vs C Pitfalls

#117

Post by nickpsecurity »

burntsushi wrote: post #109
lossolo wrote: post #87

Earlier quoted context omitted.

> If you show me a naive line by line approah, I'll show you an approach that is much faster but more complex. Of course, I did it myself many times. But this is NOT the point, I've already wrote it. The point is that I wrote naive approach in both languages and it's a lot faster in Go. Which is a reply to what OP wrote (don't forget where this discussion started). In this case this is the fact and I don't see any re…

> The point is that I wrote naive approach in both languages and it's a lot faster in Go. I tried your challenge, and the first data point I uncovered contradicts this. Here is the source code of both programs: https://gist.github.com/anonymous/f01fc324ba8cccd690551caa43... --- The Rust program doesn't use unsafe, doesn't explicitly use C code, is shorter than the Go program, faster in terms of CPU time and uses less…

Best example of evidence-based rebuttal I've seen in a language argument on here in a long time. Great write-up!

Re: Rust vs C Pitfalls

#118

Post by choudanu4 »

chj wrote: post #114

We are having new languages every year. Instead of debating which language is the best, why can't we invent a way to let components implemented in different languages talk with each other easily? We have pipes, sockets and message queues, but it's never simple enough to glue everything together.

This is an interesting idea that has been explored before in VMS, an old operating system I believe competed with UNIX.

VMS had a feature called CLE (Common Language Enviornment) [1] which defined calling conventions for computing primitives (functions, registers, stacks...you get it) independent of any language. You could call bits of code from all sorts of languages like COBAL, FORTRAN, C, and some others I'm not really familiar with. Because the calling conventions were specifically designed for language interopperability in mind, VMS was implemented in several different languages. Different components were coded in whatever language best expressed them. This directly contrasts with Unix, which we all know champions C.

I'm not too familiar with Unix calling convention specifics, but as I understand, it revolves around C and its memory model. I believe this is what gives some languages difficulty "talking" with each other; if a language doesn't have a memory or execution model close to C's, it needs to translate through a FFI (Foreign Function Interface) [2] before exchanging execution routines efficiently.

[1](https://en.wikipedia.org/wiki/OpenVMS#Common_Language_Enviro...)

[2] (https://en.wikipedia.org/wiki/Foreign_function_interface)

Re: Rust vs C Pitfalls

#119

Post by 0xcde4c3db »

chj wrote: post #114

We are having new languages every year. Instead of debating which language is the best, why can't we invent a way to let components implemented in different languages talk with each other easily? We have pipes, sockets and message queues, but it's never simple enough to glue everything together.

Microsoft has sort of been working on this for decades. It started as Dynamic Data Exchange in Windows 3.x, then evolved into Object Linking and Embedding and Component Object Model, which in turn became the basis for ActiveX, Distributed COM, and COM+.

Reactions vary.

I believe GNOME was originally envisioned as providing a GNU framework for this kind of functionality (whence the "Object Model Environment" in the original acronym expansion), but I think those particular ambitions have mostly been abandoned.

Re: Rust vs C Pitfalls

#120

Post by shmerl »

sidlls wrote: post #13

The kind of safety guarantees Rust provides are, in my opinion, insufficient justification for experienced developers to move from C or C++. Rust has other features that make it generally superior in certain (many) contexts. The safety is a nice "add-on" effect, I suppose, but my view is that constantly hyping safety as the biggest selling point is missing a mark.

> The kind of safety guarantees Rust provides are, in my opinion, insufficient justification for experienced developers to move from C or C++.

Avoiding security related issues based on a whole class of problems prevented in Rust by design is a huge benefit. It's better for compiler to prevent that, than to rely on levels of experience, while anyone can make a mistake in reality.

Post reply on HN