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

311–320 of 379 posts

Re: Rust vs C Pitfalls

#311

Post by steveklabnik »

zerofan wrote: post #115
steveklabnik wrote: post #91

Earlier quoted context omitted.

> 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…

Weird, it was fine for me with and without -O. Nothing about that code should be doing bounds checks, as it's just allocating an array.

Re: Rust vs C Pitfalls

#312

Post by steveklabnik »

devty wrote: post #198
steveklabnik wrote: post #60

Earlier quoted context omitted.

Thank you! Carol and I are working on the second edition, you can read what we have so far here: http://rust-lang.github.io/book/ (I think it's even better, but I'm biased)

I'm enjoying the new write-up on ownership/references/borrowing! It reads more like an fascinating reading on PL concept than a language-specific manual. Great work!

Thank you!

Re: Rust vs C Pitfalls

#313

Post by hamilyon2 »

dispose13432 wrote: post #22
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…

>On similar note, why Rust over Go? I was going to say that rust has performance advantages over Go (due to GC), but look at benchmarks: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Go wins some and looses some, but it's all in the ballpark (except Binary trees [1] which it loses even to Java(!)). It's true that rust is a new language, but so is Go. [1]: I assume it's because it's a test of GC, but…

This site explicitly mentions that results of benchmarks mean almost nothing. Google published results that tell that golang is slower than java in real applications

Re: Rust vs C Pitfalls

#314

Post by tatterdemalion »

blub wrote: post #269
groovy2shoes wrote: post #257

Earlier quoted context omitted.

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 pr…

When Rust (or Swift or golang) gets ISO standardized we'll know that it's mature and left the "move fast and break things" phase. This won't happen, because it's still growing now, so it doesn't make sense to standardize. They might even always want to be able to move fast. I don't see golang ever being standardized. The fact that someone says on HN "we're backwards compatible" doesn't quite offer the same level of t…

> Especially when there are some conflicting reports out there i.e. there are many super-awesome libraries that only work with nightly (I think it's called), because many of those maintainers are early adopters that love to try out new features.

This is totally orthogonal to whether or not Rust stable is backward compatible, which it is. People put a lot of work into making sure it is, and this sort of FUD is very frustrating to read.

Re: Rust vs C Pitfalls

#315

Post by mmstick »

tempodox wrote: post #263
mmstick wrote: post #210

Earlier quoted context omitted.

You're only going to anger people by referring to another group as 'evangelists' when you yourself have already made note that you don't know enough about Rust to see why they are promoting it. There's much more to Rust than safety. You should actually spend a few months with it, and then give your opinion.

> ...you don't know enough about Rust to see why they are promoting it. If you have to know a lot about Rust to find out why you're using it in the first place, you certainly do have a chicken-or-the-egg problem. And, if the promotion doesn't leave you with a clear idea of why you might want to use Rust, that promotion couldn't have been very successful.

The same is true of any technology. One cannot give an informed opinion without first being informed about the technology in the first place. Technology moves forward because there are many whom are willing to leave the comfort of their boxes into the unknown to try things without being required to be convinced.

Re: Rust vs C Pitfalls

#316

Post by igouy »

steveklabnik wrote: post #78
lossolo wrote: post #75

Earlier quoted context omitted.

> Case in point, some are featuring custom hash maps that feature hashing algorithms that, while fast, would never be useful as they provide no protection against collisions. They are useful in this case, aren't they? Custom hash map implementation can be also useful in other scenarios. This is feature of the language that allow you to do that so it's not "illegal" to use it. If Rust doesn't allow you to do something…

Rust can do custom hashes as well, to be clear. There's been some arguments over what hashes are allowed in the game in the past.

To be clear: anyone can contribute a Rust k-nucleotide program that uses a custom hash function, just like those used by other programming languages.

Re: Rust vs C Pitfalls

#317

Post by tatterdemalion »

blub wrote: post #272
groovy2shoes wrote: post #247

Earlier quoted context omitted.

I could definitely live with such a solution, but even six months might be too quick. So, as long as the plan is to lengthen the LTS window, I think that could work. The company that employs me just upgraded to a C++11-capable version of GCC three months ago. Even C++'s three year cadence seems like it might be too fast! Thing is, the company wants to vet our entire platform, which itself only changes yearly. They wa…

Completely agree, C++'s three year cadence is probably the fastest more conservative industries are willing to go. And why should one invest time for such a low-level component in their toolkit every 6 months?! I want to build software and solve problems, not spend my time keeping up with programming languages and library updates.

I have upgraded Rust every six weeks. I run `rustup update stable` and wait a minute. Its not a time investment! Rust puts so much work into guaranteeing backwards compatibility so that updating every 6 weeks is an effortless process.

You seem to come from an experience where software updates are kinda sorta mostly backwards compatible. Rust works very hard to actually be backwards compatible. There is infrastructure to check for regressions across the entire package ecosystem, which is run regularly on HEAD and on any commit we think might potentially be breaking before we even land it.

Re: Rust vs C Pitfalls

#318

Post by dikaiosune »

groovy2shoes wrote: post #250
naasking wrote: post #179

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 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…

More often than not, brand-spanking-new software is written against 30-year-old APIs. Lots of software we use day-to-day is old . For example, a couple years ago I fixed a 20-year-old bug in netcat, which itself hadn't been updated since the mid 90s. After I fixed the bug, I didn't need to fish out an old compiler or any compatibility libraries; I just compiled it with the latest GCC and glibc, and carried on with my…

> After I fixed the bug, I didn't need to fish out an old compiler or any compatibility libraries; I just compiled it with the latest GCC and glibc, and carried on with my day.

Could you show me an example where post-1.0 you wouldn't be able to do this with Rust?

Re: Rust vs C Pitfalls

#319

Post by Manishearth »

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 point of that comment was to say "It's being worked on, actively"

Re: Rust vs C Pitfalls

#320

Post by [deleted] »

fungos wrote: post #308

You're so wrong that is laughably. That laughably hashing functions are highly specialized implementations for a proposed problem. There is NO MORAL there. I code C for living and if we can use "laughably hashing functions" to gain performance we WILL DO.

[deleted]
Post reply on HN