8 ms·
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 o
by palata 2y ago
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 language "because the JVM is slow" (spoiler: it is not) or for C instead of C++ because "it's faster" (spoiler: it probably doesn't matter for your project).
It's a bit like choosing Gentoo "because it's faster" (or worse, because it "sounds cool"). If that's the only reason, it's probably a bad choice (disclaimer: I use and love Gentoo).
- artursapek 2y agoInstall Gentoo
- palata 2y agoAs I said, I use Gentoo already ;-).
- gerdesj 2y agoQuite. I was a Gentoo user (daily driver) for around 15 years but the endless compilation cycles finally got to me. It is such a shame because as I started to depart, Gentoo really got its arse in gear with things like user patching etc and no doubt is even better. It has literally (lol) just occurred to me that some sort of dual partition thing could sort out my main issue with Gentoo. @system could have two partitions - the running one and the next one that is compiled for and then switched over to on a reboot. @world probably ought to be split up into bits that can survive their libs being overwritten with new ones and those that can't. Errrm, sorry, I seem to have subverted this thread.
- curt15 2y agoGentoo Silverblue?
- fc417fc802 2y agoYou have approximately described guix.
- palata 2y agoWhat about the binary packages now supported in Gentoo?
- djmips 2y agoI agree with you except for the JVM bit - but everyone's application varies
- peterashford 2y agoYou think the JVM is slow?
- mceachen 2y agoIME large linear algebra algos run like molasses in a jvm compared to compiled solutions. You're always fighting the gc.
- za3faran 2y agoDo you have any benchmarks to show, out of curiosity?
- deleted 2y ago[deleted]
- light_hue_1 2y agoOk. But we have plenty of C libraries to bind to that for. They're far slower in Python but that hasn't stopped anyone.
- bluGill 2y agoDepends. JVM is fast once hotspot figures things out - but that means the first level is slow and you lose your users.
- echelon 2y agoRust is actually quite suitable for a number of domains where it was never intended to excel. Writing web service backends is one domain where Rust absolutely kicks ass. I would choose Rust/(Actix or Axum) over Go or Flask any day. The database story is a little rough around the edges, but it's getting better and SQLx is good enough for me. edit: The downvoters are missing out.
- benwilber0 2y agoTokio + Axum + SQLx has been a total game-changer for me for web dev. It's by far the most productive I've been with any backend web stack.
- VWWHFSfQ 2y agoRust is very easy when you want to do easy things. You can actually just completely avoid the borrow-checker altogether if you want to. Just .clone(), or Arc/Mutex. It's what all the other languages (like Go or Java) are doing anyway. But if you want to do a difficult and complicated thing, then Rust is going to raise the guard rails. Your program won't even compile if it's unsafe. It won't let you make a buggy app. So now you need to back up and decide if you want it to be easy, or you want it to be correct. Yes, Rust is hard. But it doesn't have to be if you don't want.
- WD-42 2y agoThis argument goes only so far. Would you consider querying a database hard? Most developers would say no. But it’s actually a pretty hard problem, if you want to do it safely. In rust, that difficultly leaks into the crates. I have a project that uses diesel and to make even a single composable query is a tangle of uppercase Type soup. This just isn’t a problem in other languages I’ve used, which granted aren’t as safe. I love Rust. But saying it’s only hard if you are doing hard things is an oversimplification.
- dudinax 2y agoMy feeling is that rust makes easy things hard and hard things work.
- goku12 2y agoI'm not going to deny your experience. But is Rust really that hard? It's a very smooth experience for me - sometimes enough for me to choose it instead of Python. I know that the compiler complains a lot. But I code with the help of realtime feedback from tools like the language server (rust-analyzer) and bacon. It feels like 'debug as you code'. And I really love the hand holding it does.
- dudinax 2y ago"Hard" maybe the wrong word. Tasks that are simple in most other languages, like a tree that can store many data types, are going to take a lot more code and a lot more thinking to get it to work in rust. Generics and traits have some rough edges. If I rub up against them, they're really annoying. Otherwise, if I can avoid those then I agree with you that rust is smooth, and the trade off is worth it.
- wffurr 2y ago>> a bit as if people went for C++ instead of a JVM language "because the JVM is slow" (spoiler: it is not) The OP is doing game development. It’s possible to write a performant game in Java but you end up fighting the garbage collector the whole way and can’t use much library code because it’s just not written for predictable performance.
- palata 2y agoI didn't mean that the OP should use Java. BTW the OP does not use C++, but Rust. This said, they moved to Unity, which is C#, which is garbage collected, right?
- jayd16 2y agoC# also has "Value Types" which can be stack allocated and passed by value. They're used extensively in game dev.
- vips7L 2y agoHopefully that changes once Java releases their value types.
- pjmlp 2y agoYou can already get halfway there with Java, by making use of Panama, even if not exposed at language level. And lets be real, how many devs manage to sell as many copies as Minecraft? Too much discussion about what language to use, instead of what game to make.
- neonsunset 2y agoC#/.NET has huge feature area for low-level/hands-on memory manipulation, which is highly relevant to gamedev.
- elabajaba 2y agoThe core unity game engine is c++ that you can't access, but all unity games are written in c#.
- lolinder 2y agoI 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 boiled it down to looked an awful lot like Rust code, so I thought why not, let's rewrite it in Rust. I took another day to rewrite it all. The result was not statistically different in performance than my Java implementation. Each took the same amount of time to complete. This surprised me, so I made triply sure that I was using the right optimization settings. Lesson learned: Java is easy to get started with out of the box, memory safe, battle tested, and the powerful JIT means that if warmup times are a negligible factor in your usage patterns your Java code can later be optimized to be equivalent in performance to a Rust implementation.
- internetter 2y agoI'd rather write rust than java, personally
- lolinder 2y agoI'd have said the same thing 10 years ago (or, I would have if I were comparing 10-year-old Java with modern Rust), but Java these days is actually pretty ergonomic. Rust's borrow checker balances out the ML-style niceties to bring it down to about Java's level for me, depending on the application.
- vips7L 2y agoI’d rather write Java than Rust, personally
- jandrewrogers 2y ago> 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.
- cantrecallmypwd 2y ago> C++ has been faster than C for a long time. Citation needed.
- haberman 2y ago> 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 think it's meaningful to call one faster than the other.
- krapht 2y agoI know you're going to reply with "BUT MY PREPROCESSOR", but template specialization is a big win and improvement (see qsort vs std::sort).
- ryao 2y agoI have used the preprocessor to avoid this sort of slowdown in the past in a binary search function: https://github.com/openzfs/zfs/commit/677c6f8457943fe5b56d7aa8807010a104563e4a https://github.com/openzfs/zfs/commit/677c6f8457943fe5b56d7a... The performance gain comes not from eliminating the function overhead, but enabling conditional move instructions to be used in the comparator, which eliminates a pipeline hazard on each loop iteration. There is some gain from eliminating the function overhead, but it is tiny in comparison to eliminating the pipeline hazard. That said, C++ has its weaknesses too, particularly in its typical data structures, its excessive use of dynamic memory allocation and its exception handling. I gave an example here: https://news.ycombinator.com/item?id=43827857 https://news.ycombinator.com/item?id=43827857 Honestly, I think these weaknesses are more severe than qsort being unable to inline the comparator.
- wyager 2y agoI write a lot of Rust, but as you say, it's basically a vastly improved version of C++. C++ is not always the right move! For all my personal projects, I use a mix of Haskell and Rust, which I find covers 99% of the product domains I work in. Ultra-low level (FPGA gateware): Haskell. The Clash compiler backend lets you compile (non-recursive) Haskell code directly to FPGA. I use this for audio codecs, IO expanders, and other gateware stuff. Very low-level (MMUless microcontroller hard-realtime) to medium-level (graphics code, audio code): Rust dominates here High-level (have an MMU, OS, and desktop levels of RAM, not sensitive to ~0.1ms GC pauses): Haskell becomes a lot easier to productively crank out "business logic" without worrying about memory management. If you need to specify high-level logic, implement a web server, etc. it's more productive than Rust for that type of thing. Both languages have a lot of conceptual overlap (ADTs, constrained parametric types, etc.), so being familiar with one provides some degree of cross-training for the other.
- goku12 2y agoWhat do you mean by 'a mix of Haskell and Rust'? Is that a per-project choice or do you use both in a single project? I'm interested in the latter. If so, could you point me to an example? Another question is about Clash. Your description sounds like the HLS (high level synthesis) approach. But I thought that Clash used a Haskell -based DSL, making it a true HDL. Could you clarify this? Thanks!
- wyager 2y agoYeah, sometimes I'll do e.g. a backend state management server in Haskell and then a lightweight (embedded) client in Rust. I haven't ever tried linking rust from haskell yet, if that's what you mean. I would actually flip your HDL definition a bit. Clash is a true HDL, but specifically because it's not just a shallowly embedded DSL. Clash is actually a GHC plugin that compiles haskell code to a synchronous circuit representation and then can spit that out as whatever HDL you like. It's emphatically not just a library for constructing circuit descriptions, like most new gateware development tools. This is possible because the semantics of Haskell are (by a mixture of good first-principles design and luck) an almost exact match for the standard four-state logic semantics of synchronous digital circuits. This is also different from the standard HLS approach where the semantics of the source language do not at all match the semantics of the target. With Haskell, they are (surprisingly) very close! Only in a few edge cases (mostly having to do with zero-bit wires and so on) does the evaluation semantics of haskell differ from the evaluation semantics of e.g. verilog.
- WalterBright 2y agoThe advantage C has over C++ is it won't let you use templates.
- oflebbe 2y agothis!
- somenameforme 2y ago> "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 typing, but the difference is that in a weakly typed language that 'feature' is forced upon you, whereas random new feature in C++ or C# is near to always backwards compatible and opt-in only. For instance, to take a dated example - consider move semantics in C++. If you never used it anywhere at all, you'd have 0 problems. But once you do, you get lots of neat things for free. And for these sort of features, I see no reason to ever oppose their endless introduction unless such starts to imperil the integrity/performance of the compiler, but that clearly is not happening.
- tonyedgecombe 2y agoYou 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.
- palata 2y agoMy experience with C++ is that it fundamentally "looks worse" and has worse tooling than more modern languages. And it feels like they keep adding new features that make it all even worse every year. Sure, you don't have to use them, but you have to understand them when used in libraries you depend on. And in my experience in an environment of C++ developers, many times you end up having some colleagues who are very vocal about how you should love the language and use all the new features. Not that this wouldn't happen in Java or Kotlin, but the fact is that new features in those languages actually improve the experience with the language.
- nmeofthestate 2y agoI'm a C++ developer and it's always great when we move to a newer language version, with all the language improvements that come with that.
- mabster 2y agoI think the choice of C++ vs JVM depends on your project. If you're not using the benefits of "unsafe" languages then it probably doesn't matter. But if you are after performance how do do the following in Java? - Build an AOS so that memory access is linear re cache. Prefetch. Use things like _mm_stream_ps() to tell the CPU the cache line you're writing to doesn't need to be fetched. Share a buffer of memory between processes by atomic incrementing a head pointer. I'm pretty sure you could build an indie game without low-level C++, but there is a reason that commercial gamedev is typically C++.
- palata 2y ago> but there is a reason that commercial gamedev is typically C++. Sure, and that's kind of my point. There are a few use-cases where C++ is actually needed, and for those cases, Rust (the language) is a good alternative if it's possible to use it. But even for gamedev, the article here says that they moved to Unity. The core of Unity is apparently C++, but users of Unity code in C#. Which kind of proves my point: outside of that core that actually needs C++, it doesn't matter much. And the vast majority of software development is done outside of those core use-cases, meaning that the vast majority of developers do not need Rust.
- mabster 2y agoWe were using a modified Luajit, in assembly, with a bit of other assembly dotted around the place. That assembly takes a long time to write (to beat a modern C++ compiler). Then we had C++ for all our low level code and Lua for gameplay. We were floating a middle layer of Rust for Lua bindings and the glue code for our transformation pipeline, but there was always a little too much friction to introduce. What we were particularly interested in was memory allocation bugs (use after free and leaks) and speeding up development of the engine. So I could see it having a place.
- pjmlp 2y agoWhile there are many technical reasons to use C++ over Java in game development, many commercial games could be easily done in Java, as they are A or AA level at most. Had Notch thought too much about which language to use, maybe he would still be trying to launch a game today.
- imtringued 2y agoVPS/Cloud providers skimp on RAM. The JVM sucks for any low RAM workload, where you want the smallest possible single server instance. The startup times of JVM based applications are also horrendous. How many gigabytes of RAM does Digital Ocean give you with your smallest instance? They don't. They give you 512MiB. Suddenly using Java is no longer an option, because you will be wasting your day carefully tuning literally everything to fit in that amount.
- icedchai 2y agoYou can get decent startup times if you have fewer dependencies. The JVM itself starts fairly quickly (<200 ms), the problem is all the class loading. If your "app" is a bloated multi gigabyte monstrosity... good luck!
- anacrolix 2y agoThis couldn't be any more accurate even if you compiled with CFLAGS='-march native ' and RUSTFLAGS='-C can't remember insert here'