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

Migrating away from Rust

deadmoney.gg

Post reply on HN
Print view View original

481–490 of 799 posts

Re: Migrating away from Rust

#481

Post by WalterBright »

haberman wrote: post #328
jandrewrogers wrote: post #295

Earlier quoted context omitted.

> C instead of C++ because "it's faster" (spoiler: it probably doesn't matter for your project) If your C is faster than your C++ then something has gone horribly wrong. C++ has been faster than C for a long time. C++ is about as fast as it gets for a systems language.

> C++ has been faster than C for a long time. What is your basis for this claim? C and C++ are both built on essentially the same memory and execution model. There is a significant set of programs that are valid C and C++ both -- surely you're not suggesting that merely compiling them as C++ will make them faster? There's basically no performance technique available in C++ that is not also available in C. I don't thi…

> What is your basis for this claim?

Great question! Here's one answer:

Having written a great deal of C code, I made a discovery about it. The first algorithm and data structure selected for a C program, stayed there. It survives all the optimizations, refactorings and improvements. But everyone knows that finding a better algorithm and data structure is where the big wins are.

Why doesn't that happen with C code?

C code is not plastic. It is brittle. It does not bend, it breaks.

This is because C is a low level language that lacks higher level constructs and metaprogramming. (Yes, you can metaprogram with the C preprocessor, a technique right out of hell.) The implementation details of the algorithm and data structure are distributed throughout the code, and restructuring that is just too hard. So it doesn't happen.

A simple example:

Change a value to a pointer to a value. Now you have to go through your entire program changing dots to arrows, and sprinkle stars everywhere. Ick.

Or let's change a linked list to an array. Aarrgghh again.

Higher level features, like what C++ and D have, make this sort of thing vastly simpler. (D does it better than C++, as a dot serves both value and pointer uses.) And so algorithms and data structures can be quickly modified and tried out, resulting in faster code. A traversal of an array can be changed to a traversal of a linked list, a hash table, a binary tree, all without changing the traversal code at all.

Re: Migrating away from Rust

#483

Post by tonyedgecombe »

somenameforme wrote: post #480
palata wrote: post #208

I really like Rust as a replacement for C++, especially given that C++ seems to become crazier every year. When reasonable, nowadays I always use Rust instead of C++. But for the vast majority of projects, I believe that C++ is not the right language, meaning that Rust isn't, either. I feel like many people choose Rust because is sounds like it's more efficient, a bit as if people went for C++ instead of a JVM langua…

> "I really like Rust as a replacement for C++, especially given that C++ seems to become crazier every year." I don't understand this argument, which I've also seen it used against C#, quite frequently. When a language offers new features, you're not forced to use them. You generally don't even need to learn them if you don't want. I do think some restrictions in languages can be highly beneficial, like strong typin…

You can't avoid a lot of this stuff, once libraries start using it or colleagues add it to your codebase then you need to know it. I'd argue you need to know it well before you decide to exclude it.

Re: Migrating away from Rust

#484

Post by jamessinghal »

ycombinatrix wrote: post #466
lolinder wrote: post #267

Earlier quoted context omitted.

I have a personal-use app that has a hot loop that (after extensive optimization) runs for about a minute on a low-powered VPS to compute a result. I started in Java and then optimized the heck out of it with the JVM's (and IntelliJ's) excellent profiling tools. It took one day to eliminate all excess allocations. When I was confident I couldn't optimize the algorithm any further on the JVM I realized that what I'd b…

>I realized that what I'd boiled it down to looked an awful lot like Rust code you're no longer writing idiomatic java at this point - probably with zero object oriented programming. so might as well write it in Rust from the get-go.

Yes but it would just be the hot loop in this case; the rest of the app can still be in idiomatic Java, and you still get the GC.

Re: Migrating away from Rust

#485

Post by srcreigh »

haberman wrote: post #328
jandrewrogers wrote: post #295

Earlier quoted context omitted.

