Hacker News Reader

Comment by satvikpendem | Hacker News Reader

I just clone everywhere and write Rust like a high level language. Then, once I need to optimize more, if I ever do (as Rust is many times faster than other languages even with liberal cloning), then I simply go through and remove the clone where needed.

View on HN

> as Rust is many times faster than other languages even with liberal cloning

Have you really compared? I have. Rust was faster for "small input", but quickly got beaten by Java and other languages I tried because the cost of doing things this way grows exponentially. I suggest you run benchmarks before you make your mind up and start throwing opinions around.

I have never benchmarked Java vs other languages, but from experience java applications always have horrible startup time. So, there might be some contexts in which long running Java application can beat Rust or other language, but if you need something that starts instantly (like CLI utilities) Java is a no-go.

Another wart is that there are some written and non-written standards on CLI arguments (e.g. long option names should start with double hyphens) that 99% of Java CLI apps violate for some reason. Maybe I'm a perfectionist but it makes me uncomfortable to use Java CLI apps.

I'm no Java expert but they seem to be solving startup time with ahead-of-time (AOT) compilation.

https://medium.com/@subhajitc77/how-java-17-and-spring-boot-...

> So, there might be some contexts in which long running Java application can beat Rust

yes, context is essentially all server side SaaS business segment..

> So, there might be some contexts in which long running Java application can beat Rust or other language, but if you need something that starts instantly (like CLI utilities) Java is a no-go.

Maybe I'm in a bubble, but to me this sounds like Java would have faster performance in nearly all professional development situations. Very few people are writing CLI tools compared to those writing server code.

My other languages generally used are Python and TypeScript of which it absolutely is faster. I don't write Java anymore, generally speaking, so it could be faster, but it has its own problems, such as having null pointers and exceptions.

Me too. I also do this with .unwrap() - when I'm pretty sure of the happy path - while I'm prototyping. It's pretty easy afterwards to run back through and replace .unwrap() calls with better error handling. But as I improve, I'm getting more in the habit of using matching directly. Understanding lifetimes is probably really helpful for understanding library errors though and I need to go deeper there for sure

This is what I love about Rust, and other languages with these kinds of constructs. You have to acknowledge that something might e.g. fail. You can choose to do "nothing" (e.g. unwrap), but it must be done explicitly, which makes the ignored cases simple to identify later

I used to use OCaml before using Rust, it was similarly great and it's where Rust got the notion of the Option and Result types.

.unwrap() is the new // TODO:

for better or worse...

I found prototyping with `anyhow` really easy then I can convert to `thiserror` if I'm not interested in the boxing.

Another technique for dodging [manual] lifetimes is not store references in struct fields etc.

Reply on news.ycombinator.com