
Which language has the brightest future for replacing C: D, Go, Rust? - sidcool
https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Andrei-Alexandrescu?share=1
======
jasode
Well, one of those things is not like the others.

Golang competes more with gc languages/runtimes like Python/Ruby/Nodejs. To a
lesser extent it may compete with Java JVM. (However at this point in time,
the JVM GC technology is still far ahead of Go's GC.) If one is writing a
networkish service such as REST API endpoint, Golang's combination of language
featurs & quality libraries (http) is positioned very well for that. Go isn't
suited for system drivers or tight loops that depend on controlling exact
memory layouts. I've heard several times to think of Golang as a "DSL for
networking apps" and I think it's the best succinct soundbite for that
language.

That leaves D-minus-the-gc and Rust which Andrei Alexandrescu provided very
reasonable analysis. I don't think either will replace C. In 1995, many
predicted that Java would supplant C++ and that never happened. For the
performance domains that C++ was good at (e.g. AAA games, commercial software
like AutoCAD and MS Office), _it became even more entrenched._ In terms of
being forced to make bets, I'd say Rust has a better chance than D because
Rust has the momentum behind it that D never had.

~~~
odiroot
> Golang competes more with gc languages/runtimes like Python/Ruby/Nodejs.

I still cannot even grasp this trope. Seems like some try to apply "fake it
till you make it" approach.

To me, coming from Python and Node (and a bit Ruby) development it seems as a
completely opposite direction -- similar to going back to C++ or Java (where I
started myself).

If not for the quirky syntax and lack of generics I would personally pose it
as a replacement for the C++ itself.

Rust on the other hand seems to me to be the most promising out of these three
as a systems language.

~~~
jasode
_> I still cannot even grasp this trope. Seems like some try to apply "fake it
till you make it" approach._

It's not a fake trope. There are tons of blog posts from programmers
describing experiences of switching from Ruby+Rails to Go, or Python+Django to
Go, or Javscript+NodeJs to Go. Some defections were high profile such as
Nodejs uber-contributor TJ Holowaychuk switching to Go.

Compare that to virtually zero notable stories of C++ projects switching to
Go. If people are using C/C++, they very likely depend on it for the
performance characteristics and therefore switching to Go to suffer a speed
penalty makes no sense. On the other hand, people leaving Python/Ruby report
performance gains. That's why the reality on the ground looks the way it does.

~~~
cbr

        Compare that to virtually zero notable stories of
        C++ projects switching to Go.
    

A lot of projects at Google have switched from C++ to Go, and the people I
know who work on them are pretty excited about working in Go. Here's a blog
post by a coworker who leads the Chrome Data Compression Proxy project:

[http://matt-welsh.blogspot.co.uk/2013/08/rewriting-large-pro...](http://matt-
welsh.blogspot.co.uk/2013/08/rewriting-large-production-system-in-go.html)

~~~
jasode
Thanks for the example. I think your coworkers' rewrite further reinforces the
"sweet spot" for Go.

The transcoding was left as C++ but the other stuff including the networking
was rewritten in Go. That makes sense to me because transcoding is performance
intensive and cpu-bound instead of io-bound. (E.g. CPUs pegged at 100% while
bytes being read at a slow 10MB/sec.) In other words, if people tried to
rewrite ffmpeg in Golang, a conversion job such as avi to mp4 would run
slower.

If Google's internal cpu-bound projects switched from C++ to Golang, that
would be a very interesting data point. In other words, I don't expect Google
would switch their machine-learning algorithms scanning petabytes of data from
C++ to Go (or create greenfield machine learning projects using Go instead of
C++).

------
hellofunk
> Given C++'s age, I'll assume in the following that the question also puts
> C++ alongside with C as a target for replacement.

Yes, C++ is old, but it has really stayed with the times in an impressive way.
The so-called "Modern C++" that started with C++11 is a significantly
different way of writing C++. All the things that made C++ infamously
challenging and allowed inexperienced developers to leak memory and cause
crashes, are, for the _most_ part, no longer in the normal C++ workflow.

And all the rage about functional programming, passing around functions as
values, writing closures that capture and encapsulate their surrounding
values, using map, filter, reduce algorithms, relying on type inference,
forgetting about pointer deletion and manual memory management and avoiding
the access out of bounds memory on iterations -- that is all normal C++ now.

If anything has or will successfully replace C++, it is going to be C++
itself. The standards committee and community are doing an extraordinary job
of keeping the language current while maintaining its great reputation for
speed.

~~~
jernfrost
C++11 in no way solves the fundamental problem of C++. C++ is too big and has
too much baggage. There are too many corner cases and oddball stuff to deal
with. Being a good C++ developer requires unnecessary amounts of training.

C++11 can't remove what is already there and so one just keeps piling on more
stuff increasing the complexity.

I am actually sad C++11 happened because it keeps alive a language that should
have died years ago.

I've worked years on projects where so many of the fundamental problems can be
traced back to the usage of C++. Huge amount of legacy code which can't safely
be refactored because C++ is just too complex a language for a refactoring
tool to be able to deal with properly. Insane compile times. Odd hard to track
down problems from static initialization and deinitialization. Templates are
impossible to use in a sane way because they mix so poorly with regular OOP in
C++ and increase compile times too much to be practical.

Move a project like that gradually away from C++ is a huge undertaking and
nobody is going to support it as long as C++ keeps updating self to not be
completely behind the times.

~~~
hellofunk
>There are too many corner cases and oddball stuff to deal with.

It seems like all the langauges I've used, from objective-c to swift and
Clojure require you to keep certain aspects of the language in mind for
certain situations that don't on the surface seem obvious. Purity in any
language is quite rare.

In the case of C++, it is possible to ignore much of that old baggage most or
maybe even all of the time if you write new code using new features. I agree
that those maintaining much older codebases are going to have a rough time,
but is not an uncommon problem in many languages.

Also, even in a so-called "better" language you can run into massive
refactoring projects with older code once you choose to adopt new libraries
and tools. As Bjarne says, C++11 is much better, C++14 will be even better,
and C++17 is further going to be better... frankly, this is a good path for
any language to be on.

~~~
jernfrost
I don't think purity is the problem. I just think simplicity has value. It
makes it possible to keep most of a language in your head. It makes it
possible for anybody on your team to have a chance of understanding your code.

There was a time I tried to embrace modern C++. Problem is C++ is so big that
there will always be lots of people who don't understand the code you are
writing. I used to have tech talks to explain concepts like C++ concepts,
models and how it relates to STL containers, iterators etc. But ultimately all
these efforts is just putting bandaid on a shitty language.

The whole point of programming languages is so people can exchange code and
understand each others code. C++ is epic fail in this area.

While Objective-C is also a kind of old and crufty language, it is infinitely
simpler than C++.

Maintaining old codebases in anything other than C++ is much simpler for many
reasons. Refactoring tools in languages like Java and C# actually works.
Refactoring in Ruby or Python is simpler because they more naturally decouple
due to their dynamic typing.

Refactoring C++ code is hell on earth because the refactoring tool has to be
able to understand macros, C++ templates etc. Any changes to a class interface
even private methods or variables requires recompile of all files using that
class. Which means doing lots of changes means recompile of lots of files.
Which sucks in a large project when C++ is terribly slow at compilation to
begin with.

Compare with a language like Go. The syntax is so much more sane that you can
actually write simple refactoring tools yourself easily. No way in hell you
can do that with C++.

No matter what Bjarne does with C++, they will still be stuck with macros, a
fiendishly complicated template system, static initialization and
deinitialization mess. As long as you need to remain backwards compatible you
are stuck with a lot of awful stuff.

~~~
hellofunk
>But ultimately all these efforts is just putting bandaid on a shitty
language.

Well, that's a highly subjective opinion. It sounds like C++ doesn't work for
_you_ but I still find it a fascinating and enjoyable language to work in.
There are drawbacks with any language, and I guess the drawbacks you find for
yourself in C++ are your business.

------
Argorak
First and foremost: this is a good and fair post.

I disagree with Alexanders (regular) narrative that Rust puts a lot of estate
into safe memory handling. Rusts memory management features may seem daunting
at first, but they make advanced things (like type-system assisted data
sharing) a breeze. So, while the whole "let's talk about data"-aspect of the
language _does_ take a lot of estate, it goes far beyond "let's talk about
memory".

I agree though that this is a property that comes rather late in learning the
language and we still struggle to communicate that easily.

------
aprdm
Replacing C? Not gonna happen anytime soon... I think C is a beautiful
language and is probably one of the languages with more lines of code in the
history, hugely used even today and the still the best for a good amount o
scenarios.

Long live C!

~~~
jernfrost
From what I understand Cobol and Fortran still leads in number of lines. So
much scientific software: weather simulations, military simulations is still
in Fortran and Cobol runs at the core of so many banks. In my home country
Norway you used to be able to download the code that was used to calculate
your taxes (might still be possible but haven't tried in years). That code was
all Cobol. So I suspect a lot of government stuff is also Cobol.

I am quite fond of C as well, but you know there are quite a lot of other nice
languages out there as well. Since I started writing Swift, e.g. I haven't
felt much need for C for anything anymore.

A problem for me jumping to C#, Java etc is that those are managed languages
with very different set of tools and thinking. As a long time C/C++ developer,
Swift feels much more natural as the tools, compile process and thinking is
much more similar.

And Go has a very similar feel to C. When you read Go code it has much of the
same simplicity and straightforwardness about it as C code. Even if I don't
write much Go code I often read Go code to understand how things work, e.g.
HTTP code, encryption stuff etc. Much easier to read the Go code than the C
code or anything else really.

~~~
aprdm
How does Swift do for embedded systems? Most of the processors in the world
are not the usual PC, they are embedded systems. 99% of the embedded systems
shop use C! There are still loads of 8 bits microcontrollers being sold every
day and they aren't going anywhere anytime soon.

But I do agree with you, I am a web developer today and use Python, C doesn't
fit too well in this space.

~~~
jernfrost
I've worked AVR microprocessors (used in Arduino) and I found that for as
small programs as I would write on a micro controller even assembly
programming works. But C is definitely a good fit. Since you need effortless
access to many low level details I think C is probably the best language for
writing micro controller software. Of course as the software gets larger I
guess it start making more sense to switch to something like Swift or Rust.

The right tool for the job right? C is the right choice in many cases. It is
just that C/C++ has been used for a lot more jobs than they are the right
choice for.

------
SandB0x
What a fantastic, thoughtful post. If anyone is skipping to the comments here
based on the title, you should read the article, not least because it's by
Andrei Alexandrescu.

~~~
fithisux
D is my favorite. My problem is lack of IDEs and I do not count Visual D as
one of them since it requires Visual Studio which is heavy and not
crossplatform.. If they could go with Visual Studio Code (when it matures) or
KomodoEdit which are cross-platform and free (bias on KomodoEdit) I would be
all for that.

Until then I put my bet on Mono-D and DDT.

In any case, this month is the D month for me. Enough is enough with C++ and I
am thankful to them because they made an amazing replacement.

~~~
Zardoz84
Visual Studio 2015 Community edition it's far more lightweight that for
example Eclipse.

I just re-attach to D for doing some stuff, and I found that DUB and VisualD
just works very fine. And I'm a guy that in 75% of my time running on a
GNU/Linux...

------
DeveloperExtras
I love to do C programming. C++ in comparison, I don't enjoy at all. I think
it's the syntax. C# and VB.net are fun, and fast to work in. Obviously just my
opinions of course. Java is fun and fast.

With C and even Objective-C, I have to plan everything out, and finely craft
the code. It's meant to be closely examined and optimized and perfected.
That's what makes it rock-solid in my experience.

I don't have type-related or buffer or memory related issues since its part of
developing in the language. Things like Heartbleed are interesting, because
obviously the guy was overworked and didn't spend enough time with the code
before checking it in.

I view those types of issues as 'check-in irresponsibility' and it can occur
with any language, not just C. My answer would be 'None of the above'.

------
flashm
Why does anything need to replace C? It's been fine for years and still does
exactly what it needs to do.

~~~
xenadu02
You're right. It keeps on giving us heartbleed, slammer, sasser, kernel null
check eliding holes, and literally thousands upon thousands of other memory
exploiting, remote executing, security breaking bugs.

But I'm sure, Real Soon Now(TM), if teams just adopt (best practices / better
libraries / better code reviews / better static analysis tools / better
testing) all those problems will be solved and C will be a great language to
keep using.

After all, saving a few extra CPU cycles is totally worth breaking all SSL
encryption and leaking private keys, quite literally putting the security of
EVERY SINGLE FUCKING HUMAN WHO HAS EVER TOUCHED THE INTERNET in jeopardy.

So sure, let's just keep using C. It's fine, why change anything amirite?

(Sarcasm aside: In the general case it is not possible for humans to write
security-critical code in C. So far the history of the internet has proven me
100% correct.)

~~~
srj
What other language would someone use to write a kernel or driver? Even if you
use a higher-level language for most of the logic you'll likely want the core
to be C -- amazing considering the language is nearly 40 years old. C is, to
me, a systems programming language. Writing code that handles any significant
amount of user input in the language is a mistake I believe. Note that this
doesn't include C++ which has more modern constructs.

~~~
mpweiher
You might be surprised that NeXTStep used Objective-C for device drivers in
the kernel.

~~~
jernfrost
That is pretty cool. Shows some of the versatility of Objective-C. I was also
surprised that a low level API like Metal also uses Objective-C.

------
kbart
I'd bet my money that C will outlive them all.

~~~
blueflow
Yes. C has the lowest abstraction depth without going into platform-specific
details like asm. LLVM is the only thing that could compete with C on that
level.

~~~
yazaddaruvala
You probably know already, but just for anyone that doesn't, Rust uses LLVM to
compile its machine code.

~~~
blueflow
Properties of an language are not necessarily inherited when compiled. LLVM
Code is not bound to Rust's memory access restrictions.

~~~
kibwen
The Rust developers specifically tailor the compiler to generate LLVM IR that
resembles Clang's generated LLVM IR.

------
fithisux
It would be more accurate to say C++ and not C. C is here to stay.

But the biggest question is not replacement but interoperability. Can I call
Rust code from Go? Can I call Go from Rust?

~~~
kibwen

      >  Can I call Rust code from Go?
    

Yep. Rust code can easily expose a C ABI, so any language that can call into C
(which is every language) can potentially call into Rust.

    
    
      > Can I call Go from Rust?
    

Go is working on exposing the ability to compile standalone libraries that can
be called from other languages. Support was spotty last I looked, but it
should be interesting to watch going forward.

------
merb
If Rust's syntax would be more close to other languages it would be the
dealbreaker.

I mean most simple things are easy to read. But once in a while you stumble
around code that nobody will understand if not every single character is well
documented.

Still somehow I love it.

------
raspasov
Clojure is the new C
[http://www.infoq.com/presentations/clojure-c](http://www.infoq.com/presentations/clojure-c)

~~~
weavie
Wow, that's probably one of the last things I would have thought of. I look
forward to listening to that.

~~~
progman
I agree when Clojure gets rid of the JVM dependency. The Java ecosystem is
nice but the annoying startup time of Clojure apps and the strange error
messages of the Clojure compiler are reasons why Nim has become my favorite.

------
vukmir
No language will replace C, but all of those mentioned will eat some of its
cake. Its usage will shrink, but C is here to stay.

D is what C++ should have been. It had some traction in mid-2000s but the
Tango vs. Phobos debacle killed it.

Go is the most serious of the three languages mentioned. It has the momentum,
solid community, solid tooling, and corporate backing. It's well suited for
networked services, but it is not replacement for C.

I'm not so sure about Rust. Unlike D and Go, Rust can replace C (in theory),
but I don't think that will happen. Rust has a feel of a hobbyist language in
perpetual alpha.

~~~
Zardoz84
> but the Tango vs. Phobos debacle killed it. It was D1 lang.

You should know now that D2 have single standard lib, the official compiler
front end is wrote on D, and open source. Plus there is LDC and GDC
implementations.

~~~
vukmir
I know, but it missed an opportunity to go big.

In early 2000s, Microsoft basically told Win32 API developers to either
migrate to .NET or to go fuck themselves. There was a lot of FUD flying
around. At one point, people were wondering will the new Visual Studio ship
with C/C++ compiler.

In it's quest to promote .NET, Microsoft even got Borland to kill itself by
jumping on the .NET train. The days of native Windows development were over
and the best alternative to MS stack, Borland with its Delphi, decided to
commit suicide.

That was the chance for D to shine. I was among the developers looking for
non-MS solution for native Windows development and D was my favorite, but the
Tango vs. Phobos thing killed it for me.

Like many developers at that time, I left Windows for the Web development. If
D was then what is now, I would stay with Windows a bit longer than I did.

------
gilgoomesh
The whole article is a little spurious. None of the languages mentioned (C,
C++, D, Go, Rust) target exactly the same space (even though they all
overlap).

Go and Rust in particular have been designed with very specific clients in
mind (replacing Google's use of Python for server-side work and safety-
paranoid multi-threading for Mozilla's Servo, respectively).

Rust is the only new language mentioned that resembles C in its capabilities
but then again: C++ resembles C in (theoretical) capabilities but never de-
throned C (mostly because when you use C++ like C, you might as well use C).

------
vruiz
> Reading any amount of Rust code evokes the joke "friends don't let friends
> skip leg day" and the comic imagery.

That could not have been more graphically enlightening.

------
jdmoreira
Nim for sure. Compiles to C and it's awesome.

~~~
quotemstr
The language known also as n_i_m and NiM?

~~~
progman
I was involved in programming from the very beginning (the time of KIM-1) and
I learned many programming languages, the major ones (C, C++, Java, Ada, Perl,
Python, ...) and also very exotic ones (Assembler, APL, Fortran, Prolog, Lisp,
...). No language was more productive for me than Nim. Ever. It's the ideal
"mix" of C, Python and Lisp with C++ native performance. Nim is really nice. I
wonder why it is still barely known.

[http://nim-lang.org](http://nim-lang.org)

[http://hookrace.net/blog/what-is-special-about-
nim/](http://hookrace.net/blog/what-is-special-about-nim/)

Uses Cases:

[https://github.com/nim-lang/Nim/wiki/Nim-use-cases](https://github.com/nim-
lang/Nim/wiki/Nim-use-cases)

Note that meanwhile there is also NimScript, an interpreter for a subset of
Nim, which can be used for shell scripts.

Nim for scientific computing:

[http://rnduja.github.io/2015/10/21/scientific-
nim/](http://rnduja.github.io/2015/10/21/scientific-nim/)

> The language known also as n_i_m and NiM?

[http://blog.codinghorror.com/the-case-for-case-
insensitivity...](http://blog.codinghorror.com/the-case-for-case-
insensitivity/)

I have no problem with that because this way everyone can use his favorite
notation. The only thing that strongly reject are strong spaces. That was a
silly idea and should be removed instantly.

~~~
Nrpf
What do you think about Julia?

~~~
progman
I have barely touched Julia and I am impressed by the performance. It could
become a real competitor to R.

Nim could also play a significant role because its syntax is similar to
Python, and because NumPy is a Python API which is very prominent among
scientists. However someone has yet to write a Nim library similar to NumPy.

Nim has the advantage of zero overhead to C, and it compiles to C which makes
Nim an interesting option for super computing.

~~~
quotemstr
> Nim has the advantage of zero overhead to C,

Untrue. Nim requires the use of a garbage collector.

~~~
progman
No. Counter example from
[http://learnxinyminutes.com/docs/nim/](http://learnxinyminutes.com/docs/nim/):

    
    
      # Because Nim compiles to C, FFI is easy:
    
      proc strcmp(a, b: cstring): cint {.importc: "strcmp", nodecl.}
    
      let cmp = strcmp("C?", "Easy!")

------
jernfrost
Different languages will probably replace different parts of C usage. I
suspect Go will replace C/C++ for high performance server side stuff like
databases and various server software. E.g. I've seen a bitcoin server being
written in Go. That is the sort of stuff that makes sense for Go I think.

However C is often used for writing libraries that can be used for many
languages. Think about OpenSSL e.g. I doubt C was chosen due to its
credentials as a secure language. Rather this is a liability for C/C++ in many
areas.

I think Rust will replace this. Actually I think Swift will be fighting with
Rust over some of the the same territory. They both got the same advantage of
not requiring a garbage collector and thus can be used to write libraries to
be used by any language through a C-API.

While Rust might have an edge language wise, Swift might be just good enough.
That matters because we are using C/C++ not so much due to the quality of
those languages but due to a combination of their feature set and existing
momentum.

Swift is more or less guaranteed to get big as it is replacing Objective-C for
iOS development rapidly. That will create a large user base for it quickly.
This will only accelerate when Swift goes open source and can be used on more
platforms.

Both D and Rust have a bit of a chicken and egg problem. People aren't going
to use those languages if people don't believe they have a future. They wont
have a future if people don't believe they have a future. Rust is novel and
cool enough in a geek perspective that I think it will gain enough momentum to
get some presence. D has been around for a long time without that happening so
there is no reason to believe it will happen now.

Swift has the chicken and egg problem solved. For writing something like
OpenSSL it would take away many potential problems. No accidentally not
executed code due to not using curly braces for if statements. No exploitable
buffer or integer overflows. No accidentally uninitialized variables. No
accidental switch-case fall through. No unintentional type conversions. A
whole host of memory bugs gone.

~~~
pjmlp
On OSes written in C, C benefits from OS ABI == C ABI, but it wasn't always
like that.

------
facepalm
Depressing to read. Somehow I can not find a language I really like :-(

~~~
yoodenvranx
I miss Delphi more and more. The language is ok-ish but when it comes to rapid
Gui development it still runs cires around everything else.

------
tmaly
For me the minimalism of the Go language, the quick learning curve, the great
standard library, and the ease of deployment make it a great choice. I hardly
ever need to code things in low level assembly, but I do need to revisit old
code frequently. The explicitness of Go makes it easy to work on coded you
have not touched in 6 months. I have not looked at D, and Rust is still pretty
new. I may give Rust a try in the future if I can find a project for it and I
have some time to learn it.

------
gonzo41
c++. Its not going away.

~~~
moonshinefe
The level of verbosity in modern C++ is almost approaching Java levels these
days. I could see a simpler language gain favour.

~~~
creshal
The beauty of C++ is that you can define an arbitrarily small subset of the
standard that work as simpler language of its own!

Too bad not two projects can agree _which_ subset.

~~~
DanWaterworth
Sounds like someone needs to rigorously define a good subset then write a tool
to verify that a program uses only that subset.

~~~
lucozade
As if by magic....

[https://isocpp.org/blog/2015/09/bjarne-stroustrup-
announces-...](https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-
cpp-core-guidelines)

~~~
bryanlarsen
Wow, that's huge. It's what everybody's doing anyway, but being standardized
with big names and heavy hitters behind it makes it much easier to advocate
and argue for.

Such an effort would be so much easier to advocate for in a C++ shop, and more
importantly, very difficult to argue against.

This deserves a proper HN discussion. I've resubmitted it, it missed the front
page the first time around:

[https://news.ycombinator.com/item?id=10545921](https://news.ycombinator.com/item?id=10545921)

(sorry for the karma stealing, lucozade totally deserves the karma if my
resubmission takes off)

------
oDot
While the post is fantastic in showing the pros/cons of the other languages,
it doesn't talk about the advantages of C, advantages to some people at least.
Here's Linus on replacing C:
[https://www.youtube.com/watch?v=MShbP3OpASA&t=20m45s](https://www.youtube.com/watch?v=MShbP3OpASA&t=20m45s)

------
avera
I think that C is completely fine; Language is relatively simple, and so can
be easily used/implemented anywhere. Any dynamic parts and GarbageCollection
can be provided by C libraries.

By using source-to-source compilers, C is a good target language.

From this standpoint, we can treat C as a "cross-architecture assembly
platform".

Simplicity is beautiful!

~~~
progman
Yes, simplicity is beautiful but C is not state of the art anymore. In
comparison to modern languages C is merely a high level assembler. Why fiddle
with C when you can use modern languages which can compile to C anyway?

~~~
avera
high level assembler - exactly!

------
avdicius
If the next C standard were to introduce something like try/finally/throw to
replace prehistoric libc-based setjmp/longjmp, it would shrink the gap between
it and other languages, well, I'd say roughly by half.

~~~
rwmj
It seems unlikely that would happen. What would be the semantics of stack
unwinding? C doesn't have destructors, so (as with longjmp) you end up losing
track of memory allocations which were pointed to by the stack.

I do offer my own pet wish for C though: Official support for
__attribute__((cleanup)). GCC and CLANG support it.

~~~
avdicius
The semantics would be nothing but executing the finally block. As a rule C
programs do only what is explicitly coded. No high-level programming language
behind the scenes stuff.

------
sudeepj
Amongst all the technical differences, following are some of the factors from
a team-lead/architect p.o.v:

1) What is the ecosystem now? If it is not good, does it look like it will
improve in next X time or so?

    
    
       1.1) What are the production ready libraries right now?
       1.2) Who are the maintainers? Who is backing them?
       1.3) How approachable is the community? 
       1.4) Are the current pain points are being worked at and at appropriate speed?
       1.5) How is the tooling scene?
    

2) What is the overhead for large codebases? e.g factors = [simplicity,
deployability, testability, code-review, refactorability, learnability]

3) How hard/easy it is to wrap C/C++ code/libs if we ever need? Will there be
any performance impact?

4) Does it look like more CPU bound code will be added looking at the product
roadmap?

We are a python shop. As long as it was network IO centric we were ok. However
due addition of features, the CPU bound code has increased and we clearly see
the limitations of Python. This has led to find the replacement language.
Since we are reviewing now the 'X time' in #1 is '1 year'. For others the
tolerance may vary.

As for #2: Code review has an additional overhead due to Python's dynamic
nature. Also we need to write additional unit testcases. A language which
"prevents" basic issues (not going into 'how') has less overhead on the team.

#3: From what I know, go does not do well here in terms of performance. We
deal with lot of 3rd party APIs e.g using VMware APIs which are in C and are
called in the main loop. Also evaluation of this point helps us to see if any
shortcoming in the current libraries can be augmented by wrapping existing
C/C++ libs. Rust & D are better I suppose.

refactorability: GC'ed languages inherently has an advantage (for large
codebases). Counter examples welcome.

