9 ms·

Which language has the brightest future for replacing C: D, Go, Rust?

152 points by sidcool 11y ago

gonzo41 11y ago
c++. Its not going away.
- moonshinefe 11y ago
  The level of verbosity in modern C++ is almost approaching Java levels these days. I could see a simpler language gain favour.
  - gonzo41 11y ago
    The trick is to not use all the features.
    - gilgoomesh 11y ago
      It's actually the lack of features that's the problem for verbosity in C++. Features like algebraic types, pattern matching, Unicode handling – which are all part of modern languages – require bloated libraries and templating upon templating to work in C++. C++'s apparent excess of features is mostly due to the fact that its memory model and type system have hundreds of edge cases that need handling. Compared to D, Rust and other newer languages, C++ never actually feels full featured (despite being horribly complex in some areas).
  - creshal 11y ago
    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 11y ago
      Sounds like someone needs to rigorously define a good subset then write a tool to verify that a program uses only that subset.
      - lucozade 11y ago
        As if by magic.... https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-...
        bryanlarsen 11y ago
        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)
      - creshal 11y ago
        I suspect it'll end like this: http://xkcd.com/927/ http://xkcd.com/927/
  - richev 11y ago
    Isn't the verbosity all about job security? ;) http://harmful.cat-v.org/software/c++/I_did_it_for_you_all http://harmful.cat-v.org/software/c++/I_did_it_for_you_all
  - otabdeveloper1 11y ago
    This hasn't been true since C++11. C++11 is as terse as ML.
  - deleted 11y ago
    [deleted]
  - pjmlp 11y ago
    You got it wrong. Before J2EE was a thing, there were something called CORBA and COM and mainly used from C++.
- grabcocque 11y ago
  C and C++ have both passed the threshold of immortality. There's so many billions of lines of code in both those languages that the likelihood of either of them ever disappearing is very slim. The question is about new development, and to what extent C and C++ are evolutionary dead ends. Nobody would design a language like C today, would they? They'd be laughed at.
  - EliRivers 11y ago
    They'd only be laughed at because they were accidentally recreating C and it'd be easier to just use C. C itself is a great language doing the job it was made for very well.
    - grabcocque 11y ago
      Again, the evidence of this is rather slim. It's basically impossible to create safe, code in C as evidenced by the fact that nobody has every managed it. You're making the mistake of assuming that because you know something really well, that makes it good.
      - sien 11y ago
        NASA got 3.8 million lines of safety critical code written in C for the Mars Curiosity rover by 40 engineers in 5 years. It can be done. The talk on their coding standards, automatic code checking, code review and code coverage is well worth watching and listening to. http://cacm.acm.org/magazines/2014/2/171689-mars-code/abstract http://cacm.acm.org/magazines/2014/2/171689-mars-code/abstra...
      - Kristine1975 11y ago
        But C wasn't made for safe code, it was made as a replacement for assembly language to implement Unix in. And that it arguably did well ;-) Incidentally, according to Wikipedia, development of C started in 1972, the same year buffer overflows as a concept were first documented.
      - EliRivers 11y ago
- progman 11y ago
  C++ has reached the state of Cobol. It's not going away just for historical reasons. There is too much code written in it which needs to be maintained in the next decades. I don't envy them who are forced to do that :-)
flashm 11y ago
Why does anything need to replace C? It's been fine for years and still does exactly what it needs to do.
- grabcocque 11y ago
  The endless, eternal, continual stream of catastrophic security flaws in every C program of note begs to differ.