> C instead of C++ because "it's faster" (spoiler: it probably doesn't matter for your project) If your C is faster than your C++ then something has gone horribly wrong. C++ has been faster than C for a long time. C++ is about as fast as it gets for a systems language.

> C++ has been faster than C for a long time. What is your basis for this claim? C and C++ are both built on essentially the same memory and execution model. There is a significant set of programs that are valid C and C++ both -- surely you're not suggesting that merely compiling them as C++ will make them faster? There's basically no performance technique available in C++ that is not also available in C. I don't thi…

At a certain point, C++ compile time computation becomes something you really can’t do in C. https://codegolf.stackexchange.com/a/269772

Re: Migrating away from Rust

#486

Post by pcwalton »

demaga wrote: post #467
pcwalton wrote: post #312

Earlier quoted context omitted.

> More than anything else, this sounds like a good lesson in why commercial game engines have taken over most of game dev. There are so many things you have to do to make a game, but they're mostly quite common and have lots of off-the-shelf solutions. > That is, any sufficiently mature indie game project will end up implementing an informally specified, ad hoc, bug-ridden implementation of Unity (... or just use the…

But it also doesn't have even 10% of Unity features. Bevy docs themselves warn you that you are probably better off with something like Godot, at least while Bevy is still in early development.

Over the past year I've been working at my studio to add enough features to Bevy to ship real apps, and Bevy is at the point where one can reasonably do that, depending on your needs.

Re: Migrating away from Rust

#487

Post by tonyedgecombe »

vips7L wrote: post #368
aquariusDue wrote: post #361

Earlier quoted context omitted.

Yep, that's precisely it! When dealing with other languages I miss the "match" keyword and being able to open a block anywhere. Sure, sometimes Rust allows you to write terse abominations if you don't exercise a dose of caution and empathy for future maintainers (you included). Other than the great developer experience in tooling and language ergonomics (as in coherent features not necessarily ease of use) the reason…

What language are you using that doesn’t have match? Even Java has the equivalent. The only ones I can think of that don’t are the scripting languages.. Python and JS.

Does Java have sum types now?

Re: Migrating away from Rust

#488

Post by noisy_boy »

im3w1l wrote: post #478
noisy_boy wrote: post #398

Earlier quoted context omitted.

If I have all the time in the world, sure. When I'm racing against a deadline, I don't want to wrestle with the borrow checker too. Sure, it's objections help with the long term quality of the code and reduce bugs but that's hard to justify to a manager/process driven by Agile and Sprints. Quite possible that an experienced Rust dev can be very productive but there aren't tons of those going around. Java has the stig…

I have found that the ClassFactoryGeneratorFactories sneak up on you. Even if you don't want to the ecosystem slowly but surely nudges you that way.

That has not been my experience. Sure, you don't have any control over the third-party stuff but I haven't seen this issue being widespread in the mainstream third-party libraries I've used e.g. logback, jackson, junit, jedis, pgJDBC etc which are very well known/widely used. The only place I've actually seen proliferation of this was by a contractor, who I suspect, was trying to ensure job security behind impenetrability.

Re: Migrating away from Rust

#489

Post by tonyedgecombe »

aquariusDue wrote: post #361
echelon wrote: post #298

Earlier quoted context omitted.

Perhaps. But a comparable Rust backend stack produces a single binary deployable that can absorb 50,000 QPS with no latency caused by garbage collection. You get all of that for free. The type system and package manager are a delight, and writing with sum types results in code that is measurably more defect free than languages with nulls.

Yep, that's precisely it! When dealing with other languages I miss the "match" keyword and being able to open a block anywhere. Sure, sometimes Rust allows you to write terse abominations if you don't exercise a dose of caution and empathy for future maintainers (you included). Other than the great developer experience in tooling and language ergonomics (as in coherent features not necessarily ease of use) the reason…

>Anyway, would I recommend Rust to everyone?

For me it's a question of whether I can get away with garbage collection. If I can then pretty much everything else is going to be twice as productive but if I can't then the options are quite limited and Rust is a good choice.

Re: Migrating away from Rust

#490

Post by Ygg2 »

SkiFire13 wrote: post #468
Ygg2 wrote: post #428

Earlier quoted context omitted.

> fight the borrow checker I see this and I am reminded when I had to fight the 0 indexing, when I was cutting my teeth in C, for class. I wonder why no one complains about 0 indexing anymore. Isn't it weird how you have to go 0 to length - 1, and implement algorithm differently than in a math book?

Because the math books are the ones being weird. https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831...

Maths books aren't being weird. They are counting in a way most people learn to count. One apple, two apples, three apples. You don't start zeroth apple, one apple, two apples, then respond the set of apple contains three apples.
Post reply on HN