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

181–190 of 379 posts

Re: Rust vs C Pitfalls

#181

Post by saghm »

lossolo wrote: post #76
steveklabnik wrote: post #71

Earlier quoted context omitted.

http://blog.burntsushi.net/ripgrep/ There are only seven instances of unsafe: https://github.com/BurntSushi/ripgrep/search?q=unsafe&type=C... Four of them are related to calling libc/kernel32 functions, which need unsafe to be called. One is due to using a memory map, which needs unsafe to be called. Only two are actual unsafe rust functions. That's a "real-world" example though, you're asking for a more specific imp…

I told you NO unsafe code. Use only standard library, no third party tools. I have posted Go implementation to Rust magicians (it's just simple buffered reader, you do not need to be Go wizard to write it, any beginner can write it) and I've asked for Rust solution on Rust IRC channel because it was slower than easy Go solution, what I found out it's impossible to do it more efficient in Rust using standard library w…

> I told you NO unsafe code. Use only standard library, no third party tools.

I'm not sure what such an example would prove, other than maybe "Go is better than a subset of Rust excluding some of the core features of the language and its greater ecosystem".

Re: Rust vs C Pitfalls

#182

Post by grzm »

naasking wrote: post #179
grzm wrote: post #176

Earlier quoted context omitted.

If the software does what you want, being able to run on 30 years worth of hardware with just a recompile is a good thing. At the end of the day, it's what the software does that's important.

> If the software does what you want, being able to run on 30 years worth of hardware with just a recompile is a good thing That's not a responsible metric. 30 year old software was written against 30 year old APIs vulnerable to known attack vectors, and with 30 year old notions about security. The belief that this software is suitable for modern use is absurd IMO. And if the types of programs you're talking about ar…

If the software does what you want includes all of those criteria. If you find that there are deficiencies in any of those areas, that would qualify as a reason to make changes, weighed against the cost of doing so.

Re: Rust vs C Pitfalls

#183

Post by mmstick »

gravypod wrote: post #66
mmstick wrote: post #55

Earlier quoted context omitted.

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.

Atom does support Projects. The left panel is where you add your projects, which is created via cargo and has integration within Atom. You can hide the projects panel by pressing Ctrl + '\'. There's an integrated terminal if you install the tokamak terminal. I'm not sure what you mean by a 'go' button though.

Re: Rust vs C Pitfalls

#184

Post by mmstick »

gravypod wrote: post #45
empath75 wrote: post #40

Earlier quoted context omitted.

https://internals.rust-lang.org/t/introducing-rust-language-...

I don't care about the backend and how it's implemented. I don't write IDEs. I write software in IDEs. If the IDE is good, and by good I mean provide autocomplete and features on par with Eclipse for Java,and it needs to be fast and easy to use. Fast and easy to use are UI tricks that can't be handled by a server. Edit: I just realized that this may be read in a negative connotion and I didn't mean it like that. I ju…

The only thing the RLS is going to provide is just faster completion for the most part. All the IDE's in existence right now are making use of racer for completion and clippy for linting quite well without it, especially Atom.

Re: Rust vs C Pitfalls

#185

Post by Manishearth »

Animats wrote: post #171
mmstick wrote: post #55

Earlier quoted context omitted.

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…

Agree that Rust lacks something comparable to NumPy for numeric work. Rust does have lots of numeric crates. Too many. I took a look at matrix multiply functions recently.(See [1], below "Here is what the Rust compiler actually does", for some notes on the effectiveness of Rust's subscript checking optimization.) "algebloat" wouldn't compile on stable. "matrixmultiply" is all unsafe code, with C-type raw pointers. "n…

> "ndarray" has unsafe indexing

We've had this discussion before. ndarray exposes both a safe and unsafe API for indexing, just like the stdlib vector (or core arrays). That is not problematic.

I agree that the lack of standardization is a problem, though. I think that mostly folks use ndarray or nalgebra (and num if they need bigints). Anyone can upload a crate, the question is if the crate is the main one used by the community. There are some efforts to make it easier to choose crates amongst alternatives on crates.io, however.

I suspect most of the issue here is just that no group (only individuals) is using Rust for scientific computing yet, so there's no large driving effort behind getting good libraries here. When I needed this in Rust I just picked the library that I thought would work best with very little thought, with no thoughts on writing my own or improving the lib because I didn't have time. When larger groups work on things generally attention gets paid to stuff like this and better solutions come out on top. Rust isn't quite there yet in adoption for this to happen, maybe soon :)

Re: Rust vs C Pitfalls

#186

Post by Manishearth »

lobster_johnson wrote: post #140
mmstick wrote: post #55

Earlier quoted context omitted.

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…

Does Rust have anything like "gorename" and "goimports"?

https://github.com/jonathandturner/rls (still WIP) has rename support I think. Unsure if imports are in the plan.

Re: Rust vs C Pitfalls

#187

Post by lossolo »

mmstick wrote: post #175
lossolo wrote: post #149

Earlier quoted context omitted.

I have different times for both naive solutions on my machine than you. It's 2.6 seconds for Go and 3.5 seconds for Rust, both perf results and code here: http://pastebin.com/WwhvHH6S

Your Rust example is kind of odd. Did you not see the linting errors in your editor or from the compiler? You can basically boil it down to just two lines of Rust. https://gist.github.com/mmstick/a8316ba0514f9d9ab33b18fa9b91... As for timing, I'm doubtful that Go is any faster than Rust. I don't have this www.js file so I can't test it on my laptop, but I'm pretty sure you didn't even attempt to do things like enabli…

I don't know if you noticed but we are discussing naive solutions which I've mentioned couple of times in previous posts. Code you linked is not naive solution. Things you proposed to do are not naive either.

Re: Rust vs C Pitfalls

#188

Post by gigatexal »

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…

Disagree. Rust seems like all the things we have been wishing C/C++ was. It's on my list of languages to learn next for sure.

Re: Rust vs C Pitfalls

#189

Post by Manishearth »

cderwin wrote: post #169
pornel wrote: post #92

Earlier quoted context omitted.

Because Rust is IMHO the first viable replacement for C. Well-written C programs translate almost 1:1 to Rust. It can do (roughly) everything C can, i.e. it's natively compiled, gives control of memory layout, and doesn't depend on a GC runtime. Previous C killers were either dependent on a fat runtime (which isn't a big problem in general, but is a problem for some of niches dominated by C), or didn't offer meaningf…

On my system (2015 MBP running Ubuntu 16.04) Rust's hello world compiles to a nearly 3.5 MB executable. Compiling the equivalent C program with clang results in an executable under 9 KB. Rust may not have a GC, but its executables are certainly fat. Note: Rust executables can be trimmed down by stripping them (not done by default, even for release builds) and using libc malloc instead of jemalloc. But even then, C wi…

> But even then, C wins by a lot.

C links dynamically to its libraries. Rust does not (by default).

This overhead is a constant overhead so it rarely matters. When it does, you can strip it down further and get it to the same level as C.

This is not evidence of a fat runtime, just a different default compilation strategy that prodces larger binary executables. jemalloc is (an optional) part of the runtime, but the rest isn't.

Re: Rust vs C Pitfalls

#190

Post by mmstick »

cderwin wrote: post #169
pornel wrote: post #92

Earlier quoted context omitted.

Because Rust is IMHO the first viable replacement for C. Well-written C programs translate almost 1:1 to Rust. It can do (roughly) everything C can, i.e. it's natively compiled, gives control of memory layout, and doesn't depend on a GC runtime. Previous C killers were either dependent on a fat runtime (which isn't a big problem in general, but is a problem for some of niches dominated by C), or didn't offer meaningf…

On my system (2015 MBP running Ubuntu 16.04) Rust's hello world compiles to a nearly 3.5 MB executable. Compiling the equivalent C program with clang results in an executable under 9 KB. Rust may not have a GC, but its executables are certainly fat. Note: Rust executables can be trimmed down by stripping them (not done by default, even for release builds) and using libc malloc instead of jemalloc. But even then, C wi…

Not a particularly fair comparison though, as that C binary is loading dynamic libraries that are already in memory. Case in point: that C program needs the C standard library, but by default that library (glibc) is dynamically loaded. Rust is not offering the Rust standard library as a dynamic library, hence the larger size. Not to mention, interfacing with C functions in the kernel.

You'll get different results if you compile them with musl for truly static and fair binary size comparisons.

Post reply on HN