- beering 11y ago
  I think this is not a serious question, but I'll bite. We're paying a hefty price for C in the form of buffer overflows, memory leaks, slow development, and other problems and will continue to do so as long as we run software written in C. If we instead switch to a language that doesn't have these problems, then we'll come out better in the long run.
  - flashm 11y ago
    It was slightly tongue in cheek - C is good at what it does, but I agree that there are plenty of good options going forward. I just don't think C will be 'replaced' across the board though, but I suppose that's obvious. Of the languages mentioned, I've only got experience with Go (which I use for APIs). Rust looks interesting though, I need to have a proper look at it.
  - EliRivers 11y ago
    We won't come out "better". We'll have made a trade-off. For some situations, it will have been a trade-off that benefits. For others, it will have been the wrong choice. Just use the right tool for the job given the circumstances.
  - arihant 11y ago
    These aren't problems of the language. These are a result of having a design choice of full programmer control. Having automatic cars is convenient and has its uses. But the argument that not using a manual cars will cause less road accidents is misinformed. It looks like that because common sense dictates that as it's easier to drive, more people will drive it easier. But usually the result is that now you have people on road who could not drive a stick! Some things are meant to be written in lowest level possible. Programming languages are tools and it helps us to have tools for entire spectrum of abstractions. Electronic screwdrivers haven't replaced manual ones in 2 decades. That's not how tools work. As far as direct comparisons go, these isn't any indication that raising the level of abstraction actually helps with more secure, bug-free code. Compare Java code written (in FOSS setting) with C code written in last 15 years. I bet you'd find C code more secure, more fast, more faster to refactor than a lot of Java code. So if Java was a systems language, would the world be better off if it replaced C? Probably no. Which shows that it's our infatuation with new shiny toys (languages like Go) that's driving our opinion rather than evidence.
kbart 11y ago
I'd bet my money that C will outlive them all.
- blueflow 11y ago
  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 11y ago
    You probably know already, but just for anyone that doesn't, Rust uses LLVM to compile its machine code.
    - blueflow 11y ago
      Properties of an language are not necessarily inherited when compiled. LLVM Code is not bound to Rust's memory access restrictions.
      - kibwen 11y ago
        The Rust developers specifically tailor the compiler to generate LLVM IR that resembles Clang's generated LLVM IR.
- pjmlp 11y ago
  Cobol is still around.
facepalm 11y ago
Depressing to read. Somehow I can not find a language I really like :-(
- tdsamardzhiev 11y ago
  Me too. I think people generally prefer to stick with the evil they know.
- yoodenvranx 11y ago
  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.
jasode 11y ago
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.
- buster 11y ago
  Plus, as Andrei says himself, D has a GC and it's impractical to work around that in D. So, from that point of view, only Rust can compete with C/C++.
  - jasode 11y ago
    Right. I clarified that I meant D's usage explicitly avoiding the historical GC. I'm not a D expert but it looks like the GC obstacle is mostly in the libraries and not impeding the language syntax.
    - chipsy 11y ago
      It's a whole-ecosystem issue. There are plenty of built-in features that happen to depend on GC, and while the ways to eliminate GC use are only increasing with time, the "idiomatic D style" is left in doubt when it's so dependent on allocation strategy. Precision choices for performance are characteristic of D - you have a lot of options to type or annotate your code towards a certain envelope of performance, or ignore almost everything and leave it to the GC. So this is not an unfamiliar problem, but it's a point of friction in the same way that borrow-checking poses friction for Rust - the friction may be centered on what you want for your problem domain. If nothing else, you can write C in D, in a roughly similar way to how you can write C in C++ - the features are there, and so are the libraries.
SandB0x 11y ago
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 11y ago
  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.
  - FraaJad 11y ago
    I use Xamarin Studio (Mono-D) daily for programming in D on a Mac and it is a very capable IDE, at least for what I do.
  - Zardoz84 11y ago
    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...
smegel 11y ago
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.
- rvense 11y ago
  Rust isn't alpha anymore.
- fithisux 11y ago
  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 11y ago
    > 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.
  - vukmir 11y ago
    >Rails hurts Ruby, Django hurts Python, Sinatra hurts Javascript. Is there some JS framework called Sinatra? Either you made a mistake or I'm out of the loop when it comes to the JS world. The only Sinatra I know of is http://www.sinatrarb.com/ http://www.sinatrarb.com/
gilgoomesh 11y ago
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).
Argorak 11y ago
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.
raspasov 11y ago
Clojure is the new C http://www.infoq.com/presentations/clojure-c http://www.infoq.com/presentations/clojure-c
- weavie 11y ago
  Wow, that's probably one of the last things I would have thought of. I look forward to listening to that.
  - progman 11y ago
    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.
