Hacker News Reader

Comment by melling | Hacker News Reader

“Besides strict typing and having a generally ugly syntax, C++ also requires ahead of time compilation.”

What’s wrong with strict typing and ahead of time compilation as long as it compiles fast? Doesn’t this prevent many runtime errors that can occur in Python?

Python is a higher level language than C++ so it requires less effort but newer compiled/typed languages offer more of what Python is good at

View on HN

> What’s wrong with strict typing and ahead of time compilation as long as it compiles fast? Doesn’t this prevent many runtime errors that can occur in Python?

Nothing, as long as the compilation is fast. C++ compilation is not fast. The large C++ projects I've worked on over the last few years, compilation is bordering on 2 hours for a full build, and 10-60s for incremental builds. At one point, incremental changes were taking 15 minutes to link at one point (resolved by [0]). Go is a great example of fast compilation and strict typing IMO.

[0] https://devblogs.microsoft.com/cppblog/improved-linker-funda...

Go was designed, in part, as a response to C++'s slow compile speeds. The Go compiler has gotten a bit slower over the years, but it's still pretty fast, especially when compared to C++ or Rust.

> In 2007, build engineers at Google instrumented the compilation of a major Google binary. The file contained about two thousand files that, if simply concatenated together, totaled 4.2 megabytes. By the time the #includes had been expanded, over 8 gigabytes were being delivered to the input of the compiler, a blow-up of 2000 bytes for every C++ source byte.

https://go.dev/talks/2012/splash.article#TOC_5.

I also hate how just adding some definition to a .h file that's only referenced in one .c (or .cpp) file will recompile loads just because the header file changed. Maybe there's ways to improve on that (ccache?), but I mostly write C to contribute to open source projects (rather than my own) and it can be an annoying wait.

You can limit the impact of this with forward declarations and only putting that is needed for the public API into the header includes. The rest can all live in the .cpp

C++ (especially template heavy with lots of headers and so on) is certainly not fast to compile. But 2 hours that's crazy. What sort of codebase and on what kind of machine?

A 128 cores threadripper is a great workstation to compile C++ code fast :D

Chromium is known for taking hours.

More like an hour or less on reasonable, consumer hardware[1]. A lot less on workstation/server CPUs, or with IncrediBuild.

[1] https://youtu.be/nRaJXZMOMPU?t=770

Most people will use ccache under Unixen.

And for those of us who work primarily with MSVC?

I am on Gentoo so I have some build time stats!

My system has a 3900x, 32GB ram, and a fast NVME SSD for reference.

The last chromium build took 1h:45m to complete. This build had LTO enabled and -j18 passed to ninja.

Without LTO it would probably be closer to an hour I think but I don't seem to have a non-LTO build in the logs.

Your estimation seems pretty accurate!

That is true. But Chromium is not in the realm in which the compiled vs. interpreted debate is relevant. It is slow to compile, but it would also be very slow to run if it was written in Python.

(Unless a hypothetical Node.js rewrite would be comparable on speed. I wonder how it would do on memory.)

For reference Unreal Engine 5 full build (building a lot of stuff you don't need) takes like 30 minutes on a 3950x. Typical incremental build is either 15 seconds, or a minute if I touch some popular header. For full build not only you can have a lot more cores, you can use IncrediBuild.

In my experience, a large Unreal Game can take as long as the engine on top of it. My current project is about 2 minutes of project code plus 15 minutes of engine code but my last project was more project code than engine code.

Unreal engine games, on a 3990x Threadripper with 128GB ram and NVMe SSD drives.

> Go is a great example of fast compilation and strict typing IMO.

I think an even better example might be OCaml. Ocaml's compilation speed (last time I checked) was on par with Go, but it provides a much nicer (IMO) type system.

OCaml is another example of fast compilation and static typing.

I have worked with very few C++ projects that compile fast, and my experience is that the errors in C++ projects are often more severe than the errors in Python projects. Even with modern C++ smart pointer style, I’ve seen all sorts of stuff like dangling pointers / use-after-free, buffer overruns, etc. All in code that had been reviewed.

Yes, C++ was created in the 1980’s and a lot had been added …

That’s why I was suggesting newer compiled languages incorporating some of what we’ve learned over the past 4 decades. eg type inference

In general, the more work the type system is doing for you, the slower the compilation speed. Kotlin and Scala, for instance, both compile far more slowly than Java. I think even C# compiles very slowly compared to Java. You mention type inference, but type inference actually slows down compilation, and the more sophisticated the type inference, the slower the compilation!

Similarly, Rust compilation speed is much slower than GoLang's, whose type system does relatively very little for you. I haven't seen exact numbers, but I've seen people say Rust and C++ have similar compilation speeds, and both are, in general, slow to compile.

Rust gives you so much more for the same compilation speed though.

Try any larger Swift project and suddenly C++ looks pretty fast. Agreed on the pointers though.

In my experience a good pipeline with decent unit tests makes c++ and python work fine.

And Valgrind (and / or Memory Sanitizer), they mostly remove a big source of problems in C++ code.

>Python is a higher level language than C++ so it requires less effort but newer compiled/typed languages offer more of what Python is good at

I see Nim as clearly better if you write a larger software. It's a shame it's usage is low and thus there aren't many Nim resources.

I think Nim is best placed as the choice for the fast functional core performance-critical and cpu-bound few parts of a larger python codebase.

I see a strong convergence of typed / fast / expressive languages between python/php/ruby and cpp/ada. Rust is one trendy instance but I believe it's gonna create a spot around it.

> What’s wrong with strict typing and ahead of time compilation as long as it compiles fast? Doesn’t this prevent many runtime errors that can occur in Python?

Nothing, it's all good things: It's easier to write, easier to debug, and the compiler (not the user) catches bugs.

C++ compilation is anything but fast.

Reply on news.ycombinator.com