Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It claims C has the fastest build/run cycle. Is this true? Many non-compiled languages I can redefine my functions at runtime, and with Java I can hotswap.


I don't think it's true. Back in the day Pascal was known for a fast compile, single pass compile was a major selling point for Borland's Turbo Pascal. I don't know if a single pass C compiler ever existed but current C compilers use multiples passes (in addition to preprocessing). As far as I remember C was always known for a slow turn around cycle compared to other languages.


Borland used to tout the virtues of their single-pass C/C++ compiler too, even as far back as version 2.0.

Most modern C compilers have used an integrated preprocessor for quite some time, and Clang/LLVM can emit machine code directly without going through a separate assembler.


VB is actually faster to compile than C# and probably a lot of other languages. Not very used now but VB.NET works well in a .NET environment.


go has a very, very fast build cycle, partly due to the language and partly due to conventions (the standard preprocessor in C is absent in go). But, that might not have been on Damien's radar when he wrote this.

And, go is built by some of the same people who built C for some of the same purposes (plus some new ones, like concurrency and networks), so it's arguably a "better C", and probably prioritizes some of the same goals. Simplicity and small surface core language area, in particular, but removes some of the dangerous aspects of C (which might be a problem for something performance-oriented, since well-written C is still faster than well-written go for most tasks, and may always be).

But, as you note, if you don't have to build, the cycle is even faster. I still consider a compile phase a slowdown over dynamic languages that don't compile.

Then again, so many people have introduced "compile" like stages into their dynamic process (SASS, LESS, test coverage checks, etc.). It may be difficult to completely get away from a compile like stage in any app of significant size.

Anyway, a large project in go is faster to compile than a large project in C, in my experience, but my experience is exceedingly limited.


I don't see why people keep calling Go a better C. Most of the C programmers I know use it because they want manual memory management which Go doesn't have.


Go has the fastest build/run cycle I've seen. You can usually compile compile to a binary and run it quicker than it takes a python runtime to start up. It's totally viable to use Go as a scripting language while compiling to binaries from source.


I mostly work in Python but I had a similar scripting-like experience during my Go project -- with a small codebase, the time it spent compiling was barely perceivable, if at all. Very impressive, and shows you what's possible.

Semi-relatedly, the downvoting around here has gotten completely out of control. It's sad, what's happened to HN.


You may have a very long python-path and/or script loading a lot of modules initially if it is taking so long to start up.

For example, in a recent script I deferred loading the requests module and startup improved a few tenths of a second. Rinse, repeat.


I'm guessing you've never used Lisp/Slime?


> build/run cycle

> non-compiled language

C isn't trying to fit in that space. regardless, C code takes far less time to parse, optimise, and convert into machine code than all the languages i know of.


Nope. Pascal is still king here. The speed it compiles at is simply ridiculous. Largely this is because the way the modules are defined makes it a snap to pre-compile aggressively. You're simply not allowed to do things that would change the way a module is understood by the compiler based on context.

The biggest hold-up in the C world is rampant abuse of #include files.


Yea, change a certain .h file and you can go get a cup of coffee while waiting for the build to end. This can't ever happen with Java/C#.


Turbo Pascal is (was?) king here.

It's possible to make slow Pascal compilers. But Borland put a lot of effort into that, and it really set a very high standard.


> The biggest hold-up in the C world is rampant abuse of #include files.

true.

> Nope. Pascal is still king here.

for some values of "king" perhaps - perhaps it's faster to compile, but no arrays of varying lengths in a function call? and if i'm not mistake, a function must be defined before use..? pascal is incredibly restrictive, and perhaps that's why it's so fast.


It's very restrictive, but the compiler is unbelievably fast because of that.

I'm not going to argue that Pascal is somehow superior to C, it's far more limited, but there's lessons here to be learned on how to make a compiler rip through code.


Only if speaking of original Pascal, neither Extended Pascal nor Object Pascal suffer from those limitations.

When I learned C, after a few years of Pascal dialects C just felt like a stone age language.


> for some values of "king" perhaps - perhaps it's faster to compile, but no arrays of varying ...

Well, let's not change the goalpost - your initial assertion was that C has faster compile times. Then chances are that something's got to give, whether that is in the grammar, declaration order, etc.


Doesn't Forth compile incredibly fast?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: