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

Rust is Not so Hairy

nevi.me

Post reply on HN
Print view View original

31–36 of 36 posts

Re: Rust is Not so Hairy

#31

Post by pjmlp »

geezerjay wrote: post #28
pjmlp wrote: post #20

Earlier quoted context omitted.

> What makes Rust, like C or C++, efficient is not just that they are statically compiled, it's that they have massively-tuned optimizing compiler spending a lot of time in compile-time optimizations. Actually lots of money spend across compiler vendors in the last 30 years, and UB abuse, as C compilers were pretty lame in the early 80's.

> UB abuse That baseless assertion makes no sense. UB is a property of the ISO standard and has no effect on how compiler vendors implement the language. In fact, UB is intended to enable vendors to be free to choose how they implement that behavior. So why do you believe that the freedom to pick how you implement something hinders any development effort?

I don't know, maybe the daily CVE reports including some Linux exploits, in spite of the kernel review process and static analyzers?

Re: Rust is Not so Hairy

#32

Post by Accipitriform »

littlestymaar wrote: post #12
jokoon wrote: post #4

Good performance is not surprising, it's a statically compiled language.

Being “statically-compiled” isn't some magic property that automatically makes program run faster. It can even be the opposite in some situations, since you can't benefit from JIT optimizations. What makes Rust, like C or C++, efficient is not just that they are statically compiled, it's that they have massively-tuned optimizing compiler spending a lot of time in compile-time optimizations. If you take Go, another st…

> What makes Rust, like C or C++, efficient is not just that they are statically compiled, it's that they have massively-tuned optimizing compiler spending a lot of time in compile-time optimizations.

Consider that javac and the Java runtime have received plenty of resources and development time (since 1995 or so!).

The overhyped claim in the early days of Java was that it would be "faster than C" due to JIT optimizations. That has certainly turned out to not be the case. Further, Java and all the other managed languages (to include the CLR languages) remain unsuitable for real time applications due to GC pauses.

As this article points out, memory consumption for JVM based systems is also usually vastly higher than for C/C++/Rust/Ada.

C++ in particular has been a dumpster fire of a language, and IMO has set the industry back considerably. It's good to see Rust and a few other languages providing much better alternatives in the same space - languages suitable for lean, real time, high performance applications.

Re: Rust is Not so Hairy

#33

Post by msla »

pjmlp wrote: post #10
diroussel wrote: post #7

Earlier quoted context omitted.

Java is not statically compiles to machine code. It’s statically compiles to byte code which is hen interpreted or dynamically compiles to machine code. So to way java is statically compiles is not quite correct in my opinion.

If you are talking about free Java compilers that is correct. Most commercial compilers, specially those for embedded markets always had AOT native code as deployment option. But now the bad Oracle is finally making the AOT compiler research they got from Sun Labs available for free.

At least one free Java compiler compiles to machine code: gcj.

https://gcc.gnu.org/wiki/GCJ

Re: Rust is Not so Hairy

#34

Post by pjmlp »

msla wrote: post #33
pjmlp wrote: post #10

Earlier quoted context omitted.

If you are talking about free Java compilers that is correct. Most commercial compilers, specially those for embedded markets always had AOT native code as deployment option. But now the bad Oracle is finally making the AOT compiler research they got from Sun Labs available for free.

At least one free Java compiler compiles to machine code: gcj. https://gcc.gnu.org/wiki/GCJ

Yes, but it sadly died around 2009 when most developers left the project.

GCC devs just kept it around because of the unit tests, but with GCC 7 they removed it from the distribution.

Re: Rust is Not so Hairy

#35

Post by blackrock »

// Mutable pointer to the field.

// If field is not initialized, it is initialized with default value first.

pub fn mut_message(&mut self) -> &mut ::std::string::String {

        &mut self.message
}

=========

Geez, this is ugly.

And here's another..

=========

// Take field

pub fn take_message(&mut self) -> ::std::string::String {

        ::std::mem::replace(&mut self.message, ::std::string::String::new())

}

Re: Rust is Not so Hairy

#36

Post by kaixi »

nevi-me wrote: post #22
nazka wrote: post #21

Earlier quoted context omitted.

Nice post. I will be really curious to see the same microservice done with Go and compare all of them.

My Go is very basic, but I can follow up with a Go impl and compare it with Rust. The code shouldn't take an experienced Go programmer more than an hour, as it's mainly mapping gRPC calls to Redis calls.

Please do. I'm interested as well.
Post reply on HN