News for hackers. Stuff that matters.
Re:Rust – Faster compilation with the parallel front-end in ... by zeroxfe on Friday November 10, 2023 @10:45AM (#38220267)
> It’s not really that go is better designed for fast compilation

One of the explicit goals, by Go's creators, was fast build times. I still remember Rob Pike introducing Go during an all-hands at Google, where he talked about the very long build times for C++ and Java in Google's monorepo, and then showed some promising demos. (Most of us rolled our eyes at it then, because it was just a "hello world", but it's quite impressive how the language has evolved and remained true to its goals.)

> - it is just a plain language where the compiler can just spit out vaguely optimized code, and call it a day.

It's a simple language, but I wouldn't call it plain, nor characterize the optimizers that way.

Re:Rust – Faster compilation with the parallel front-end in ... by kaba0 on Friday November 10, 2023 @10:54AM (#38220390)
It is not faster at compilation than Java, which was not particularly designed for such.

Also, as can be seen, go is not a well-designed language, having language warts we knew for 50 years. I would take the creators’ claims with a huge grain of salt.

Re:Rust – Faster compilation with the parallel front-end in ... by rayiner on Friday November 10, 2023 @11:20AM (#38220714)
But Java is inspired by Smalltalk, which is a late-binding language that defers most things to runtime. I believe in Java you can generate bytecode directly as you’re parsing the source file.
[dead]
Re:Rust – Faster compilation with the parallel front-end in ... by kaba0 on Friday November 10, 2023 @11:14AM (#38220642)
So which of my statements do you take issue with?

I do think highly of Rob Pike and Ken Thompson for their IT work, but they are simply not good at language design, which just shows that PL design is quite unlike working on an OS.

Re:Rust – Faster compilation with the parallel front-end in ... by mariusor on Friday November 10, 2023 @11:28AM (#38220828)
Both statements, because unless otherwise qualified you're comparing apples to oranges when you say Java compiles as fast as Go. There's always going to be more overhead on running the Java bytecode on the JVM than there will be when running the native instructions generated by a compiler (even as "unoptimized" as Go is).

And someone that makes that assertion with a straight face without this caveat is not someone that should be dissing Rob Pike about language design.

Re:Rust – Faster compilation with the parallel front-end in ... by riku_iki on Friday November 10, 2023 @12:26PM (#38221674)
> It is not faster at compilation than Java

why do you think so? Their goal was to be much faster, but I can't find much benchmarks..

Re:Rust – Faster compilation with the parallel front-end in ... by Mawr on Friday November 10, 2023 @05:15PM (#38225272)
Java is compiled to bytecode, for later compilation to machine code at runtime (JIT). Go is compiled AOT, straight to machine code. It makes no sense to compare them.

Unless you meant that Java's AOT compilation is faster than Go's?

Re:Rust – Faster compilation with the parallel front-end in ... by kaba0 on Saturday November 11, 2023 @02:26AM (#38228272)
The parent comment explicitly mentioned that Java is slow at compilation, which is just false.

Also, there are single-pass compilers that produce machine code, they are not fundamentally slower than a byte code generator. Of course extensive optimizations will be more expensive.