I'm a die-hard C guy. My motto for years has been "you can pry pointers and address spaces from my cold, dead hands."
Of the new languages I've seen lately, Rust is my favorite. I love how it gives me better ways to express things I actually want to say without imposing GC on me.
But even so, I can't see myself actually using it for much, because writing in a language other than C means buying in to that language's runtime. Buying into one language's runtime means that your code won't play nice with other languages' runtimes.
If I write a library in Rust, how can I expose my types and algorithms to Ruby, Python, Lua, etc? How will Rust Tasks play with Python threads? What if I use a Rust Pipe to send a Python value between tasks? How do I keep Rust from doing a GC pass while I'm holding the Python GIL? etc. etc.
Programming Languages by their nature want to be at the center of your world. If you buy into their abstractions, everything works nicely. But if you try to mash two of them together in a single process, you start to suffer from the fact that their abstractions overlap and don't interoperate at all.
If you're only writing an application (ie. not a library) and never want to embed other languages into your application, then this might be ok. But I'm more interested in writing shared functionality that is useful across languages. Why should the whole stack of parsers, crypto, compression, etc. have to be written separately in each language? Life is too short to do some great work that is only usable by one language community -- computing is so big and changes so much that one-language-only functionality is at best limiting your market and at worst dooming your code to obsolescence when the next big language comes around.
So as much as I instinctively like Rust, I think I'll be sticking with C.
"If write a library in Rust, how can I expose my types and algorithms to Ruby, Python, Lua, etc?"
The same way you expose them in C. Rust and C are compatible at the binary level.
"How will Rust Tasks play with Python threads?"
More or less the same way C setcontext()/swapcontext() workalikes play with Python threads. We probably want a runtime-less Rust to allow users who aren't using tasks at all to just omit the whole system, though. The language itself knows nothing about tasks; they're purely part of the runtime library.
"What if I use a Rust Pipe to send a Python value between tasks?"
Should work as you expect. In Servo we're already sending Objective-C values (which require special APIs to perform the memory management) from task to task over pipes.
"How do I keep Rust from doing a GC pass while I'm holding the Python GIL?"
By not using the GC. It's easy to tell when you aren't using the GC; you can just avoid @ types, and there is a warning you can turn on to enforce no GC use. This sort of thing is the reason why we support manual memory management.
"If you're only writing an application (ie. not a library) and never want to embed other languages into your application, then this might be ok. But I'm more interested in writing shared functionality that is useful across languages."
"Why should the whole stack of parsers, crypto, compression, etc. have to be written separately in each language?"
I agree completely that this is undesirable. That's why Rust doesn't do this. For your three examples, Rust and Servo link to C libraries: Hubbub for HTML parsing, NSS for crypto, and zlib for compression.
> We probably want a runtime-less Rust to allow users who aren't using tasks at all to just omit the whole system, though.
I'd be really interested in reading more about this if/when it is available. I'm also interested in whether you'd ever ship the tasks library standalone, such that you can interoperate with Rust tasks from C (obviously you'd have to follow certain rules to maintain the integrity/safety of the runtime).
> I agree completely that this is undesirable. That's why Rust doesn't do this. For your three examples, Rust and Servo link to C libraries: Hubbub for HTML parsing, NSS for crypto, and zlib for compression.
Understood, but I'm interested in the story for the guy who is writing those libraries.
I just wanted to say, I totally understand where you're coming from here. I often end up writing libraries in C explicitly because that's the easiest way to hit as many targets as possible and not impose any unexpected runtimes on other languages, even if I know it would be easier to write in another language. So, I would say that not enough language designers think this way, and it's really refreshing to see you describing this point of view.
I've often thought that a useful exercise would be to come up with a language that adds just a bit more power than C but stays within the boundaries of the C runtime, just for this purpose.
However, if new languages like Rust can deliver this, all the better! One language that I once looked at with this in mind was Clay, which seemed to basically be C with more safety and generics. However, it doesn't seem to be as nicely supported as Rust, and perhaps Rust's static analysis and concurrency support will be more powerful.
You'd want a runtime-less Rust if/when it becomes available (there are no immediate plans for this, but we'd be happy to help). We use native OS dynamic libraries, so once it's possible to build Rust code without a runtime it should be pretty easy to call Rust from a pure C host app.
I'm not sure if this will alleviate all of your issues, but eventually the goal is to allow Rust programs to forgo the runtime entirely.
An old comment from pcwalton (sorry, I've lost the link):
"I'd like to see a 'runtime-less Rust' myself, because it'd be great if we could implement the Rust runtime in Rust. This might be useful for other things too, such as drivers or libraries to be embedded into other software. (The latter is obviously of interest to us at Mozilla.) Rust programs compiled in this mode would disable the task system, would be vulnerable to stack overflow (although we might be able to mitigate that with guard pages), and would require extra work to avoid leaks, but would be able to run without a runtime.
"If anyone is interested in this project, I'd be happy to talk more about it -- we have a ton of stuff on our plate at the moment, so we aren't working on it right now, but I'd be thrilled if anyone was interested and could help."
Tell you what I'm doing lately, that makes me less and less interested in the new-school elite, and just generally enjoying a language 'enigma' moment: putting Lua in everything.
That is, I mean to say, Rust is neat and all but we can do it all in Lua, pretty well, too. Table types are fabulous, kids!
And being able to take any collection of C libraries, and glue them together into 'ones own runtime' with a common language framework/boundary, means a lot.
So, yes, of course.. Lua isn't fast, it has weaknesses, there is luaJit and so on: its not about Lua. Its about the fact that you can choose whatever languages are out there, get competent at their adept usage, and win.
I believe that Rust will be a systems programming language when there is a bootable Rust OS that boots to an editor, a shell, a means of interacting with devices, and a Rust compiler sitting there, waiting for input .. until then, it sure is fun to watch the new school language paradigms get all twisty and bent in the rush to school someone on how systems 'should be programmed, instead of the way they are now'. Research in this field is a terrifically interesting social cache.
Has anyone done a RustOS? Is there one? I know of a couple LuaOS projects, and it sure seems to me like what was done with Linux on Android could be done to Linux, again, with Lua .. Rust .. and so on. Could be very cute times ahead, in the distribution mecca .. GoboLinux, but instead 100% booted to Lua? Hmm .. bogglethink .
No, really, I'm not being snide. I honestly believe that Rust is of great interest, as is the effort and front of new language exploration. However, there is an intrinsic quality of language: it is infinitely useful, or not useful, depending on one thing only: the user.
This is exactly the "one language" myopia that I was arguing against. Anyone who tries to sell me on a language or programming system that asks for complete buy-in and offers no interoperability story is immediately suspect in my book.
(FWIW, I don't think the Rust guys actually sell this line, so I'm arguing against you, not them).
No one will ever invent "the last language you'll ever need." One reason for this is that different languages excel at different things. For example, Rust is not as easy to sandbox as Python, Ruby, etc. It's also not as simple to write quick scripts in.
Another reason is that you'll never convince everyone in the world to use the same language. Even if you convinced them that they should use the same language (which is impossible), there are billions of lines of code in use that is written in different languages. If you can't interoperate with them, you are a rock, you are an island.
There's nothing "modern" about the idea that "we're going to make the last language you'll ever need."
Grandparent has a point, and it's not quite as outlandish as you make it out to be.
Consider that a lot of Python developers write most of their code in Python, then rewrite critical parts in C to speed it up. Python is not a speed demon, and that becomes particularly problematic with tight loops or heavy math—but writing entire applications in C is error-prone and tedious.
Rust won't outright replace both of those, but it does offer a nice middle ground: it's safe, it has some higher-level constructs, it does away with some boilerplate, it builds fairly easily, and it still compiles essentially to machine code. Writing quick shell-like scripts or entire applications in a systems language is now a viable option for lazy jerks like me, even if it's not always the best one.
> Writing quick shell-like scripts or entire applications in a systems language is now a viable option for lazy jerks like me, even if it's not always the best one.
I agree completely. I love Rust for this reason too. That's not what the grandparent said, or what I'm arguing against.
Grandparent was dismissing my concern about language interoperability because new languages should cover "all your needs." This attitude is closed-minded and dangerous.
A language that covers lots of needs is great. A language that is so useful that you find yourself needing fewer total languages for your project is great.
But the moment you use that as a reason to stop caring about interoperability between languages, to argue that it doesn't matter whether your language can interface with others, that's the moment when I stop paying attention to what you are designing.
Out of mild concern over the title (not that it ought to be changed, TFA doesn't really have a meaningful title), I'd like to preemptively defuse any potential flame war.
Go and Rust are not really competing. There may be some overlap in domain, but they occupy different niches and will likely appeal to different crowds. Go will appeal more to people who prefer its focus on conceptual simplicity and its "opinionated" nature (very much like Python). Rust will appeal more to people who prefer "functional" trimmings (algebraic datatypes, pattern matching, liberal use of higher-order functions, Scheme-style macros) as well as folks fed up with C++ who aren't willing to give up complete control over memory and performance characteristics. The fact that both languages are built around a similar concurrency model is just convergent evolution.
It's tempting to cast Go vs. Rust as Google vs. Mozilla and/or Chrome vs. Firefox, but there's no practical reason that both languages cannot peacefully coexist and thrive.
The two languages aren't really in the same space in the first place. Go is a simpler language that leans more heavily on garbage collection. Rust is a more complex language that can be safely used without the GC at all.
Go is a great language -- I greatly admire its simplicity -- and for its domain it's fantastic. Rust is in a different domain: low-level systems programming in which abstractions must be zero-cost and control over the machine is crucial.
Go actually provides what I believe to be zero cost abstractions that map straight to the c memory model, making it very easy to use for systems programming.
If you want a fixed size array of bytes, for for it. Zero overhead. If you want a slightly smarter list you can use a go slice, which is also pretty low overhead. I've personally verified that if I create a struct in go it takes up the exact same amount of memory as the same c structure.
As a concrete example, I recently built an interface to kernel crypto apis using pure go (no cgo). There's no magic to go data structures, you can define structs in go and pass pointers directly to syscalls (through the syscall package) and everything just works. Dealing with large arrays of binary data is similarly straightforward. So go does give you complete control over memory layout if you choose to use it.
The elephant in the room is that go does have garbage collection, and that ain't free. Practically you can minimize it's impact by managing your own memory. In fact that's what Brad Fitzpatrick is doing with his go based memcached implementation.
It all boils down to how you define systems programming. I guess if you mean is go suitable to write a kernel in, the answer is probably no, (but it would sure be fun to try). If systems programming requires having the complete ability to interact with the operating system and all syscalls + tight control over memory layout, then maybe go is the way to go.
with respect to python and garbage collection, did you know you can actually turn it off? If you have no cycles in your program you can turn off gc and let the ref counter clean up all your data, similar to Objective-C's ARC.
There is a lot more to zero-cost abstraction than memory layout. If you do manual memory management in Go, then you get no safety. It is also difficult to use the standard library with manual memory management. Furthermore, interfaces in Go are not zero-cost; you incur virtual dispatch whenever you use them.
The article is about doing safe manual memory management. That's something that's unique to Rust.
Simplicity is absolutely the most crucial aspect of a language used for successful commercial application in my space (15-30 mil annual). That's what I like about Go. Don't know much about Rust, but if it's being designed by a small group of engineers who think oop is still awesome, then successful commercial software developed in Rust will be just as costly to maintain as the 500k to 5 mil line codebases I run across today, written in currently available languages.
Speaking in general:
You get all this wonderful language functionality, and I promise you that you will write some shitty code at some point just to keep up with the daily pressures presented by a successful software package (clients screaming, salespeople breathing down your neck, etc), I don't care how good of an engineer you think you are. What's really funny is that, because everything has gotten so much more complicated (dev tools, business, cost of bugs going up, how to make money with software, whatever), the successful software I work on today is not making any more money than the successful software I worked on back in the late 80's running under DOS. Back then, the oop free tools and the target os were simple enough that we really could become SME's on our domains as well as on the dev tools we used to write code for those domains.
C# and java are definitely not the solution for new applications which are expected to generate revenue for the next 10 years. If Rust is just trying to be smarter at what these languages already do, I'm not interested. Something has got to come along which simplifies development, especially concurrency, and allows programmers of varying skill levels to write productive code in. Then after 5 mil loc, programmers coming and going on a project, an app doesn't end up looking like a fragile mess.
I should have said "generate competitive revenue." Sorry about that.
If you're still using C# or java in 10 years time for a commercial app, the only reason you will not be at a competitive disadvantage is because all the other competitors in your space are using the same languages.
Not sure what you mean here. Rust tends to be pretty dependent on inlining optimizations, just as C++ is. As for code compactness, the way we do task failure leads to significant code bloat at the moment (though that's on track to be fixed, and the code is off to the side and not executed unless you actually fail). As for memory layout, the rules follow C; struct fields are laid out in the order you specify them in the code, and so on.
For what it's worth, I like Rust because I like Python. Python does strive to have one "obvious way to do it", but that ends up meaning it has a very colorful toolbox full of different ways to solve different problems, much like Rust. Generators, context managers, metaclasses, decorators, and descriptors are all very different mechanisms, but they all work together well.
Hell, I keep discovering that Rust has already implemented language features I'd independently thought up half-baked versions of.
And not to encourage a flamewar, but I believe there's a gigantic unspoken niche that Rust and Go will be fighting over: people like me who stay away from systems programming because it's a pain in the ass. C is tedious, C++ is bozotic, D is obscure—so the lowest I've bothered to go for a while is Cython. But now there's Rust, and I'm genuinely enjoying it, and I see other people who've mainly been sticking to Ruby or Python who are enjoying Go. This will be interesting to watch. And regardless of what I think of Go, I'm glad there's finally some activity in this space again. :)
I have not had time yet to look into rust more closely, but do you know if it would be able to export a Rust module in a dlopen-able library, accessible from C ? Writing python extensions in Rust instead of C would be pretty exciting
This is not quite possible yet, but will be at some point.
Rust does currently depend on a language runtime which expects to control the execution of all Rust code (in particular managing the task scheduler), and the runtime does not have an embedding story yet. Even with an embeddable runtime though, the process would be more involved than loading a library through `dlopen` and executing a function.
As part of the effort to rewrite the remaining bits of C++ runtime code in Rust (almost all of Rust is written in Rust), there are further plans to make Rust code runnable without an underlying runtime and without split stacks. After that it will be feasible to write code in Rust and just call it like any C function.
Ha, I was just thinking about how Rust bindings to Python might look.
I haven't actually tried this, but since Rust libraries just compile to .so's and it's possible to declare a Rust function with a C signature, I bet it'd be a simple exercise to write a CPython-compatible extension module.
For those with even less of a chemistry background than I have: rust is iron oxide, and pyrite is iron sulfide. It's a good analogy because oxygen and sulfur are in the same group (column) in the periodic table, so they have some chemical similarities.
There was a music software language called Pyrite. It ran inside of Max graphic programming environment. It then evolved into SuperCollider which is now one of the most used music programming languages in experimental and academic music. Http://github.com/supercollider
But that pyrite hasn't been active for a long time.
I have used D but no Rust yet. They look superficially similar.
On the Rust side, algebraic data types, an AST macro system, saner tuples, non-nullable and immutability by default. I'm a bit skeptic about the different pointer types and how they will interact with meta-programming.
On the D side, many good things like unittest(), best-in-class overloading support, compile-time everything, etc.
No, Rust has two ways of allocating memory (on the task heap or on the exchange heap), and most functions take borrowed pointers, which accept both kinds of memory.
(Edit, re below reply: It depends how you define "allocation"; it's either two or three. I wasn't considering the stack as allocation, but you're right that Rust takes the traditional stack/heap distinction and expands it to stack/exchange heap/task heap. We should update the tutorial to make it clear that borrowed pointers work for the stack as well as both heaps.)
I agree that the language is not designed to be a Python replacement, however. No language is suitable for every task.
Rust has three "realms" in which objects can be allocated: the stack, the local heap, and the exchange heap. These realms have corresponding pointer types: the borrowed pointer (&T), the shared box (@T), and the unique box (~T). These three sigils will appear repeatedly as we explore the language. Learning the appropriate role of each is key to using Rust effectively."
Rust statically prevents leaks and double-frees, warns about implicit copies of large structures, and has GC built in if I want to use it. It's certainly more familiar to a Python dev than C++. The whole trait system is even like a built-in and vastly simpler zope.interface.
Of course they compete. People aren't born with a gene that puts them into exactly one of the camps you describe. These ideas compete and so do the languages, provided they can be used for largely the same tasks, which seems to be the case.
I'm sure that Go has higher-order functions, I just mean that Rust encourages you to use higher-order functions all the time. For example: in Rust, `for` loops desugar to higher-order functions (it's very neat, actually). Furthermore, whereas in Go you spawn a goroutine with the `go` keyword, spawning a task in Rust is done by handing a function (usually a Ruby-esque closure) to the `task::spawn` library function. (Note also that "higher-order functions" are not the same as "first-class functions".)
Go does not have pattern matching, to my knowledge, though without algebraic datatypes I don't think it's really a big deal.
Go does not have pattern matching. There are type assertions, but obviously that's not the same thing.
Go has higher order functions in some sense, and the standard libraries use them for some things. But I wouldn't say they're nearly as ubiquitous as they are in Ruby or your average functional language. My read is that Go is pretty firmly grounded in imperative-land.
Regardless, since Go 1 came out relatively recently, I doubt they're going to make substantial changes to the language anytime soon. Obvs I don't speak for them, etc etc.
Go has first class functions yes, but without the support for generics/parametric polymorphism, you can't write "higher order functions" for polymorphic functional constructs like map/filter/reduce etc.
Google employs some of the brightest computer science minds in the world and turns out stuff like Go and Dart, which seem to be more aimed at enterprise Java programmers rather than computer scientists or programming enthusiasts.
You attribute too much to these entities called "Google" and "Mozilla". They're made of people.
No executive asks for a new programming language. However at some enlightened organizations, they are willing to let hackers explore radical approaches.
At some point, in order for them to become "official" projects, the hackers have to align the language with the organization's goals. But the imprimatur of their creators is unmistakable.
In any case, I doubt there is any plan to move everything in Google to Go. They're willing to let the creators and some enthusiasts play around with it, maybe deploy a few apps internally. But for Rust to be a success, Mozilla's going to have to use it extensively in their main product.
That said, managers usually have little say in defining what the actual language is going to be like or what its other applications will be, because so much has to be deferred to the language designers. Even though Netscape's execs specifically requested a Java-like language, they got something rather different.
Yeah, I admit my comment was not all that well thought out.
I was reacting to the usual dumbass theory that $BIG_ORGANIZATION is executing some master plan which explains all of their actions. It explains how they filter and rank ideas, but it doesn't explain why those particular ideas happened to be floating around in their organization.
When it comes to things like new frameworks and languages, in my experience, it's usually some employee going off on their own. And the reason why the language is the way it is has more to do with that person's obsessions and interests. They later justify it to the organization by producing results and getting peer buy-in. FLOW-MATIC (ancestor of COBOL), Perl, Java, Sawzall, Go, and Rust seem to be like this.
I don't think Haskell counts at all. That was an academic project amalgamating other academic projects.
I don't know enough about the others you mention. Maybe this isn't a useful way to think about programming languages, but I was just exploring the idea by rambling about it. ;)
Objective-C was developed mostly by one guy (Brad Cox) back in the '80s. He was inspired by Smalltalk. He didn't do it on behalf of any corporation that I know of, though he and a partner did try to commercialize it later.
"today's server programs comprise tens of millions of lines of code, are worked on by hundreds or even thousands of programmers, and are updated literally every day. To make matters worse, build times, even on large compilation clusters, have stretched to many minutes, even hours."
He never specifically said it's C++ nor Java. I think he's talking about C++. C++'s slow compile problem has to do with the repeated inclusion of header files for every source file, which can become a FileNum^2 recompilation problem. Though pre-compiled header files and refactoring into pre-built libraries should reduce the compile time. Java simply does not have the slow compile problem due to its simple package/class per dir/file, where a compiled class won't be recompiled again.
I think that's because they have a lots of Java code to compile. When there are a lot of GO codes to compile, it will take hours as well. I doubt GO's compile speed is significantly faster than Java. Both of them don't have the dependency problem plaguing C++. It would be interesting to compare the two.
I'm pretty sure that go's compile speed is significantly faster than java. It's hard to compare though because java compilation is not the same thing. There is the bytecode in the class files and on the fly compilation in the vm. As well as some stuff that happens when the bytecode is loaded and run.
A lot of go's compile speed comes from how simple it's syntax is besides the gains it gets from avoiding C++ dependency issues. Java's syntax while less complex than C++ is still complex compared to go's. And it won't have go's parse time savings.
Go's syntax may look simpler, but from a how many tokens do I need to look ahead parser perspective, I don't think it's much simpler than Java. Go does have a hand tuned parser written in C, vs the java parser written in java and perhaps not tuned for speed, but there's no reason a fast java parser cannot be written.
Nothing you've said contradicts my statement concerning compiling java at Google.
Go doesn't need to rely on dynamic loading because compiling a library is fast and statically linking the libraries is fast. The result is a monolithic executable true but it's still fast without dynamic loading. Go doesn't compile all the source that goes into a binary every time. Libraries get compiled into an archive and don't have to be compiled again unless they change. In that way it has the same benefit as jars for compilation speed.
Seems weird. Google especially is a company that relies so much on programmer productivity & getting things right. Getting them wrong typically means lost revenue.
I mean they spend crazy amounts of money on all kinds of projects that have no directly viable monetization scheme, yet for some reason you think it would be weird for them to explore programming languages? Odd.
Just those three things are enough to make Go code look very from what came before. And I could go on-- things like the way go does namespaces and scoping are also very different.
It's a different philosophy that leads to much better code, in my opinion at least, not dozens of gee-whiz features, which seems to be what the languages of the 1990s gave us and are continuing to give us.
None of those three "big new ideas" are big or new. Go is incredibly conservative, primitive even. It takes a few tiny things like those you mentioned from languages that have had them for decades, but leaves out so much important stuff that the language is barely useful at all.
I'm assuming you'd rather see them focus on declarative programming, because it seems to be the big thing among enthusiasts and hobbyists.
Google works with software projects with planned lifetime of decades. It's far better to rely on imperative programming concepts which are tested and trusted with experience grown from what, 50's or so.
Sure, declarative programming is a nice toy, but that's all. I'm yet to see major companies investing millions, if not billions of capital on a system written in declarative languages. We all "know" functional programming "is the future", but yet nobody trusts their money and time on them.
I'm yet to see major companies investing millions, if not billions of capital on a system written in declarative languages. We all "know" functional programming "is the future", but yet nobody trusts their money and time on them.
SQL is declarative.
Erlang is kinda-sorta functional, and was developed specifically to run expensive high-uptime telecom systems.
...both of which are domain specific languages, or developed as such.
I really think C++ is going to gnaw "market share" from C in any low-level domains and fight back Go and other competitors in high-level systems programming domains thanks to it's recent C++11 standard and upcoming standard library extensions which being the transition of making it much more on-par with other modern languages. Bjarne Stroustrup(the language creator) has also hinted for much faster standardization process than last time around(when it took some 13 years to come up with a new standard), and would hope for a 5 year cycle instead, so perhaps C++16 is coming up next. Oh, and the standards committee is already working on it.
The only major setback I see with C++11 in comparison to many other languages aimed for large-scale software development is it's very small standard library which completely lacks support for modern technologies such as hierarchical filesystems, sockets, XML and HTTP and so on. They are coming up later on, though. The core language is very solid and doesn't lack anything special. Yet, it's not any more "bloated" or complex by it's standard(in terms of page/line/word count) than say C# 3.0 or Java 7.
tl;dr: I think many people think C++ is "old" or even dead and we need something more modern, yet now C++ evolves faster than ever and tries to meet that demand.
There are plenty of companies who have spent millions on developing their websites, written in a variety of the languages you list as 'toy' languages, or even PHP. Whether they would have been better to use other languages is impossible to say of course, but these languages are being used for significant projects. The use of the pejorative 'toy' is not very useful, and likely to evoke emotional reactions.
Go was inspired by a talk on the features of C++11  - in despair at the addition of yet more features; the origins of the language and the philosophy behind it might make interesting reading if you use C++, because it was done directly in reaction to the (as they saw it) baroque edifice of C++.
Though I agree that people should not judge languages by popularity, novelty, or coolness (though it seems many people do), that doesn't mean you shouldn't be open to looking at new languages, if only to inform how you use your favourite one. Go for example has been inspired by the languages you deride, or their precursors (Python, Ruby etc), and in fact has taken much from them in syntax and in the popularity of closures etc.
I do agree with your other point though that this is an excellent area for Google to focus on, and something which will benefit a lot of domains which currently don't use scripting languages (systems programming, many large server systems, desktop apps, mobile apps).
I'm aware of what and why Go came to be, and I can easily relate to the reasons(I've read the blog post). I am by no means saying C or C++ as languages are perfect, nothing is. However, as I mentioned in my another reply to sanderdj, there's huge investment in effort for the abstractions the two languages build. It's very hard to tackle the problem of existing codebase for example, as that requires building stuff from ground up(that happens later on), or the fact that there are far more competent C or C++ programmers than there are Go or Rust programmers(and this isn't likely to change for the next 10-15 years or so, I'd bet), or the fact that there exists practically no libraries for these languages(ports are relatively fast though, few years max.), portability is a major concern too, tools too as well as language standard and educational resources(books, uni grade education, best practices over years, ...) won't exist for years...
So while I think that C and C++ will phase out eventually even in the domain of systems programming, I really don't see Go or Rust doing that for the foreseeable future, if ever. It would be really great to build trustworthy(non-leaky, efficient and secure) abstractions on top of languages like Rust and Go, but how reliable would it be? When would it be feasible? Who takes the first steps? When will the mainstream follow? Are these languages going to be relevant after 20 years?
Oh, and I'm not deriding other languages in their specific domains(I'm a Ruby fan, not so much into Python), but rather the fact that I've been under the impression that many people think that soon C and C++ will phase out and become obsolete(or that they have already done so), we go higher in abstractions, Python and Haskell are the future and computers are so fast that nobody has to care about optimizing their code. Then reality and post-PC era strikes back, battery life and software power-efficiency play higher role than ever...
My experience with Go and especially Rust is quite limited, but it would be really great if I could do my stuff(right now games and path tracing rendering, render times from 12 hours upwards) in either them instead of C++. I really like the ideas behind the languages and they fit my core domain just as well as C and C++ do. Though the thing is, there are no tools. No libraries. No books. Nothing. There's simply no way to jump over, even if the possible performance penalty would be tolerable. And this isn't likely to be changing much for the better for upcoming years, if even then. Perhaps when the languages get an actual standard... It's sad in a way even, but can't escape the facts which make them not viable for many domains.
Thanks for the cogent response, not sure why I was modded down, but never mind. I've been doing a few small experiments in Go just to see what it's like and have loved the compilation time, lack of cruft like header files, and the simplicity. The standard library for Go reminds me of Ruby in many ways as it mostly works exactly as you'd expect with few surprises, and it covers a surprisingly broad range.
I agree that hyperbole on the future of computing is overblown (I wonder if Rust now feels it has to compete with Go for hype!), but there are a lot of things in say Go which are not as nice in C, unicode strings, loops, slices, etc. So it's not entirely pointless to start again with all we have learned since 1969. All of the little niggles in C can be worked around, but overall Go feels like a cleaned up version of C which took a few ideas from C++ and other OOP languages and left the rest out as unnecessary. Given the problems vast hierarchies of classes sometimes cause, and the huge and growing complexity of C++, I can sympathise with that point of view.
To say that there are no tools or libraries is exaggerating slightly, there are tools for Go (see http://golang.org/pkg/), and books, just not as many, which is quite normal for a young language which has just hit 1.0. For Rust there will be far fewer as it is even less developed, but that's to be expected. As you say if Go or Rust ever do become popular it will be over decades, not within a year or two.
From the outside, C++ appears to be such a mess that I actually cannot tell whether C++11 made it better or worse.
I don't think systems programming is going anywhere—I mainly stick to Python, but would like something lower-level available that I actually enjoy writing. The thought of having nothing better than C++ for the next however many years is terrifying.
Implying that you don't exactly even know the language, if it really is such a mess you think it is. I bet a bunch it really isn't.
> I actually cannot tell whether C++1 made it better or worse.
This really just shows the fact that you are clueless about C++ and what C++11 brings to the table. Whatever you think has no relevance. Not because your opinion would be less valuable, but because you can't be objective about something you don't understand. You just follow what you hear from others - often times those who are in the same situation. Hooray for circle jerking over how C++ sucks. This leads nobody nowhere.
This is a major problem with C++, but it's mainly a problem for people who don't write any C++.
So what does C++11 bring to the table? To mention some:
- Rvalue references, move semantics, constant expressions with constexpr
- Standard facilities for threading, async, futures
- lambda expressions, support for UTF8/16/32, uniform initialization
- std::chrono for various time handling facilities, standard random number engines and generators, hash tables, regular expressions, tuples
There's also plans to introduce more libraries to C++ next year, and evolve the language through libraries rather than the core language specification.
Many of the problems people face with C++ can be avoided, and people know it. Many of the problems in existing code bases are fault of poor design. (Blaming C++ for multiple inheritance because the designer shot themselves to the foot by not being competent at designing software is a prime example. It's not like the same functionality couldn't have been implemented via policy-based or component-based design for example. Easier to blame the tool than the user, I get that.)
Of course, those who use the language just avoid them and those who don't use the language keep bitching about them. Strange.
> Of course, those who use the language just avoid them and those who don't use the language keep bitching about them. Strange.
Dumb pointers are built into the language. They just look like an asterisk.
Smart pointers are, at best, something like `unique_ptr<...>`.
So C++11 continues to have the error-prone variant as the default, and you have to import a stdlib thing and put some ugly incantation on every pointer in your entire program to finally get memory safety. But you expect those who use the language to "just avoid" broken features like dumb pointers -- the features that have dedicated syntax, the features that take 92% less typing and reading effort, the features that have been around for twenty-nine years.
Your argument is that C++11 is great because they tacked on a bunch of stuff to fix the core language, and obviously I should just ignore the core language because the other facilities are so great. In fact, you deride anyone who uses the core language as merely not understanding C++ well enough or creating "poor design"—even though multiple inheritance has built-in syntax and component-based design does not. (Rust has no MI, and its traits look like they'll map quite well to components. Hm!)
You are blaming the user for not using the tool in a way it was clearly not designed, because that other way happens to work better. Maybe it's not just me. Maybe, just maybe, this tool sucks and you're so used to it that you can't believe anyone else would possibly not want to use it.
I'm interested in Rust because it lets me do systems programming without having to avoid the entire core syntax because it's all broken, without having to worry that whatever I'm doing might be bug-prone but only hanging around because C did it, and without having to deal with rhetoric like this implying that anyone who doesn't think favorite tool X is the height of perfection must just not understand it well enough. I've had my fill of that crap from the PHP crowd.
> So C++11 continues to have the error-prone variant as the default
Yes, and rightly so. What would happen to the existing code if the "default" pointers became smart pointers? Would they be unique? shared? weak? Also backwards compatibility with C would be gone, stopping people from using C++ as a better C with improved functionality. Of course, everything would break and some people would possibly even rejoice!
> Your argument is that C++11 is great
No. My argument is that C++11 is an improvement and that there's nothing better in the market which could be used where C++ is being used in, without sacrificing portability, efficiency, productivity and existing investment in skill and knowledge. As I've mentioned in various replies, I'd be more than happy to move onto language which let's me do what I'm doing with C++ - unfortunately no such language exists. C# makes me tied to Microsoft's platform(Mono is bullshit, don't even bother). Java ties me to Oracle and Java's own platform built upon JVM, compromises efficiency, forces programming paradigm and exposes to whatever problems the Java implementation may have now and in the future. D seems to be like C++ with some changes, less tools, portability, performance and libraries available. Needless to say Python and Ruby aren't even considered. Rust is very unstable, features come and go, tools don't exist, books don't exist, perhaps the whole language won't exist in 5 years. Go seems more mature and seemingly the most potent candidate, although with various drawbacks(no support for libraries, whatever written in Go can't be included with other languages).
> In fact you deride anyone who uses the core language as merely not understanding C++ well enough or creating "poor design"
Anyone who plays with fire and burns themselves while doing so can do nothing but blame themselves, I'm sure you agree. There's no denying the fact that using C++ correctly is actually hard. It's not so much because of the language itself(I'm not saying language hasn't got problems) than the ways it's being taught. For example, if you Google for C++ tutorials, you see things like naked new and delete, using explicit resource management where RAII would've been sufficient, not taking advantage of STL, ... Take a modern book dedicated towards learning C++11 from the ground up(e.g. C++ Primer, 5th edition) which actually avoids lots of problems and uses the language in a safe, efficient way. I'm sure anyone learning the language that way instead of from books dating back to mid 90's, from people who still consider C++ as "C with Classes" actually avoids lots of the problems you've mentioned. I assume I don't have to mention about actually designing software and the complexity of it regardless of the language. It's very loosely tied to the language itself, rather than the core concepts, requirements and benefits behind the design that it's clear that the designer is to be blamed for any issues.
> You are blaming the user for not using the tool in a way it was clearly not designed, because that other way happens to work better. Maybe it's not just me. Maybe, just maybe, this tool sucks and you're so used to it that you can't believe anyone else would possibly not want to use it.
The "tool" is flexible. In many cases as the programming language and practices evolve, we find better ways to do things and I think this is a good thing. This happens with every language. How would a Python programmer from 1997 compare to what we have today?
I don't consider the language to be perfect, but it does what it's intended to do the best what there's available. Feel free to provide alternative languages for systems programming in the domain in which C and C++ work in. Alternatively I wouldn't mind alternatives even for the domain in which I work in(3D simulations, games, computer graphics).
> and without having to deal with rhetoric like this implying that anyone who doesn't think favorite tool X is the height of perfection must just not understand it well enough.
A language does not have to be the height of perfection to be the best tool to do the job with. As it should be quite clear by now, I don't consider Go or Rust to be viable alternatives for C++ in many domains for the upcoming years. We both know why.
JLS7 is ~600 pages; the latest draft I could find (because apparently the actual standard isn't available online, a problem in itself) for C++11 was over 1200.
I very much doubt a version bump will stem C++'s decline; while it contains plenty of improvements there are no really radical changes. What are the changes that you think will make people who chose C or go over C++03 switch to C++11?
I really don't see where someone would pick C over C++ when starting a new project if not either due to 1) lack of (good enough) C++ implementation or 2) lack of confidence in using C++(this is personally a problem for me, as I've been programming in C much more than C++ and still feel unfamiliar with lots of things, the least not being the object oriented paradigm). Of course personal taste may differ, and this is understandable; I'd prefer more compact language but right now the domain I work in has no alternatives.
Nice, but you're 4 years late, sir! Everything can be viewed in a bad light if it's wanted to and we both know it. So how about actually talking about the bigger picture, and problems with programming languages and the actual art of creating large-scale software rather than trying to be smart?
Yossi, by his own words, is a whiner. The fundamental reason behind is attitude towards C++ is to stir up controversy, rather than to provide objective criticism. If his attitude was sincere, I'm sure he wouldn't have spent so much effort in mastering the language.
...which is completely fine when is not used as an attempt to debunk the argument, but show that the information is biased.
Any form of critique towards a biased source can always be countered with claims of it being an ad hominem argument - which it strictly speaking usually is - but that alone does not make the critique false or the original source any more reliable.
As an example, many of the points Yossi makes are subjective and opinionated and as such FQA is nowhere near an unbiased and reliable source of problems within the language. Nobody who actually wants to be serious about the subject cites FQA as a whole. At best, individual points he makes with which many agree with. Including Bjarne himself.
You seem to be using a definition of "declarative" that I'm unfamiliar with. The functional languages you target in the second to last paragraph are very different from the more imperative languages in the final paragraph, and I wouldn't consider either group to be "declarative". I'm left wondering what concepts you're attempting to criticize.
Having said all that, yes, I believe major commercial projects are started in those languages, though I have no idea if anybody plans them into the 2030s.
Functional languages are declarative. The point is that there are two kinds of languages; languages which people bitch about and languages which nobody uses.
1) existing codebase
6) programmer availability, resources and education
7) language reliability and future proofness(e.g. backwards compatibility, vendor and thus platform independence).
These are real problems when it comes to building reliable abstractions(that's the whole essence of systems programming, isn't it?), and thus far C and C++ have been the only languages which have been able to provide all of those the best.
When it comes to the future of computing from a hardware level, things may(or may not) seem a bit better; for example utilizing GPUs for general computing, using low-power ARM/x86 cores for parallelism. There are foundations for these things in C(and now C++ too) and libraries to help programming these things. How many years will it take to get a reliable Go or Rust support for programming a vendor-independent GPU? What's the overhead compared to say C or C++? The alleviating thing here is that GPUs and ARM cores aren't CISC machines so compilers and thus software is highly responsible for the performance, so with a good compiler you can get away with using less efficient implementation language, and get gradual improvements too.
I didn't expect that, I am almost surprised! Though, I was more after using Rust or Go for general purpose GPU computing via OpenCL for example. There seems to be some form of project for binding, but I certainly would not put my money on some random person doing the bindings. Very experimental and unreliable stuff.
This is definitely true, and the exact point I'm building my arguments upon. Are Rust and Go better languages than C and C++ for solving lots of problems, in many, many cases yes! But we can't use them. How frustrating is that!?
Of course there's a difference between being able to use a language and when mainstream starts picking it up. Considering for example C++, it wasn't only until mid 90's when it really took off, a bit more than 20 years after it was named C++ from C with Classes. Perhaps Go and Rust have their place in the stack sometime in 2030.
Maybe because that's what Google needs its own programmers to learn right now. Although, they should make a language that's meant to eventually replace Java/Dalvik for Android as well, and a language that's very easy to use and learn.
Yeah, absolutely. Go and Dart really both fit needs of working with large software and giant scales. As I think they've both said independently, conservative design was considered a design bonus. You can see why as it gets teams up-to-speed quickly, is less off-putting to project managers, and is more likely to benefit from experience surrounding how to write effective, readable code forms.
Stuff like Rust is awesome, but no-one yet knows what an Effective Rust book might look like, and you really need that sort of solidified design understanding to work. Code is write once, read hundreds of times, so that exciting wild west of "we don't have idioms yet" simply won't fly at a big company.