21–30 of 279 posts
> could have been caught by a run time bounds check And here I thought rust was all about zero cost abstractions.
You can't know everything at compile time. Runtime checks are witnesses that run at program execution instead of compile time.
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 produces efficient standalone binaries. Most of my hobby projects are in Rust now. But I would not rewrite any of my work projects in Rust even though they require ultimate performance. That would be a maintenance burden. It is great to see people rewriting i…
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.
Earlier quoted context omitted.
Rust is about zero cost abstraction. Bound checks can be disabled.
And then it's no longer memory safe, which makes the whole exercise pointless...
Even better is to use iterators and other abstractions that don't require bounds checking at all. Rust has lots of good tools to build efficient code.
Earlier quoted context omitted.
Nullpointer exceptions are a huge thing in Java.
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 Obj…
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 produces efficient standalone binaries. Most of my hobby projects are in Rust now. But I would not rewrite any of my work projects in Rust even though they require ultimate performance. That would be a maintenance burden. It is great to see people rewriting i…
Nullpointer exceptions are a huge thing in Java.
> could have been caught by a run time bounds check And here I thought rust was all about zero cost abstractions.
It's not, that's C++. Rust requires a lot of runtime checks, but that's the price one has to pay for memory safety.
Earlier quoted context omitted.
Rust is about zero cost abstraction. Bound checks can be disabled.
And then it's no longer memory safe, which makes the whole exercise pointless...
Earlier quoted context omitted.
Nullpointer exceptions are a huge thing in Java.
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)
Earlier quoted context omitted.
Nullpointer exceptions are a huge thing in Java.
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 Obj…
That said, "write good tests" is impossible. You can write as many tests as you want, you can make sure those loops loop or don't, and those ifs if or don't, but you cannot write "good" tests. Tests will always miss some corner case, some input, some unexpected locale variable.
Earlier quoted context omitted.
Nullpointer exceptions are a huge thing in Java.
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)
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.