fithisux 11y ago
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?
- pjmlp 11y ago
  All major open source C compilers are written in C++.
- kibwen 11y ago
  > 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.
- Ygg2 11y ago
  Rust can expose C interface. If your lang can talk to C, it can talk to Rust
merb 11y ago
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.
jdmoreira 11y ago
Nim for sure. Compiles to C and it's awesome.
- quotemstr 11y ago
  The language known also as n_i_m and NiM?
  - progman 11y ago
    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 11y ago
      What do you think about Julia?
      - progman 11y ago
        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.
aprdm 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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.
hellofunk 11y ago
> 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.
- seivan 11y ago
  Yeah but the problem is that your benefits depend on the libraries you're using. You might not be able to use unique/shared_ptr because of some framework using different conventions internally. But overall, I agree with you. C++11 seems different from when we used it in high school.
  - KayEss 11y ago
    That's true to a certain extent. There are a ton of new libraries appearing though, and the benefits of moving to the newer features are so compelling that actively maintained libraries are swiftly moving over. In the past six months I've moved all of mine from C++03 to C++14 and going through the process of stripping out loads of Boost and internal facilities that are now in the language.
  - T-zex 11y ago
    Smart pointers are about ownership. If "some framework is using different conventions internally" then that framework entirely owns the resource and access to it is not managed by smart pointers. That is a natural, fully idiomatic behaviour of modern C++ and is not related to any specific library.
MrPatan 11y ago
C
oDot 11y ago
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
- deleted 11y ago
  [deleted]
DeveloperExtras 11y ago
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'.
avdicius 11y ago
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 11y ago
  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 11y ago
    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.
jernfrost 11y ago
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 11y ago
  On OSes written in C, C benefits from OS ABI == C ABI, but it wasn't always like that.
sudeepj 11y ago
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)
- 11y ago
vruiz 11y ago
> 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.
avera 11y ago
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!
- Zardoz84 11y ago
  C is the assembly for the Unix virtual machine.
- progman 11y ago
  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 11y ago
    high level assembler - exactly!
vukmir 11y ago
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 11y ago
  > 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 11y ago
    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.
- steveklabnik 11y ago
  > Rust has a feel of a hobbyist language in perpetual alpha. Would you mind elaborating on this? We released a stable version in May, so I'm wondering why it still feels that way.
tmaly 11y ago
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.

152 points by sidcool 11y ago

gonzo41 11y ago

c++. Its not going away.

moonshinefe 11y ago
The level of verbosity in modern C++ is almost approaching Java levels these days. I could see a simpler language gain favour.
- gonzo41 11y ago
  The trick is to not use all the features.
  - gilgoomesh 11y ago
    It's actually the lack of features that's the problem for verbosity in C++. Features like algebraic types, pattern matching, Unicode handling – which are all part of modern languages – require bloated libraries and templating upon templating to work in C++. C++'s apparent excess of features is mostly due to the fact that its memory model and type system have hundreds of edge cases that need handling. Compared to D, Rust and other newer languages, C++ never actually feels full featured (despite being horribly complex in some areas).
- creshal 11y ago
  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 11y ago
    Sounds like someone needs to rigorously define a good subset then write a tool to verify that a program uses only that subset.
    - lucozade 11y ago
      As if by magic.... https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-...
      - bryanlarsen 11y ago
        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)
    - creshal 11y ago
      I suspect it'll end like this: http://xkcd.com/927/ http://xkcd.com/927/
- richev 11y ago
  Isn't the verbosity all about job security? ;) http://harmful.cat-v.org/software/c++/I_did_it_for_you_all http://harmful.cat-v.org/software/c++/I_did_it_for_you_all
- otabdeveloper1 11y ago
  This hasn't been true since C++11. C++11 is as terse as ML.
- deleted 11y ago
  [deleted]
- pjmlp 11y ago
  You got it wrong. Before J2EE was a thing, there were something called CORBA and COM and mainly used from C++.
