Why Rust and Go are both dead-end languages ... | Hacker News Reader

Why Rust and Go are both dead-end languages ...

5 pointseriksank6 comments

C code is very often called from scripting engines. This phenomenon started almost immediately when the first shell scripts appeared, chaining C programs.

It only became more prevalent with scripting popularity (Javascript, Ruby, Perl, PHP, Lua, and so on) going through the roof.

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.

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.

Since you cannot call Rust -or Go code from a scripting engine, they are inadvertently positioning themselves as alternatives for the scripting engines themselves.

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.

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.

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.

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 :/.

I always saw Go as a replacement for Java.

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

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.

>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.

Reply on news.ycombinator.com