7 ms·

I primarily use Java for my job. Security and memory related features of Rust are not an advantage compared to Java. But I like rust because it feels modern and

• orf 8y ago
  Nullpointer exceptions are a huge thing in Java.
  • Eridrus 8y ago
    I haven't written any Rust in a few years, but last I knew, it was very possible for a Rust program to crash. The guarantee is that it won't corrupt memory while doing so.
    • gpm 8y ago
      That's true, but 'null pointer exceptions' (which I suppose means expecting a Option<&T> to contain a &T when it is instead empty) are much rarer since nullability is made explicit. Rust goals in life towards bugs are basically - Isolate memory bugs to unsafe code which you rarely write. - Make as many classes as bugs reasonably possible rarer by encoding as much as is reasonable in the type system and encouraging the programmer to think about all possible cases. The first gets all the attention because it is the one you can make guarantees about, but the second is really just as important.
    • vaylian 8y ago
      There are different reasons why a program can crash. Nullpointer exceptions are one of them. Out-of-memory situations are another. Rust protects you against the former, but not the latter. But at least in my experience I only encountered crashes when I disabled safety checks by calling .unwrap().
      • jononor 8y ago
        unwrap() does not disable safety checks, it just means you ignore/disregard error handling. It will panic and abort the program, but not cause a safety issue. /pedantic
        • amalcon 8y ago
          This is actually an interesting distinction. The way that Rust defines "safety" is a little jargon-ish. It's probably more useful than the (highly impractical) colloquial meaning, but still different. In a rust context, "safety" means that the program is protected from a very specific set of things. One might expect that set to contain things like crashing (panic! and friends) and leaking memory (forget). It does not, and is not intended to.
          • dullgiulio 8y ago
            But the parent's point remains: a Java NPE and a panic because of unwrap are really equivalent. Not really unsafe in the C sense, but equally bad as unhandled crashes.
            • Yoric 8y ago
              Assuming that nobody catches the NPE by accident or error (according to my experience in Java, it's a pretty big assumption), yes, they pretty much are. The big difference is that, in Java, you typically get your NPE because you didn't know/didn't check that your pointer could be `null` – in other words, the default behavior of the language is to NPE. In Rust, the default behavior of the language is to inform the developer that they need to check. They may decide to explicitly assert that the pointer is not null, causing a crash if it is, but that's a conscious choice. For instance, in my Rust code, pretty much every occurrence of `unwrap()` or `expect()` contains a comment explaining which invariant guarantees that the call will succeed. I don't think I have ever seen any comments associated to a member access in Java.
            • staticassertion 8y ago
              There's one really major distinction - you can `grep` for `unwrap`. You could grep for null, but that won't tell you if an NPE elsewhere is possible, and it won't hit every single case (like 3rd party libs returning null). Making bugs grep'able is huge.
    • jjnoakes 8y ago
      It is possible, but the causes and frequencies are quite different. In Rust runtime panics are certainly possible (array out of bounds, out of memory, etc), but the ones analogous to Java's NullPointerException have to be explicit opted into (unwrapping optionals) and do not happen implicitly. Rust lets you handle optionals in nicer ways which lets you be sure you covered the "null" cases at compile time with no runtime panics possible, if you like.
    • mrath 8y ago
      I think that is somewhat related to the article. There a class of bugs not possible in Rust, they are also not possible in my GCed langs. unwrapping an `Option` is similar to NPE. but that code does not feel idiomatic Rust. IMO there is higher chance of making NPE mistake in Java than unwrapping None in Rust for similar logic.
  • latencyloser 8y ago
    I write Java daily, I haven't seen one in a production environment in... at least recent memory. Most common NPEs I've seen can be resolved by doing two things: 1) for returning a single, nullable value, wrap it in Optional. 2) Never return null collections, always default to an empty collection instead. More nuanced ones can often be caught by using all args constructors and requiring the constructor values with Objects.requiresNonNull() or similar. Using spring? Don't use field or setter injection, always constructor so the above applies as well. Making the state of your objects largely immutable means their state is more consistent and what is null and when becomes a lot less surprising. Lastly, write good tests. If you're exhausting the behavior of your system with tests, these things are much less likely to surprise you later. NPEs are definitely a problem with Java, but they're a very avoidable one as well. Edit: I don't understand the downvotes. The parent said they're a huge deal and I'm disagreeing because I think they're relatively simple to avoid?
    • woah 8y ago
      Rust basically just enforces the things you mention
      • pjmlp 8y ago
        With the cost of catching up to 25 years of tooling and libraries.
        • bluejekyll 8y ago
          We’re getting there. I dislike this argument, I’m sure the same was made in favor of C when Java came out.
          • pjmlp 8y ago
            I agree with you, it is just a call to reality to those "lets rewrite everything in language X", without consideration that there is more to it than just grammar and semantics. Also there are plenty of domains where Java or C++ aren't even taken into consideration, in spite of decades of effort. Just to cite Microsoft's recent security recommendation out of Blue Hat conference, regarding their own software, "use a mix of C#, Rust and constrained C++".
  • FooBadDev 8y ago
    Wouldn't using Koltin or Scala, which benefit from the engineering effort of JVM and arguably its ecosystem solve this problem ? (Since NULL is not idiomatic in either language)
    • 14113 8y ago
      It's not idiomatic, but it's still possible. I've got NullPointerExceptions while writing fairly complex, modern Scala, so it's about as possible as with Java in my experience.
    • on_and_off 8y ago
      Yes and no : I have been using kotlin for a while for Android. Currently our codebase is 75% kotlin. Issues arose at the interface between java and kotlin. Unless there are @Nullable @NonNull annotations (and they need to be truthful), the kotlin compiler cannot know the nullability of something coming from a java method. It can be pretty pernicious : if you use some java written libraries like Moshi (json parsing), it can also lead to crashes : IIRC if you declare a moshi generated property to be non null but it is absent from the json, it will generate an object with null, creating a crash. Still, null is now an anecdotal issue in Kotlin. The Android framework team is working on annotating all their APIs with the corresponding nullability annotations and more and more JVM libs are also working on handling it gracefully. It was never a huge issue to begin with even in java, just pretty cumbersome to have to add annotations everywhere and have to add some policies like 'no null collections, only empty' in a codebase to have sane handling.
