
Why Rust and Go are both dead-end languages ... - eriksank
C code is very often called from scripting engines. This phenomenon started almost immediately when the first shell scripts appeared, chaining C programs.<p>It only became more prevalent with scripting popularity (Javascript, Ruby, Perl, PHP, Lua, and so on) going through the roof.<p>Therefore, any language that aims to replace C will need to be able to carry its APIs over the C ABI. It must be possible for any contender to be called from C code, because that is what it takes to be called from a modern scripting engine too.<p>The Go language is pretty much incapable of doing this: http://stackoverflow.com/questions/6125683/call-go-functions-from-c and Rust is also a disaster in this respect: https://github.com/mozilla/rust/issues/1732.<p>Since you cannot call Rust -or Go code from a scripting engine, they are inadvertently positioning themselves as alternatives for the scripting engines themselves.<p>Go and Rust, however, do not stand a chance when trying to position themselves an alternative to scripting too. This explains why neither Go nor Rust, in their current incarnations, will ever take off as replacements for C.
======
rartichoke
You're linking to a thread that's a year and half old. I'm actually in the
process of learning Go and if you pay attention to what the language
developers want to do with the language you would have known that embedding Go
into C or any other language's apps is a priority to them.

There's a Youtube video where the main guys are on stage answering questions
for an hour from a few months ago. They have plans to allow what you want and
there are also hacky (but fully working) ways to do it now.

Also keep in mind that the problem is only 1 way. You can embed C into Go
right now without issues. There's something about the Go runtime that requires
it to be executed from its own main() function, that is what they are working
on changing, but you can do things atm to get around that. I don't know the
details because it isn't something I'm doing.

------
qznc
Then use D ;)

If you write a function in D with extern(C) like this:

    
    
      extern(C) int add(int a, int b) { return a + b; }
    

it uses C calling conventions, so it can just be linked with C.

~~~
Executor
I wish D was more popular. Only reason I'm not using is because it isn't a
popular language. Same reason I'm not using Go :/.

------
unimpressive
I always saw Go as a replacement for Java.

I have no idea what Rust is. (Trying to be.)

------
tree_of_item
This isn't a very compelling argument. You can communicate over a port,
instead of through shared memory.

The "scripting" dichotomy is also an antiquated, flawed perspective.

------
pretoriusB
> _Since you cannot call Rust -or Go code from a scripting engine_

This is wrong for Rust. It already allows for that, specifically calling Rust
from C (and vice versa):

<https://github.com/mozilla/rust/issues/1732>

Not that is a compelling argument even if it was right. There are lots of ways
to make bridges to compiled code, besides using the C ABI.