grabcocque 11y ago
C and C++ have both passed the threshold of immortality. There's so many billions of lines of code in both those languages that the likelihood of either of them ever disappearing is very slim. The question is about new development, and to what extent C and C++ are evolutionary dead ends. Nobody would design a language like C today, would they? They'd be laughed at.
- EliRivers 11y ago
  They'd only be laughed at because they were accidentally recreating C and it'd be easier to just use C. C itself is a great language doing the job it was made for very well.
  - grabcocque 11y ago
    Again, the evidence of this is rather slim. It's basically impossible to create safe, code in C as evidenced by the fact that nobody has every managed it. You're making the mistake of assuming that because you know something really well, that makes it good.
    - sien 11y ago
      NASA got 3.8 million lines of safety critical code written in C for the Mars Curiosity rover by 40 engineers in 5 years. It can be done. The talk on their coding standards, automatic code checking, code review and code coverage is well worth watching and listening to. http://cacm.acm.org/magazines/2014/2/171689-mars-code/abstract http://cacm.acm.org/magazines/2014/2/171689-mars-code/abstra...
    - Kristine1975 11y ago
      But C wasn't made for safe code, it was made as a replacement for assembly language to implement Unix in. And that it arguably did well ;-) Incidentally, according to Wikipedia, development of C started in 1972, the same year buffer overflows as a concept were first documented.
    - EliRivers 11y ago
progman 11y ago
C++ has reached the state of Cobol. It's not going away just for historical reasons. There is too much code written in it which needs to be maintained in the next decades. I don't envy them who are forced to do that :-)

flashm 11y ago

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

grabcocque 11y ago
The endless, eternal, continual stream of catastrophic security flaws in every C program of note begs to differ.
beering 11y ago
I think this is not a serious question, but I'll bite. We're paying a hefty price for C in the form of buffer overflows, memory leaks, slow development, and other problems and will continue to do so as long as we run software written in C. If we instead switch to a language that doesn't have these problems, then we'll come out better in the long run.
- flashm 11y ago
  It was slightly tongue in cheek - C is good at what it does, but I agree that there are plenty of good options going forward. I just don't think C will be 'replaced' across the board though, but I suppose that's obvious. Of the languages mentioned, I've only got experience with Go (which I use for APIs). Rust looks interesting though, I need to have a proper look at it.
- EliRivers 11y ago
  We won't come out "better". We'll have made a trade-off. For some situations, it will have been a trade-off that benefits. For others, it will have been the wrong choice. Just use the right tool for the job given the circumstances.
- arihant 11y ago
  These aren't problems of the language. These are a result of having a design choice of full programmer control. Having automatic cars is convenient and has its uses. But the argument that not using a manual cars will cause less road accidents is misinformed. It looks like that because common sense dictates that as it's easier to drive, more people will drive it easier. But usually the result is that now you have people on road who could not drive a stick! Some things are meant to be written in lowest level possible. Programming languages are tools and it helps us to have tools for entire spectrum of abstractions. Electronic screwdrivers haven't replaced manual ones in 2 decades. That's not how tools work. As far as direct comparisons go, these isn't any indication that raising the level of abstraction actually helps with more secure, bug-free code. Compare Java code written (in FOSS setting) with C code written in last 15 years. I bet you'd find C code more secure, more fast, more faster to refactor than a lot of Java code. So if Java was a systems language, would the world be better off if it replaced C? Probably no. Which shows that it's our infatuation with new shiny toys (languages like Go) that's driving our opinion rather than evidence.

kbart 11y ago

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

blueflow 11y ago
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 11y ago
  You probably know already, but just for anyone that doesn't, Rust uses LLVM to compile its machine code.
  - blueflow 11y ago
    Properties of an language are not necessarily inherited when compiled. LLVM Code is not bound to Rust's memory access restrictions.
    - kibwen 11y ago
      The Rust developers specifically tailor the compiler to generate LLVM IR that resembles Clang's generated LLVM IR.
pjmlp 11y ago
Cobol is still around.

facepalm 11y ago

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

tdsamardzhiev 11y ago
Me too. I think people generally prefer to stick with the evil they know.
yoodenvranx 11y ago
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.

jasode 11y ago

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.

