Hacker News Reader

Comment by old-gregg | Hacker News Reader

As much as I like Golang, it is not a replacement for C. The major reason C is so popular because it's the only portable medium for performant code which can be shared across many languages because it doesn't impose any runtime on you.

Go comes with a VM. It lives in its own world, it cannot live in the worlds of other VMs like C can. It's more like high-performance Python (or simpler+slower C++) optimized for concurrent network services.

I'd say that Rust and probably D are good candidates for replacing C.

View on HN

The greatest trick libc ever pulled was convincing the world it didn't exist.

Isn't libc just a set of libraries and therefore not considered a runtime environment? C does have a small runtime environment, but I'd say it's the existence of the function call stack, as well as the on_exit system that's built into the core language.

On Windows it's even called "Microsoft Visual C Run-Time" (MSVCRT): http://en.wikipedia.org/wiki/Windows_library_files#Msvcrt.dl...

As well as things like floating point and large integer emulation, startup code, etc. __divdi3, for example, divides 64 bit integers on i386.

See /usr/lib/x86_64-linux-gnu/{crt1.o,crti.o,crtn.o,gcrt1.o,Mcrt1.o,Srct1.o}.

Well, it's so small compared to "real" runtimes, it might as well not exist.

I think your parent comment means runtimes in the sense of a garbage collector or other services that run concurrently with user code or are scheduled periodically, which will put you in a world of hurt if you touch one of their objects without asking its permissions and/or playing by its rules.

You can compile C code without a libc.

Currently, Rust cannot go without its runtime either. The plan is that it eventually will be able to.

(EDIT: VM -> runtime)

The plan is that it eventually will be able to.

To expand upon that point, Rust is designed to allow the programmer to avoid garbage collection altogether, if the programmer chooses. I believe that makes feasible the idea of using a runtime-less subset of Rust in any application where C would have been traditionally used.

Yes, you can use a freestanding Rust in many domains. Freestanding is still a WIP, but we have examples like embedding Rust in Ruby that work today:

http://brson.github.com/2013/03/10/embedding-rust-in-ruby/

Neither Go nor Rust have a VM.

Yes, I meant 'runtime.' That's what I get for commenting without coffee... the parent's usage of 'VM' infected my comment.

Go doesn't come with a VM, it comes with a runtime. Go code compiles to native machine code.

So does Haskell via GHC, that makes very little difference to the point being made.

The only language that does not have a runtime is called Assembly.

And even in the case of CISC processors there might be microcode playing the role of a runtime.

Why don't people learn about compiler design nowadays?!

>The only language that does not have a runtime is called Assembly. And even in the case of CISC processors there might be microcode playing the role of a runtime. Why don't people learn about compiler design nowadays?!

Because the C kind of runtime isn't what people regularly mean with the word "runtime" -- much less cpu microcode.

That said, does Forth have a runtime?

> That said, does Forth have a runtime?

It depends if you mean one of those Forth CPUs there were common in the 80's or the more standard Forth environment, both of which have nontheless runtimes.

Because in the end, you will be using a set of words besides the basic stack manipulation ones, those words are the runtime.

In one sense, Assembly does have a runtime, provided by the kernel's system call interface, not to mention all the magic that the loader has to do to make libraries work.

Even the kernel has a runtime, in a less strict sense, provided by the BIOS and whatever CPU interrupts support it.

The only thing that a program can do without any "runtime" at all is warm up your desk.

> The only thing that a program can do without any "runtime" at all is warm up your desk.

+1 Funny

Vala?

I wish the Vala folks would get going. 18 months ago, Vala, Go, and Rust were all possible native language successors to C++. (D was the fourth prospect.) But Vala has advanced so little, it's becoming an afterthought.

The web site is an afterhought that sits like an interloper on the GNOME site. The Windows distros are years old, etc. It's too bad. They had a good idea; they just failed to execute.

I agree. People mistake the fact "Some C people really like Go, for some of the same reasons they like C" for the falsehood "Go is a good candidate to replace C in the domains C it typically best for".

Reply on news.ycombinator.com