learnability: Rust suffers here most. This is a point which makes it hard for
Rust to get introduced and even though I may have patience to stick with it
others may not and drives down the adoption. On most occasions, other teams
also need to be convinced for any meaningful transition.

Testability (i.e. unit tests): Python is really good at this. This is not a
point for the testing tools but more for language features. I find dependency
injection in Rust really hardest right now (or may be I might have missed
something)

#4 is true in our case.

#1 (libraries/tools): Go is ahead I think in terms of production ready libs.

#1 (community aspect): Go & Rust are better here than D (right now) even
though the founder of D is prolific. Note that when championing a language
inside a company is concerned perceptions matter a lot. Here I think D suffers
a bit in my case.

Right now I am in wait-and-watch mode but leaning towards Rust.

(edited: formatting issues)

~~~
qznc
One advantage of D compared to the others is C++ integration. It can actually
do it partially, whereas other languages just fall back to a C-ABI layer in
between.

------
MrPatan
C

------
smegel
If C++ couldn't do it, D won't. They are of the same ilk.

Go kinda is already, but is too sucky on too many levels to really break
through.

Rust is still alpha and seems to be going backwards at times, but looks like a
strong contender.

Assuming Go fixes its many problems, and Rust is eventually delivered, I think
they will both have a strong role to play, Go in the networking/systems space,
Rust in the large scale app development space (like making a browser).

But C will still be around.

~~~
fithisux
Go is not sucky. It is fantastic at what it does. I really see it as a valid
replacement for all sucky frameworks like:

Django/Rails Sinatra and so on.

These frameworks do injustice to their languages :

Rails hurts Ruby, Django hurts Python, Sinatra hurts Javascript.

JavaScript has a lot to offer but in the distant future. An even then it
relies on slaves building pyramids.

~~~
smegel
> Go is not sucky. It is fantastic at what it does.

Go _is_ fantastic at what it does well, which is lightweight concurrency (with
a synchronous api), something that no other compiled, imperative language
offers.

But I haven't spoken to a single Go developer (and I've spoken to a few) who
don't hesitate to tell me how sucky it is in many, many other ways. I've heard
the phrase "I'm really starting to hate Go" more than once or twice.