buster 11y ago
Plus, as Andrei says himself, D has a GC and it's impractical to work around that in D. So, from that point of view, only Rust can compete with C/C++.
- jasode 11y ago
  Right. I clarified that I meant D's usage explicitly avoiding the historical GC. I'm not a D expert but it looks like the GC obstacle is mostly in the libraries and not impeding the language syntax.
  - chipsy 11y ago
    It's a whole-ecosystem issue. There are plenty of built-in features that happen to depend on GC, and while the ways to eliminate GC use are only increasing with time, the "idiomatic D style" is left in doubt when it's so dependent on allocation strategy. Precision choices for performance are characteristic of D - you have a lot of options to type or annotate your code towards a certain envelope of performance, or ignore almost everything and leave it to the GC. So this is not an unfamiliar problem, but it's a point of friction in the same way that borrow-checking poses friction for Rust - the friction may be centered on what you want for your problem domain. If nothing else, you can write C in D, in a roughly similar way to how you can write C in C++ - the features are there, and so are the libraries.

SandB0x 11y ago

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 11y ago
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.
- FraaJad 11y ago
  I use Xamarin Studio (Mono-D) daily for programming in D on a Mac and it is a very capable IDE, at least for what I do.
- Zardoz84 11y ago
  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...

smegel 11y ago

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.

rvense 11y ago
Rust isn't alpha anymore.
fithisux 11y ago
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 11y ago
  > 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.
- vukmir 11y ago
  >Rails hurts Ruby, Django hurts Python, Sinatra hurts Javascript. Is there some JS framework called Sinatra? Either you made a mistake or I'm out of the loop when it comes to the JS world. The only Sinatra I know of is http://www.sinatrarb.com/ http://www.sinatrarb.com/

gilgoomesh 11y ago

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

Argorak 11y ago

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.

raspasov 11y ago

Clojure is the new C http://www.infoq.com/presentations/clojure-c http://www.infoq.com/presentations/clojure-c

weavie 11y ago
Wow, that's probably one of the last things I would have thought of. I look forward to listening to that.
- progman 11y ago
  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.

fithisux 11y ago

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?

pjmlp 11y ago
All major open source C compilers are written in C++.
kibwen 11y ago
> 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.
Ygg2 11y ago
Rust can expose C interface. If your lang can talk to C, it can talk to Rust

merb 11y ago

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.

jdmoreira 11y ago

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

quotemstr 11y ago
The language known also as n_i_m and NiM?
- progman 11y ago
  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 11y ago
    What do you think about Julia?
    - progman 11y ago
      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.

aprdm 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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.

hellofunk 11y ago

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

seivan 11y ago
Yeah but the problem is that your benefits depend on the libraries you're using. You might not be able to use unique/shared_ptr because of some framework using different conventions internally. But overall, I agree with you. C++11 seems different from when we used it in high school.
- KayEss 11y ago
  That's true to a certain extent. There are a ton of new libraries appearing though, and the benefits of moving to the newer features are so compelling that actively maintained libraries are swiftly moving over. In the past six months I've moved all of mine from C++03 to C++14 and going through the process of stripping out loads of Boost and internal facilities that are now in the language.
- T-zex 11y ago
  Smart pointers are about ownership. If "some framework is using different conventions internally" then that framework entirely owns the resource and access to it is not managed by smart pointers. That is a natural, fully idiomatic behaviour of modern C++ and is not related to any specific library.

MrPatan 11y ago

oDot 11y ago

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

deleted 11y ago
[deleted]

DeveloperExtras 11y ago

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

avdicius 11y ago

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 11y ago
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 11y ago
  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.

jernfrost 11y ago

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 11y ago
On OSes written in C, C benefits from OS ABI == C ABI, but it wasn't always like that.

sudeepj 11y ago

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)

11y ago

vruiz 11y ago

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

avera 11y ago

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!

Zardoz84 11y ago
C is the assembly for the Unix virtual machine.
progman 11y ago
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 11y ago
  high level assembler - exactly!

vukmir 11y ago

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 11y ago
> 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 11y ago
  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.
steveklabnik 11y ago
> Rust has a feel of a hobbyist language in perpetual alpha. Would you mind elaborating on this? We released a stable version in May, so I'm wondering why it still feels that way.

tmaly 11y ago

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.