• bluejekyll 8y ago
  For me, also primarily a Java person before Rust, it’s datarace safety that captured me. Java’s executors improve the world, but I can’t count the number of concurrency bugs that I had in Java that are not possible in safe Rust. This isn’t just my code, btw, but large teams where it’s hard to disseminate good practices when building threadsafe code. If it had been in Rust, those issues wouldn’t have happened. Other things that I appreciate about Rust over Java is the error handling combined with RAII, doing away with nasty bugs around try’s lacking proper finally statements for closing file handles, etc. Java has its warts, not everything is just about memory safety.
  • mrath 8y ago
    about RAII there is quite a bit of support in recent Java versions not quite as good as Rust but there is support. Data race is one other thing, I do have data race issues but that is very rare. Some of the static analysis tools even catch these anti patterns.
  • agumonkey 8y ago
    Curious about memory usage too
    • bluejekyll 8y ago
      I think the best way to look at it is that memory usage becomes predictable and GC pause free. An application of similar scale and implementation between Java and Rust won't necessarily use less memory when in Rust.
      • agumonkey 8y ago
        Naively I thought Java data model was inherently more demanding than Rust but .. I never read about Rust memory layouts.
• ianlevesque 8y ago
  I use Java constantly in my job and recently tried rewriting a math & memory heavy component in rust to see what performance gains there might be. Surprisingly (to me) the naive rust version was ~15% slower than Java. There’s probably room for more rust optimization but it was interesting that “efficient standalone binaries” doesn’t automatically mean faster too when competing with HotSpot.
  • pjmlp 8y ago
    Google had a fast math library for Android, which got outperformed by ART JIT compiler and was eventually deprecated. https://developer.android.com/reference/android/util/FloatMath.html https://developer.android.com/reference/android/util/FloatMa...
  • carlmr 8y ago
    I find where rust usually shines the most is if you do text processing. String allocations take time. In rust you can often avoid them and use things like cow to only allocate when you change something. That way often my text processing heavy scripts go twice the speed of a C++ version, and they're easier to write with Cargo, too. Compared to highly optimized Java and C# I could often get a quite naive rust implementation to be 10x faster. Naive rust means I didn't spend much time optimizing but I do use appropriate algorithms and to avoid unnecessary allocations.
  • QuercusMax 8y ago
    My experience working on writing image processing code in Java is that rewriting the slowest bits in C++ only gave about a 10% performance boost, and this was over a decade ago. Moving stuff to the GPU was vastly more effective than doing faster CPU work.
  • alex_duf 8y ago
    When comparing speed on the JVM with speed with native languages, the only positive side you get from native binaries is cold start nowadays. For a webapp this doesn't matter, but as we're moving towards more cloud functions it start to make a lot of sense. That needs to be ponderated by the fact any real life application will have to access the network at bootstrap to load configuration and therefore your bottleneck will most likely be I/O.