Live data from Hacker News

Rust vs C Pitfalls

garin.io

61–70 of 379 posts

Re: Rust vs C Pitfalls

#61
post #32

Earlier quoted context omitted.

I doubt that a significant amount of C programmers will switch to Rust. On the other hand, rust is very attractive for us C++ programmers.

To me it's almost the opposite. I like C a lot, but I ended up compromising on C++11 because in some programs I need more features to keep the implementation clean. I pay the cost of a messy language (C++) when implementing my libraries in order to have simpler applications that use those libraries. I've written C-like programs in Rust, and that goes very well. But I really like function overloading, generic operator…

How would you have gone about making Strings be "as comfortable as integers"?

Arrays are indexed by usize, so if you're on a 64-bit machine, then you shouldn't need a cast. It's _unconstrained_ numbers that default to i32, not anything without a suffix.

Re: Rust vs C Pitfalls

#62
post #56

Earlier quoted context omitted.

No one has ever argued that it's impossible to write c code, but just because you haven't found those kinds of bugs in your code, doesn't mean that it isn't there. We're still finding 10+ year old bugs in Linux.

I'd like to see if Rust is still around in 10 years and then look before we declare the winner on this.... All software has bugs.

It's been around for roughly six or eight already, depending on how you count. Of course, pre-1.0 was a different thing, but still. Ten years is not that long a time.

(I still agree that results at that point will be more interesting then speculating today.)

Re: Rust vs C Pitfalls

#63
post #26

Earlier quoted context omitted.

I'm terribly sorry you've never encountered an experienced developer who uses C or C++ before, or think we're non-existent, or that using extremes like "never" is a reasonable position instead of an incredibly terrible hasty generalization. If there were as many blown off feet as comments on HN suggested technology even as it currently is simply wouldn't function. Do you even understand how much mission and safety cr…

No one has ever argued that it's impossible to write c code, but just because you haven't found those kinds of bugs in your code, doesn't mean that it isn't there. We're still finding 10+ year old bugs in Linux.

Who claimed I haven't found these kinds of bugs in my code?

My response was to a commenter who, as far as I can tell, represents the mainstream Rust community's view: that it's impossible to write safe C or, worse, that infallibility is a reasonable standard to apply. The latter is especially vex-some from my point of view, because Rust is not infallible, I happen to find it (so far) much more pleasurable to use than either C or C++, and I would very much like to see it have broader adoption.

Re: Rust vs C Pitfalls

#64

Earlier quoted context omitted.

I'm 19, I started out with Java, I switched to JavaScript for some time, I move on to Python for which most of my projects exist in and sometimes I use C when the job counts for it. I'm also a pretty big fan of PHP and a few other technologies that are very nice. To recap this has been my life as a programmer: Java -> JavaScript -> PHP -> Python/C/Assembly This dream that most people have made up about programmers no…

Yeah but you're just getting started. Talk to me after you've been paid to be a python developer for 20 years or whatever and tell me how interested you are in learning a new language. I play with a lot of languages but I've invested a lot of time into learning python and getting a nice python workflow going. It would take a lot for me to switch to another primary first language. I work at a tech company that's been…

Yeah I can use several languages (C,C++,python,go,rust,x64,perl,scala,etc...) But I always envision starting a project in C or C-like C++ because I learned it first and after decades I know that language inside and out and my brain's "workflow" and my actual tool setup and personal libraries means I can crank working solutions out extremely quickly.

Re: Rust vs C Pitfalls

#65
post #51
post #25

Earlier quoted context omitted.

That counts as a personal attack, and those are not allowed on HN—especially not against brand new users, which most new accounts belong to. Please don't do this again. We detached this subthread from https://news.ycombinator.com/item?id=13266687 and marked it off-topic.

Let's get real, this looks like classic astroturfing to me. (edit: ok, it was not)

They have a long-running Reddit account, for one: https://www.reddit.com/user/mmstick

Throwing around accusations of astroturfing with no evidence isn't a good look.

Re: Rust vs C Pitfalls

#66
post #55

Earlier quoted context omitted.

Like you I need something like NumPy and SciPy for my work. I'd also like an IDE. An IDE goes a long way to helping me feel comfortable to use a language.

Rust's had great IDE support for more than a year now. - There's Atom with Tokamak, which you must also install racer and clippy via cargo to get rapid in-line linting. - Then there's Visual Studio Code with RustyCode which you can also integrate with racer and clippy, that provides faster code completion and hovering over items will show a tooltip that documents that items. - Some people like IntelliJ Rust, but I've…

I've still not been able to get Rust to work with work in IntellJ or Eclipse. I've not tried Atom but that doesn't support "Projects" or "Solutions" in the way I'd like. From what I understand there is no "go" button.

Re: Rust vs C Pitfalls

#67
post #31

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…

I was writing software in Go for a year before I switched to Rust. I've not felt a need to touch Go since. Basically, anything you can do in Go, you can also do in Rust, but Rust will let you do it with higher efficiency and with significantly less lines of code. In the end, it's just easier to write software with Rust than it is Go. Feature-wise, Rust features generics and functional programming via higher-order fun…

> Basically, anything you can do in Go, you can also do in Rust, but Rust will let you do it with higher efficiency and with significantly less lines of code.

Then i challenge you. Read 5 GB text file, line by line and search for one string that occur lets say 200k times and count how many times it occurs in file without going into C or using unsafe keyword in Rust, do it as you say more efficient than in Go (faster so less CPU time usage + less memory usage) in less lines of code.

Re: Rust vs C Pitfalls

#68
post #51

Earlier quoted context omitted.

Let's get real, this looks like classic astroturfing to me. (edit: ok, it was not)

They have a long-running Reddit account, for one: https://www.reddit.com/user/mmstick Throwing around accusations of astroturfing with no evidence isn't a good look.

OK, I stand corrected then. Sorry for the noise.

Re: Rust vs C Pitfalls

#69

Earlier quoted context omitted.

Hmm, not sure I understand? Re-reading, perhaps my phrasing wasn't clear. What I meant was that I use Rust, and it's not simply because it lacks GC. There are lots of other good reasons too. To be even clearer: I don't think Rust's value proposition depends on whether you absolutely must avoid GC or not.

Rust has gc, no?

It has reference counting for some of the constructs which is a form of garbage collection and it has runtime overhead. Like shared_ptr in c++.

Re: Rust vs C Pitfalls

#70

A more interesting question for me is: is there any reason why would I want to use Rust over Haskell on any task where Haskell is "fast enough"?

Rust seems to be more lightweight and portable in general. I think the compiler uses far less memory (and IIRC has better cross-compilation support too). The binaries are much smaller and the runtime is simpler. Cargo is amazing and I have much more confidence in it to not give me build trouble. In particular, you get a test framework including doc tests for free; I know Haskell tools offer similar functionality but in practice the setup cost is far higher. Haddock is not bad, but it uses its own weird syntax; Rust's documentation system uses Markdown IIRC.

Also, some things are just easier to write in an imperative language. I expect that the performance and memory use of Rust programs is also easier to predict and understand, though generally I think Haskell gets a lot of unfair criticism in that department.

I haven't used Haskell in a while so some of the things I mentioned may have been improved upon since then. In particular, Stack may have grown up a bit.

Post reply on HN