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

251–260 of 379 posts

Re: Rust vs C Pitfalls

#251

Post by masklinn »

santaclaus wrote: post #14
manaskarekar wrote: post #9

Earlier quoted context omitted.

In addition to htaunay's post about docs, Rust also has cargo and crates.io which are fucking awesome. Blog posts are one way to showcase tooling, perhaps not this one, but they have their place.

> Rust also has cargo and crates.io Which is undersold in the propaganda! Safety, ehhh I'll take it but I'm not jonesing for it. A package manager that works and has adoption? Thank you! I've wasted far too much time wrangling C++ dependencies by hand...

My guilty pleasure these days is running `cargo doc --open`. Generating local docs for my package and all its dependencies? I love.

Re: Rust vs C Pitfalls

#252

Post by idobai »

bluejekyll wrote: post #157
all2well wrote: post #113

Earlier quoted context omitted.

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…

> I don't think I'd really want to use Rust in production yet... Why not out of curiosity? I've already been showing off to people at work how much shorter Rust code is than our corresponding Java, how much easier it is to build and deploy, and how much more stable it is. Granted I've been using it at small micro service scale at the moment, but I see no reason not to go into production at the moment (well, except fo…

> Why not out of curiosity? I've already been showing off to people at work how much shorter Rust code is than our corresponding Java, how much easier it is to build and deploy, and how much more stable it is.

And I can show you how shorter, simpler and safer code I can write in Scala. People really overrate rust - this language isn't that nice syntactically and the only "new" thing it brought is the compile-time "unique_ptr".

Re: Rust vs C Pitfalls

#253

Post by Zardoz84 »

pornel wrote: post #88
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…

I write libraries. In Go I can only write libraries for Go programs. In Rust I can write libraries for any program. i.e. Rust can easily produce static and dynamic libraries that are linkable with C programs and any language with a C FFI. I can write Rust code that works for programmers using C, C++, C#, D, Go, Swift, Python, PHP, Java, etc.

Like Dlang

Re: Rust vs C Pitfalls

#254

Post by throwitfar »

Manishearth wrote: post #146
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…

> If you're fighting, you've lost. I don't really get this attitude, it means that nothing new will ever overcome anything that's been established. > Anything that can be done easily in C or C++ will need to be easier in Rust for everyone to move You don't even need folks to move from C. Rust has had lots of success when it comes to folks completely new to systems programming learning it through Rust. Predominantly p…

Do people choose languages based on blog posts? I've never done that, usually it was a combination of literature and mailing lists that convinced me. I also ignore conferences entirely.

Re: Rust vs C Pitfalls

#255

Post by rat87 »

adrianN wrote: post #246
duneroadrunner wrote: post #227

Earlier quoted context omitted.

Well, I don't know about java's reputation, but there's this: http://www.cvedetails.com/product/19117/Oracle-JRE.html?vend... http://www.cvedetails.com/product/1526/SUN-JRE.html?vendor_i...

The Java VM is written in C though.

There are many java vms

The most popular(hotspot/openjdk) is written in c++/assembly

Re: Rust vs C Pitfalls

#256

Post by sjellis »

hueving wrote: post #228
vatotemking wrote: post #221

Earlier quoted context omitted.

> You don't even need folks to move from C. Rust has had lots of success when it comes to folks completely new to systems programming learning it through Rust. Predominantly python/ruby/whatever shops are using Rust because they need a fast language, but don't want to deal with safety issues. This resonates well with me. I came from PHP and I decided to learn C in order to contribute to an existing PHP extension. I w…

>Right now, the Rust community is filled with the smartest and friendliest devs I know of among open source communities, and I kinda like it to stay that way. I have yet to find a community that has gotten popular and hasn't turned into a sewage plant. I think it's just a reflection on what the general population is like... :(

The Rust community is as great as it is because of very deliberate decisions and investment in engineering structures to maintain a positive community at scale, so I'm pretty optimistic that it will stay really good. Arguably this work is as innovative as the language itself.

Emily Dunham of Mozilla has a talk about this Community Automation: https://www.youtube.com/watch?v=dIageYT0Vgg

Re: Rust vs C Pitfalls

#257

Post by groovy2shoes »

mmstick wrote: post #193
groovy2shoes wrote: post #90

Earlier quoted context omitted.

C has also been relatively stable for the last 25 years or so. Rust changes every 6 weeks. Yes, the language is supposedly not undergoing breaking changes without strict deprecation and feature-gating. However, as new features are added to the language, libraries are usually updated to leverage them, and suddenly you are also forced to keep up with that rapid release cadence to ensure your project still builds. Meanw…

The problem with your concept is that C does not offer an official standard library and compiler suite, so you're trying to compare the C spec to the Rust standard library + compiler. The actual Rust API has changed very little since the 1.0 release. All the changes that have occurred have been mere additions to the language -- nothing breaking. Hence why the 1.0 release was termed as a 1.0 release. There won't be an…

C does have a standard library. It's described in full in the ANSI/ISO/IEC standard for the C programming language, and it's on your system, likely called libc or something along those lines.

Anyway, I don't think that's a problem with my concept at all. What I want for Rust, and what I think will eventually be feasible for Rust as the language matures, is a standard that can be shared by compiler writers and Rust programmers. A standard is worthless if it's inadequate (see ISO Pascal or ISO Basic, for example), so it's a good thing that right now Rust is iterating quickly and improving rapidly. But eventually, there's going to need to be a stationary target for compiler writers to aim for, and for Rust programmers to be confident that the code they write today won't be littered with deprecated features, anti-patterns, and worst practices tomorrow.

Frankly, I don't see wide adoption happening in the corporate world until there's an LTS compiler at the very least.

Re: Rust vs C Pitfalls

#258

Post by enygmata »

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…

> * Great Libraries ( Everything and a kitchen sink )

This is a must for me. I often give up on compiled languages because libfoobar isn't yet available on the language and I have no interest in writing (and maintaining) language bindings for third party libraries I use.

My dream is that one day I'll be able to do something like:

    Foobar = link_cimport({"headers": ["foobar.h"], "packages": [ "foobar" ], "prefix": "foobar_"});
    Foobar.do_something(); // would call foobar_do_something();
    Foobar.hidden_function(); // would call hidden_function();
and the compiler will give me an executable that was linked against `foobar` instead of dlopen()ing it at runtime. Something like:

    Foobar = loadable_cimport({"headers": ["foobar.h"]});
    foo = Foobar.load("/path/to/foo.so");
    bar = Foobar.load("/path/to/bar.so");
would also be nice because I often have to load libraries that implement the same API/ABI.

Re: Rust vs C Pitfalls

#259

Post by tomjakubowski »

lossolo wrote: post #69
empath75 wrote: post #35

Earlier quoted context omitted.

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++.

This is a misleading comment. A Rust program may use reference counting by explicitly wrapping some value in Rc or Arc; the standard library provides these generic types. There are no "constructs" built in to the language or standard library that require the use of reference counting.

Re: Rust vs C Pitfalls

#260

Post by millstone »

michaelmior wrote: post #166

> “Safe” code is guaranteed to be 100% safe. Not statistically safe. Not safe when the compiler feels like it. As long as your code compiles, it will be safe in terms of memory safety and data-race freedom. As far as I am aware, the Rust compiler has not been proved correct. So whether or not your code is correct still depends on the correctness of the compiler. Of course this is probably correct, but still not 100%…

I can make your code as safe as you like, if you only let me define what "safe" means!
Post reply on HN