Why I love Rust
speakerdeck.comI want to spend at least 3-4 months learning a new language but just can't figure out if I should spent time learning Rust or Go. I am thinking more of it from a career perspective than interest.
Speaking as someone who has used both languages, I think you should learn both if you can. Rust will give you experience with low level systems programming (memory management, parallelism, etc.) Go will give you experience with network-facing backend code. Both languages will teach you concurrency.
Go is significantly more popular than Rust. But if what you want to learn is a popular language, you shouldn't be looking at either Go or Rust.
Disclaimer: I'm a Rust developer.
Perhaps a nice project to learn both is to write a (simple) Go compiler in Rust :)
In the same spirit as https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_...
Go is not a very complicated language. The main difficulty of writing a Go compiler would be to write the garbage collector, but you can easily skip that part by not collecting any garbage :)
Getting started writing a compiler is a bad idea outside LISP's and such that are ideally suited to it. Compilers are complex, hard-to-write programs. Best to do a series of utilities that each explore functionality one is likely to use in real life or just wants to learn about. The IRL stuff gets one used to the feel of the language and whether it's worth proceeding in. The other part is, well, fun and a learning experience. :)
This is good advice. I am totally confused by the Rust vs Go debate. They occupy such different spaces.
Because we have weird memories we all still remember Go claiming to be a systems programming language, which everyone took to mean "programming language you would use when you need to talk to metal" but which A) Go isn't suited for B)Rob Pike decided meant "programming language you would use to when you need to write a program"
Rust sort of went public around the same time as Go which automatically "made it" a competitor AND actually is a programming language you would use when you need to talk to metal.
So now people have tied them up in a PR battle.
I think there was the added wrinkle of "programming language made by the company that also makes Chrome" vs "programming language made by the company that also makes Firefox". Google's and Mozilla's browsers were/are competitors, so why wouldn't there programming languages be? Obviously, the two companies have completely different reasons for the development of the new languages, but I think that was overlooked at the time that Rust first came out.
Yup. It turns out that Google internally uses C++ for developing web applications (or at least HTTP API endpoints), which nobody on the outside quite internalized. So Go is a perfectly reasonable C++ replacement from the point of view of Google, but doesn't hit the majority of use cases outside, and it feels rather more like a compiled competitor to Python/Ruby/etc. to most of us on the outside.
Also, until about a year before 1.0, Rust had heavy focus on lightweight concurrency (à la goroutines), a garbage collector built into the language (or at least plans for one, complete with syntax), a mandatory runtime to manage those things, etc. You had to give up on the standard library if you wanted to use Rust code as a shared library in non-Rust programs. That changed fairly rapidly, and the last bits of that (like runtime removal) only hit a few months before 1.0, so people's first impressions of Rust were much closer to that of Go.
They're very different languages today. It is technically true that for both of them they are better than C++ for some things people have traditionally used C++ for, but once you get beyond that they're not that similar.
I'm going with your assessment of things as I think that's why it stays stuck in my head to a degree. The other reason is it was a modern version of Oberon: a simple, GC'd, system language ETH wrote operating systems with. Given that, I still assume an OS can be written in Go in current form or with small changes (eg runtime, FFI).
Hell, people wrote OS's in Haskell, Java, and C#. JX partly put the device drivers in Java. I'd be shocked if Go was only one that couldn't handle it.
I think the reasoning behind the debate is that, together, they mostly obsolete C/C++. Go takes the high-end and Rust takes the low-end, and there's no niche left for C to occupy in the middle.
I guess the real answer is, if you want to learn "the language that people will be using instead of C in ten years"... learn both of them.
I don't think so. Of course, there is space for Rust and Go. But that does not mean there will be no niche for C and C++. That is simply not correct. Ignoring C and C++ mean you are ignoring maybe billion $ industry around them . and That is simply wishful thinking.
>>Ignoring C and C++ mean you are ignoring maybe billion $ industry around them
Right, very difficult to move the inertia in any direction. The same is true about Java too.
But there are fewer reasons for any starting a new project to do it in C or C++.
Newer stuff replaces older stuff, Heck when C came along, there were languages with billion $ industry around them. C replaced them.
Sure, but you could argue the same for things like COBOL
As someone in the games industry, I don't see anybody moving towards either of these languages over C++, or really even any excitement over them. I'd be very surprised if Rust displaces C++ here, and put the chance of Go doing so at pretty much 0.
If anything, the current trend is moving more low level (rather than higher level, which these languages both are), as techniques like data oriented design becoming more mainstream.
Rust should be (and is, modulo wrinkles, I mean there's no fundamental reason) as low level as it gets. What makes Rust too high-level for gamedev?> (rather than higher level, which these languages both are)It's probably not too high level for game dev.
However, modern AAA game dev is largely about customising and upgrading large existing game engines, which are all C++ based. Rust could be used for them, but isn't, and the extra features Rust brings are not compelling enough to rewrite huge amounts of working code and suffer (re)training costs.
This is a hole many new languages find themselves in. JetBrains have come up with a very clever solution for their Java/Scala competitor Kotlin: the language was carefully designed from the ground up with perfect Java interop in mind (Java/Kotlin call into each other seamlessly, the IDE can refactor across languages, Kotlin uses the same standard library etc). And quite amazingly, the IDE can automatically rewrite Java into Kotlin. This isn't a party trick, it works very well.
I think if Rust wants/wanted to be a serious competitor to or upgrade path from C++ it'd have needed to take at least some level of C++ interop into account from the start such that Rust and C++ could be intermixed freely. AFAIK though, the best you get is a typical C export/import layer which is too trivial to be compelling.
Of course, it's a lot harder than connecting with Java because of the way C++ stuff is defined using header files. But at least basic interop could have been done.
If you want to be fully compatible with C++, you have to be fully compatible with all its issues and design mistakes. If those could be fixed without sacrificing compatibility, they would be fixed within C++ already. In case of rust, such compatibility would defeat the purpose of its existence.
Yes, this is a good point about AAA.
The issue with interop is on the C++ side, unfortunately, not our side. Until C++ has a well-defined ABI, it's not really possible.
It's not clear to me that it's impossible. The ABI isn't a huge issue; templates are, though. I can see a potential path forward by using clang heavily, but it requires a lot of thought.
Isn't Swift looking heavily into C++ interop? It might make sense to collaborate with them to get it to work in both languages.
Swift is implemented in C++, and uses LLVM stuff that we don't because it's not exposed in the C ABI, last I heard.
Well, sure, but how the compiler calls into libclang/LLVM isn't the difficult issue here. The more interesting issue is how, conceptually, the Swift or Rust compiler would use libclang to interoperate with C++ in a foreign environment. Once that's established, writing C bindings to whatever part of libclang is necessary should be straightforward.
C++ has a well defined ABI on many important platforms.
On GCC/LLVM based platforms it's standardised in specification documents. On Windows, I think the Visual C++ ABI is the de-facto standard.
Regardless, there are only a handful of top C++ compilers. Interop with even one of them would be of tremendous value.
I totally agree. As I mentioned in a sibling comment, maybe the right solution is for Swift and Rust to solve the problem together by using libclang in the same way.
To be concrete, I could envision some sort of bolt-on "inline C++" feature that libclang would expose to all LLVM-based languages. It wouldn't have to be principled interop any more than Objective-C++ is principled interop. It'd just need to get the job done.
Yeah, I mean, the basics of interop might be possible, it will just never be as robust as it could be if C++ had features better designed to play with other languages.
(This of course also affects Rust as well; we don't have a defined ABI either.)
Sure, you can't get completely perfect interop. However a LOT of real C++ codebases don't use or explicitly ban some of the trickiest features, so even partial support can go a long way. For instance, supporting the basic class/vtable layout C++ uses (or even just adopting the C++ ABI for Rust itself here) along with char* strings, would immediately allow you to call into a lot of real C++ APIs, albeit older ones.
Supporting C++ value types, even without templates, would in turn be enough to support quite a lot more. For instance Unreal Engine defines its own string types, as do Qt and so on.
Yeah, to be clear, I think such a thing would have value too. Just hard to get 100%, there are always gonna be caveats.
I guess Rust has many features people are only used to seeing in high level languages - and to some people that equals "too much abstraction" which equals "slow". But the thing is - Rust's "high-level" features are all compile time with either no or very little runtime overhead.
"together, they mostly obsolete C/C++. Go takes the high-end and Rust takes the low-end"
In that case some one just code "GoRust" language ^_^
Go is of Pascal tradition of simple, efficient programming languages. Rust has memory and concurrency safety. So GoRust would be...
Concurrent Pascal (1975) by Brinch Hansen http://brinch-hansen.net/papers/
...Concurrent Pascal used in Solo OS. It supported human review via readable syntax, type safety, safe ops on memory, and a concurrency system that caught race conditions at compile time. The runtime underlying the OS was about 4K with the OS itself concise enough to put in one PDF in source form. So, Hansen for the [1975] win in the GoRust competition?
Nah, just use CGo to link to a lower-level Rust library :)
I think you should learn Rust, because there are actually things there that you can't learn about in other languages.
1. How to manually manage memory more safely with aid from a borrow checker. 2. If you don't already have experience with an ML/Haskell descent language, it will teach you about more powerful static type systems. 3. General low-level programming concepts that you wouldn't know without experience in C/C++.
Whereas Go doesn't really have much to teach you. The community says it themselves: Go is a very simple language. Even if you needed to learn it for a job, onboarding new workers onto a Go project is really easy. So I don't think you'd add much to your resume just by tacking Go onto the list of languages you know. What Go can teach you about:
1) CSP - Communicating Sequential Processes. I believe this is the concurrency model behind goroutines and channels. But you can learn about CSP in other languages.
I've only started the read the canonical Go Programming Language book, but I believe that Go also permits shared-memory concurrency, it just advocates for CSP harder.
I actually think you'd go far to spend 3 - 4 months learning C++. Almost every language you can likely encounter in your career will use some feature that will get introduced to you in C++, especially modern C++, and, almost any language will be easier to learn and use after first going through a C++ learning curve.
Besides, C++ is still the big player, more than all others. Even Apple's new language Swift is written in C++. It's a good language to know something about.
It also sets you into a different category of programmers, from what I have found recently, since C++ techniques are not taught much in college programs any more (based on my conversations with recent CS grads), which really surprises me. It's a special skill that would set you apart if you know it.
The problem is that C++ is a language where the "top 150,000 most essential things to get you started with C++" is a volume that spans several book shelves. Even Bjarne Stroustrup allegedly rated his own C++ skills at maybe 7 out of 10. If you start with C++, you're committed to a multi year project, that's what it takes to advance from novice to junior level.
The whole C++ language is indeed a monstrosity designed by a committee that resulted from years of piling up "requested features", but with "modern" C++14 they try to narrow-down the idiomatic constructs to a smaller, more manageable set.
Sorry but this is just wrong. You do not need several years to get productive in C++. Very few professional C++ developers are using every feature of the language. You could spend a year mastering template metaprogramming alone, but do you need it? Not most of the time. Interfacing with good C++ libs (another reason to learn C++) does not require metaprogramming, and many other features fall into a the same category. Saying there are 150,000 required learning points is sensationalism and just downright false.
Junior level is when you know all language features, and are starting to learn the ecosystem of tools and libraries.
You're probably much smarter or more dedicated than me if you feel this level can be reached in a much shorter time.
I think you are missing the point. It is widely understood in the C++ world that no one needs to know "all language features" and in reality, almost no one does. It's not a language where that is necessary or expected because the language is large and has a tremendous range of uses, and no one needs all of it for a particular project or focus.
But you can most certainly learn all the basics of writing good C++ code, and interop with great C++ libraries and get real stuff done, in fairly short time. It took me about a month to go from Objective-C to C++ and start publishing iOS apps written almost entirely in C++. And if you don't need that, you can start writing command-line utilities in a few days at most.
this is really true in my experience. I worked on a large server for a few years and most of my work was spent doing pretty mundane things (mostly interfacing with other libraries(apis)). I certainly didn't use every feature and, like you note, most programmers don't. Sometimes I would come across a new C++ capability that was utilized and I would just learn and utilize it, but this depended on the feature and situation. In fact, the only thing that's really different about it (at least to me), was the constant concern over memory usage (and all of the make/build stuff). These are just parts of the language that you need to consider that are avoided in other languages (the dirty secret here is that regardless of the language, you still need to consider them). I liked C/C++ because you can pretty much do anything with it, but you can get to certain points faster with a different language (again, depending on the target usage). Language platforms capture programmer inertia, which is why big companies try to own them. However, in reality, since there are so many, most good programmers seem to be able to switch between them fairly easily (which is a good thing).
Junior level is when you know all language features
Wow, in that case I don't think I've ever worked with anybody who's ever managed to reach "junior level" in any language. What do you call someone with, for example, just a PhD in the relevant field, 6 or 7 years of professional programming experience and several successfully shipped products under his belt. And what do you call the guy that is obviously his junior?
When someone with a PhD in the relevant field, 6 or 7 years of professional programming experience and several successfully shipped products under his belt starts learning something new, he's a junior at that new thing.
My point is that knowing all of a languages features is neither necessary nor sufficient for getting real work done even at the highest level. I've worked with some pretty smart and experienced people in my career and non of them would probably claim to know every single obscure corner of their favorite language.
nice dodge. chewbacca defense!
> If you start with C++, you're committed to a multi year project, that's what it takes to advance from novice to junior level.
This is nonsense. Perhaps it's true to some degree if you try to "learn" C++ from tutorials of dubious quality rather than from a decent book.
You sound like someone who has never really explored C++ lookup rules.
Funnily I've been working on MLOC-sized C++ projects and almost never had a problem with lookup rules. On rare occasions where it was a problem, it was a compile-time problem and easily resolved.
In any case, these rules do not fall under what I'd call "junior-level" C++ programmer as the OP wrote.
> If you start with C++, you're committed to a multi year project, that's what it takes to advance from novice to junior level.
This is ludicrous. Depending on your back-ground and the amount of time you spend working in the language each day, a journeyman level competency can be had in just a few months. Honestly this sounds like a comment from someone who has not done much C++. Please correct me if I'm wrong.
I agree with GP and I've been doing C++ for a long time. There are a lot of dark corners that aren't a problem until they suddenly are. Most C++ devs don't really understand iterator invalidation, for example.
Or undefined behavior.
I guess it can be summed up as: C++ is extremely good at making people think they're writing safe programs.
This feeling of safety is virtually always incorrect in the case of large-scale software, and the huge stream of memory-related vulnerabilities that virtually all popular network-facing C++ applications have and continue to have is proof of this. There is no reasonable way to argue against this; the fraction of popular network-facing C++ software written by a large team that have had memory safety problems rounds up to 100%.
This is a weird answer to the question, especially since Rust very probably has whatever "modern C++ techniques" you were thinking of.
Learning C++ means you have to learn a lot about how to debug C++, and understand exactly what's going on at the machine, OS, and debugger level. Whether this is a productive use of your life is up to you.
I disagree. As others have pointed out, the demand for C++ jobs is still much higher than Rust jobs, so I think my answer still stands as a way to set yourself apart when thinking of a new language to spend a few months on.
Ideally, one would learn Rust and C++ both and see how they differ, and why.
> I disagree. As others have pointed out, the demand for C++ jobs is still much higher than Rust jobs, so I think my answer still stands as a way to set yourself apart when thinking of a new language to spend a few months on.
It's not going to be a particularly interesting thread if everyone who works in a language that trends higher than Go on Google chimes in to say "you should learn my language instead, because it's more popular".
> Ideally, one would learn Rust and C++ both and see how they differ, and why.
Aside from uninteresting language-specific details, C++ essentially doesn't teach you anything that Rust doesn't.
>It's not going to be a particularly interesting thread if everyone who works in a language that trends higher than Go on Google chimes in to say "you should learn my language instead, because it's more popular".
I think C++ is unique in that it is really not as popular as many new languages, not as trendy and as much in the news, and not even taught as much in college programs, yet, it remains the language where so many jobs are. This gives anyone with the desire to learn it a good and marketable skill that can make it possibly easier to find work and continue making a living doing software development. That does not apply to Rust, so I think it's a fair point to make to anyone who is asking about what languages are good to learn.
As for whether C++ has any techniques to teach that Rust does not, C++ is definitely a unique experience to go through and certainly gives a developer more insight into the actual machine they are working on in a way that few languages do.
> it remains the language where so many jobs are
"The" language where so many jobs are? It's one of many.
> As for whether C++ has any techniques to teach that Rust does not, C++ is definitely a unique experience to go through and certainly gives a developer more insight into the actual machine they are working on in a way that few languages do.
Can you name, specifically, a way in which C++ gives you "more insight into the actual machine" compared to Rust?
I think that Rust simplifies some things that you must do yourself in C++, and learning how to do them is valuable. At the very least, it will help you appreciate other languages, but it can also show you areas where you get manual control over performance in ways no other language offers.
And, perhaps most significantly, there are a wealth of C++ libraries out there that have no equivalent in other languages, and being able to use them is an education in itself.
The C++ programmers here disagree given how often they point out that C++ close to the machine is actually the C style of programming done with C++ language. It's actively discouraged by the C++ community in favor of the C++ style of programming described in Modern C++, etc. The C++ style gives low-overhead abstractions that increase safety and maintainability (in theory) while aiming for C compatibility and performance. Main libraries and well-written apps are big on metaprogrammed constructs.
So, learning to code professional C++ will not help you understand machines more. You'd have to learn C, basic OS/CPU structures, and which compilers produce for certain C statements. Maybe read Write Great Code by Hyde or some online articles. Learn C++ to understand machines? Not happening unless you microprogram a CPU for it on a FPGA.
As someone who has written a lot of C++ (and essentially no rust), I think you're mischaracterizing C++. It has a lot of magic that the compiler does for you under the hood, and even more if you are using libraries.
If you want to understand what is actually happening on the machine, I do not think it is the best choice. C would be much better.
> I think that Rust simplifies some things that you must do yourself in C++, and learning how to do them is valuable.
Given that you didn't answer the question, I think it's pretty clear at this point that you haven't used Rust. Rust is a low-level language with low-level control over memory and resources.
Speaking about C, since I never went too deep into C++.
The original assertion was:
> ...gives a developer more insight into the actual machine...
For better or worse, Rust feels like a reference is a proper abstraction over a memory location whereas C drives home that it really is just a number. Perhaps I don't know Rust well enough but, without unsafe, I'm not sure how I would refer to an arbitrary memory location or use pointer arithmetic to access memory locations relative to a known memory location in Rust. Vector indexes in Rust appear to be more than just syntax sugar for addition whereas C allows both array[2] and 2[array]. And I know that Rust will prevent me from accessing memory that's already been freed since it's one of the selling points of the language.
Now you can argue that Rust is mostly saving you from unpleasant consequences, and you'd be right. But the fact that C forces you to understand those unpleasant consequences teaches you something about the nature of the underlying machine. C makes you realize just how much of a "wild west" situation exists at that level. It would be very easy for someone to learn Rust without being confronted with that fact.
I certainly don't know Rust as well as C++. Some other fellows in this thread provided some features in C++ that you can't learn about in Rust, fyi.
> Some other fellows in this thread provided some features in C++ that you can't learn about in Rust, fyi.
Variadic generics and template templates are hardly interesting compared to concepts, pattern matching, and lifetimes. I use those every day in Rust, they simply don't exist in C++, and with the exception of lifetimes plenty of other languages have them too, so they're broadly useful to know. Variadic generics and template templates, on the other hand, are useful for a small subset of advanced library authors who have been programming in C++ for years.
If my understanding is correct, you can use any of those C++ libraries from Rust as well.
If those C++ libraries expose a C API, then yes.
Well, it may teach you why its a good idea to throw away old features every couple of decades :-)
OPs asked which language to learn from a career perspective, so C++ is good advice in that respect
You must say the same thing about COBOL in other threads. Demand for it remains high with people getting paid a premium in some areas for the shortage. Something like a billion lines of it out there. Microfocus is probably hiring, too.
So, anyone following your argument should skip C++ and learn COBOL because COBOL is easier to learn, in widespread use, and has jobs available.
Interesting point. I was curious about this, and turned to Wikipedia:
>In 2006 and 2012, Computerworld surveys found that over 60% of organizations used COBOL (more than C++ and Visual Basic .NET) and that for half of those, COBOL was used for the majority of their internal software. 36% of managers said they planned to migrate from COBOL, and 25% said they would like to if it was cheaper. Instead, some businesses have migrated their systems from expensive mainframes to cheaper, more modern systems, while maintaining their COBOL programs.
It was an extremely, easy-to-use language that even laypeople could write business logic in. Similar to how BASIC got so many people started. Except, Fortune 500 companies were writing all their backend stuff in COBOL on mainframes from the 60's onward. Needless to say, there's a lot of it around dependent on existing libraries, interfaces, language variants, compilers, etc. Porting it is huge risk. So, they just maintain and extend it.
Main vendor even has it on Visual Studio: http://www.microfocus.com/solutions/cobol/index.aspx
The job is boring, predictable, and 9-5-ish at most places. Exactly what some types of people are looking for. They figure they can play with the fun stuff at home. One person even jokingly made a web framework for it: COBOL on Cogs. So, yeah, I throw COBOL at anyone using the "use language X for users or jobs" argument to see how they react to what they're actually arguing.
Interesting that you at least looked it up and didn't go into denial mode. I'm impressed. ;)
Not really. From a carreer perspective you are 100% certain that there will be a lot of demand for C++ in 5 years (since the whole IT infrastructure is written either in C or in C++), whereas for Rust you are taking a huge bet.
Maybe my perspective is biased because I work in a very conservative industry, but a large part of C++ jobs in the next 5 years will likely be about maintenance/evolution of massive legacy C++98/C++03 applications. And you won't likely use a lot of C++14 or C++17, while on the other hand the rare Rust project might be a bit more exciting. But if you're primary motivation to learn a new language is to get a job, Cpp is surely a safer bet.
> a large part of C++ jobs in the next 5 years will likely be about maintenance/evolution of massive legacy C++98/C++03 applications
This is exactly right, and it's been true for many years now. That your old codebase is written in C++ is a totally legitimate reason to use C++.
Exactly, C++ has been around for a very long time, so much runs on it, depends on it, and it is not going anywhere any time in our lifetimes, I'm certain of that. That makes it a very valuable skill. You can always study the newer languages when interested in them (I find them all fascinating), but for a deep leg into the way the industry works at its core, I think knowing C++ gets you very far. Google touts Go a lot, but so much of Google's tools are actually C++ at heart (protobufs and Chrome for example), and Apple touts Swift and has its own frameworks in Objective-C and now Swift, but under the hood, so much of their toolkits and the language of Swift itself are implemented in C++; nearly all cross-platform games we know and love for a wide variety of devices and OS are C++ -- my point is that it is a crucial language and it does not hurt to understand it.
Rust lacks higher kind types which C++ has had in the form of template templates since 1998. Rust also lacks the equivalent of variadic templates. If you want to see where that is different take a look at generic tuple manipulation in C++11 vs Rust.
And Rust has other features that no shipping version of C++ has, like full-featured pattern matching, lifetimes, and concepts. These are features you will use hugely more often than template templates and variadic generics.
But really, what's the point? The reasons you'd learn a low-level systems language are to learn how to manage memory and resources, to learn how to explicitly lay out data and to understand how to program without a runtime. Both Rust and C++ will teach you these.
I think that is a great answer. I actually see some parallels between the relationship of Rust/C++ to Scala/Java. Both basically use the backend of the established language and provide an 'improved' language on top of it. Scala uses the JVM, and Rust uses LLVM.
What is interesting is that with the release of Java 8, a lot of Scala early adopters and cutting back their investment in Scala in favor of Java (for exampled LinkedIn). This is despite the fact that Scala is widely used in production, has a killer app in Spark, and allows pretty seamless use of the Java library.
Now compare this to Rust. Rust also provides an 'improved' language in the same space as C++ utilizing LLVM. However, what is interesting is the nature of the improvements. The biggest feature of Rust is the memory safety. However, the memory safety is not a productivity improvement as more of a safety improvement. Unlike garbage collection where you just do not have to think about memory allocation issues, Rust forces you to think about ownership and mutability. That same exact thinking will allow you to pretty much get the same memory safety in C++ using unique_ptr and shared_ptr and const. The difference is that the compiler makes you think about it in Rust. Much like Scala inspired the adoption of features for Java, you can see C++ adopting pretty much the borrow checker as a tool - see Herb Sutter's talk at CppCon 2015 - https://www.youtube.com/watch?v=hEx5DNLWGgA .
As the experience with Scala shows, the adopted features of the established language do not have to perfectly match the 'improved' language to convince people to migrate back to the established language. The adopted features just have to be in the ballpark. I think the new C++ tooling will be in the ballpark in much the same way that Java 8 is in the same ballpark as Scala and remove much of the impetus for moving to Rust from C++.
In addition, Rust is not as well positioned as Scala. Scala is actually deployed in production and has a killer application. Rust has no major production deployments of which I am aware and no killer application (the equivalent of Spark). In addition, while Rust can interface with C libraries, Rust cannot interface with C++ libraries unlike Scala which can interoperate with the Java standard library.
Rust has some brilliant aspects just like Scala has some brilliant aspects. However, C++ (like Java) is not sitting still but has been incorporating the best ideas. In addition, when people choose a system language, they are inherently conservative because the system they are creating will typically be long lived and mission critical. If you are writing something that you hope will power your company for the next 20 years, do you want to go with a language created and driven by Mozilla with no major use in production, or with the language that powers Google, Microsoft, Apple, and Facebook?
Here is what I recommend. Learn C++11/14/17. Learn Haskell to really open your mind to what is possible. Learn Rust to learn about the borrow checker. Then apply what you have learned to make yourself a better C++ programmer. Some of the best, most insightful C++ programmers I know are people who are actually well-versed in other languages, especially functional programming languages.
I think the new C++ tooling will be in the ballpark in much the same way that Java 8 is in the same ballpark as Scala and remove much of the impetus for moving to Rust from C++.
I think that you extrapolate from an incorrect analogy. Java is a relatively simple language (except the mess introduced by generics through type erasure), that is mostly understood by regular practitioners. Java suffered far more from the lack of modern language features than technical debt. Consequently, it benefitted from language extensions tried first in Pizza/Scala, etc.
C++, on the other hand, is a very complex language as a result of inheriting C, the lack of deprecation of misfeatures for compatibility, and perhaps questionable design choices. C++ suffers not so much the lack of language features (though support for real algebraic data types and modules would be nice), but from complexity. Complexity of the language can only be reduced by breaking compatibility.
"However, the memory safety is not a productivity improvement as more of a safety improvement."
I disagree. It frees you from chasing safety bugs and allows to invest more time in the features and that's clearly productivity win. For example rust does not suffer from compiler bugs as much as compilers written in C/C++ used to. Chrome and firefox developers spend a lot of time fixing buffer overflows and are likely to do this for many years to come. They certainly could do something more productive for everyone's benefit.
> you can see C++ adopting pretty much the borrow checker as a tool - see Herb Sutter's talk at CppCon 2015 - https://www.youtube.com/watch?v=hEx5DNLWGgA .
I have a lot of questions about this tool, both in terms of soundness/expressivity (how do you deal with shared_ptr and similar things if your goal is to statically guarantee no-alias on function entry) and in terms of practicality (the massive subsetting it requires basically makes ISO Core C++ an entirely new language).
Also, Herb's claims about the ISO Core C++ lifetime profile requiring fewer annotations than Rust were incorrect.
I gave basically this exact answer last time you posted a variant of this same comment on the last Rust thread.
Anyone who's actually used Rust, C++, Scala, and Java knows that Rust and Scala involve considerably less suffering than their counterparts. The "adopted features" don't change the fundamental problems.
Java 8 lambdas are fundamentally broken due to checked exceptions, and the likelihood that checked exceptions are going to be removed from the language is essentially nil.
Likewise, Rust error messages are already better than C++ compiler error messages, and the nature of C++ template expansion makes that unlikely to change.
Learn what you want to learn... not what large companies have decided to adopt (or not) based on a number of factors that have nothing to do with the quality of the language or its educational value.
This may be because I'm too close to it, but the Core Guidelines are similar in ways, but also very different. Preventing data races is an explicit non-goal, for example, whereas in some ways, it's the focus of the borrow checker.> you can see C++ adopting pretty much the borrow checker as a tool
Dropbox is the latest production user, as of last month. And it's serious production usage: how the bytes get stored on disk, basically the core of the whole business.> Rust has no major production deployments of which I am awareI'd really like to know how well that works out at Dropbox. How honest and public do you think they'd be if major data losses resulted from Rust crapping out on them? I'm not sure about them but lots of businesses keep such things on the DL.
I think it's a risky move. I'd have first deployed existing, native code along with Rust in parallel using the data splitting technique so some is saved with original and some with Rust. Any compiler or library related issues on Rust side would be caught without data loss. I wonder if they did this in alpha stage and how long that lasted.
I mean, I love seeing Rust in production and some success stories would be great. It's just... wow, that's pretty mission critical for what I gather is still a beta-phase tool. I'd be testing on the middle or front-end layers first given they're usually stateless(ish).
> I think it's a risky move.
> It's just... wow, that's pretty mission critical for what I gather is still a beta-phase tool.
I think this is very '90s thinking. Extreme "if it's not C++, you can't deploy it!" conservatism about programming languages hasn't been true for well over a decade. Paul Graham has written some nice essays about this very phenomenon.
Also, Rust is not "a beta-phase tool".
New languages are much easier to deploy since the PL Renaissance. There are a few holdout industries that still stick with C++ no matter what, such as games, but they'll come around eventually. :)
You've been in discussions on this forum where I slam both C and C++. I'm clearly against it unless I absolutely have to use it due to its issues. That's why your strawman is more amusing than most. My actual argument was that new tools are usually unstable in terms of features, implementation bugs, and (with compilers) performance. So, default recommendation for mission-critical apps are mature tools whose strengths and weaknesses are well-understood so pro's can use them robustly.
Back to beta-phase claim, you're saying the core features and compiler of Rust are no longer in development or testing? Totally stable now with only extensions, library features, and optimizations being added? If so, that's good news and I'll drop that claim in the future. Otherwise, it's in the beta phase. Another hint would be existence of any bugs with core functionality in your compiler or libraries.
Again, though, if the spec and core functionality are frozen with all bugs fixed then I won't call it beta. Is it there yet?
Yes, 1.0 is stable and the language will not change in backwards incompatible ways. It's been that way for months (google "rust stability deliverable").
"All bugs fixed" rules out every language in existence except CompCert, so I don't think that's a very interesting metric.
Good to know on stability part. Far as bugs fixed, it's more on the lines of day-to-day use of the language in common scenarios. Are people getting unnecessary troubles out of the compiler? Typically don't for most languages as they work out most of them in common idioms and library functions in first, few years. If they're serious rather than 1-3 people's hobby, that is.
I certainly won't expect it to be bug free. Nice comeback with CompCert, though. ;)
I've seen rust compiler bug once and that was long before 1.0. The only issue now is that some important API's are not yet declared stable (RFC still being open), so many 3rd-party libraries target nightly and won't work in stable. This is however matter or 1 or 2 releases, and proves that rust developers take this matter seriously and don't wont to stabilize anything they aren't 100% sure. For all practical purposes rust is usable now, and more and more people are using it - certainly more then 3. Generally looking at rust projects on github, most of issues are feature requests. I don't see issues with crashes or panics, while I know plenty for similar projects written in C, at least in their early days.
Thanks for the detailed assessment. Sounds like a high quality, Beta to me. I also like the good things I keep hearing about the quality of libraries, etc.
Yes, this is how Dropbox tests all of their features, and they did this with their new Rust-based storage engine as well. This tool has been in development for over a year by now and has seen extensive multi-stage testing (at first handling only a few terabytes of data, then "just" petabytes, and now exabytes).> I'd have first deployed existing, native code along with > Rust in parallel using the data splitting technique so > some is saved with original and some with Rust.I was expecting they probably did given what's on the line. Re-reading it, I realize it probably didn't come off that way. Gotta work on that.
Thanks for the confirmation, though. I do look forward to reading the experience report. Hoping they include data on all key attributes vs prior language: productivity, debugging time comparison, CPU use, memory use, integration issues, and any changes in defect rates. Community evaluating Rust needs that data for something at this level.
The project lead already said on Reddit that if Dropbox loses data, it's now Rust's fault, so... :)
The project was a whole team of engineers working for almost a year, with extensive testing. At least, that's what I've heard. So like, I think they did exactly what you said, it's just that it's ready by now.
Oh shit! That's one hell of an endorsement [in the making]. I bet the excitement and suspense are thick in the office, eh? Hope it works out for adoption reasons.
I appreciate that. It has some good details. Gotta leave to get some work done but I'll take the time to drop you a compliment related to this:
"Edit: also worth adding that he Rust core team has been amazingly friendly and helpful. We've had several meetings with them where they came to our office and basically said "how's it going? what do you need? open up your laptop and show us your biggest problem." The project is under very good management."
When Rust was being developed, the two languages that got me most excited as next-gen, systems tech were Julia mainly and Nim somewhat. They had a great choice of features balancing all sorts of attributes as PL's that might get easy adoption as C++ alternatives. Thing is, many blog posts reported their communities and dev teams were downright vicious on everything from questions to compiler bugs (wtf!?). That made it a no-go as there's an upper-bound on how good those projects can get building on such a creaky, hostile foundation.
That leaves Rust as my default recommendation for new, non-critical projects in this space. Like Dropbox employee, what I've noticed is the two of you on Rust teams here are unusually helpful and respectful compared to many in PL communities defending their work. Even pcwalton when he's clearly less than happy with my comments. ;)
The combination of brilliant design and seemingly (from my little exposure) excellent community is why I promote Rust. So, keep up the great work all of you! :)
Thanks so much. :)
While I'm bullish on Rust being a big language in the next few years, there's not much production use yet -- it's still pretty immature from a production tooling point of view.
Go, on the other hand, has a lot of adoption. So if you're looking for a language to use on the job today, it's gonna be Go.
> it's still pretty immature from a production tooling point of view.
I think that the production tooling for Rust is pretty good. For example, it has a package manager that everyone uses, with features like lockfiles that are specifically designed for production. Not many languages have this.
It's undeniable that Go is more popular than Rust, but I think "production tooling" is not the reason.
Rust and Go are going into different directions.
Rust is trying something new and Go tries to only use the stuff that worked in the past.
It's no surprise that people favor Go instead of Rust.
Also the last time I saw a video about a low level language discussion, only Rust had a dev there nobody really knows. C++, D and Go had prominent people speaking for them.
The tooling really isn't the problem, as far as I can tell, Cargo is really one of the best package manager out there.
> Also the last time I saw a video about a low level language discussion, only Rust had a dev there nobody really knows. C++, D and Go had prominent people speaking for them.
They were each represented by a prominent member of their language design team. Its tragic that more people don't know of Niko Matsakis, but his blog is one of the best resources on the design of the Rust language: http://smallcultfollowing.com/babysteps/
"Also the last time I saw a video about a low level language discussion, only Rust had a dev there nobody really knows. C++, D and Go had prominent people speaking for them."
That has nothing to do with anything.
"Rust is trying something new and Go tries to only use the stuff that worked in the past. It's no surprise that people favor Go instead of Rust."
That's a good point. Anyone doing something critical wants low risk. Using a proven tool or one with proven concepts is lower risk. Go's methods were proven in Pascal, Oberon, etc. So, Go is less risk.
Not to knock Rust in any way with the above. Might be safer in long run due to design and improving toolchain. However, there is a risk perception and a real issue of new concepts taking time to spot then eliminate problems. So, I encourage Rust for systems use on less critical stuff right now but was shocked Dropbox uses it in storage functions.
> Go's methods were proven in Pascal, Oberon, etc. So, Go is less risk.
Totally disagree. Rust's ideas are tweaks of decades-old research. These tweaks are what make it interesting and constitute research in their own right, but Go did that too with their tweaks to CSP and interfaces.
You disagree that the basic functionality of Go, including type and memory safety, have been proven by prior language and production deployments? That's my basic premise. If Pascal/Oberon-like languages and GC's are proven, then one that's very similar to them will likely maintain those properties and deliver the same results. That's supported by the number of amateurs that ported and re-implemented Oberon OS & compilers successfully in 6 months to 2 years at ETH.
Whereas Rust uses a combination of proven primitives and exotic techniques to achieve its goals. The exotic stuff, integration strategy, and implementation are new territory that exposes a level of risk a tried-and-true method (eg knock-off Oberon) doesn't have. It's new and unfamiliar territory to programmers at large even if some methods were seen in academia (eg Cyclone). It must be shown to be effective in terms of daily usage, standard libraries, and tooling because it's such new and unfamiliar territory.
When it is, as I have confidence in the team(s), it will then have a different argument where it eliminates way more risks than it introduces. Already has it at application level if compiler is robust. Overall thing needs more deployment, though, so people can see if it lives up to it, how much, and in what scenarios. That's the risk perception I'm talking about. Right now, it's a big unknown to many outsiders compared to traditional languages and platforms.
Rust is actually pretty conservative regarding "new stuff".
Every single feature of Rust, with the exception of the borrow checker, has been around since the 80s.
Even the borrow checker is based on linear / affine types that had been researched in other languages at least over a decade ago.
Go is really easy to learn if you're coming from a scripting language. It's used for a lot of server-side processing. It's probably more immediately useful than Rust if you want to get work.
Rust is elegant and the future of serious programming, but not mainstream yet.
I can't wait for a few weeks, when Dropbox should hopefully be giving a status report on how their new production deployment is going.> there's not much production use yet
Disclaimer: I say this having spent much of last year learning Go and the last couple months learning Rust. I'm a big fan of both languages. I see Go as my go to language for more situations right now, but I think that once Rust has matured a bit more, I'll choose it for more and it will probably become more useful to me than Go. I doubt I'll ever get to the point where I'd choose it for everything over Go, but I can see that possibility.
That said, if you haven't already, I think you should learn Haskell instead. Learning Haskell, for me, was the biggest departure from my previous programming experience. It forced me to re-examine more of the things that I thought I knew about organizing my thoughts into a program. And while I don't feel that I ever really got good at Haskell, I feel that my time learning Go and Rust has been so much more valuable for having learned Haskell first.
It's very unlikely that you'll find a job programming Haskell...there are a few, but not many. But I feel confident in saying that learning Haskell will make you a better programmer in whatever language you do end up getting paid to write.
That said, if the choice is really between the two, I'd probably say learn Go. 3-4 months into programming Go and you'll probably be quite adept with it. 3-4 months into programming Rust and you may just be getting past the phase where it takes you 10 minutes of fighting the borrow checker to get relatively simple code to compile. I'm a couple months into Rust and I feel like I'm a least 6 months away from being productive with it.
I've programmed only tiny bits in Go and Rust, so I will not comment on those languages. My main programming languages have been C++, Java, JavaScript and XSLT. Going from that background to Haskell is mindblowing. The language is very clean and there is very little mental capacity needed for worrying about errors because many errors that are possible in other languages are ruled out entirely or hard to make in the first place.
Currently, I'm writing a website with Yesod. In Yesod, the URLs on the site are grouped in types and database queries are constructed from these checked types. Any change in database scheme will simply give a compile error.
Rust also sounds attractive, but I think the web stack is not as nice as Yesod yet.
> 3-4 months into programming Rust and you may just be getting past the phase where it takes you 10 minutes of fighting the borrow checker to get relatively simple code to compile.
This exactly is why I can never get past the first couple weeks of playing with Rust. Every few months I revisit it and every couple weeks after that I put it aside again.
When I was first learning C++ I spent a huge amount of my time inside the debugger trying to figure out why a pointer wasn't ... pointing. There was always a reasonable explanation that way my fault and if I had just understood what my code was really doing I would have coded things right and it wouldn't have crashed.
Now we have Rust that essentially takes away that entire problem. Just wipes it out by way of a clever compiler. Only now we substitute this same learning curve "debugging" the compiler rather than debugging memory space. (Probably a better trade-off in the long run. Rust sort of bets on that being true anyway.)
Go does not suffer from either of these traits. For me, Go is not often a "fun language" to code in but it's eminently practical and is remarkably fast to pick up for what it does express. I've ported a couple pieces of C# application systems to Go and they've worked really well. But it's kind of a grind unwinding the higher level abstractions from C# into the more primitive Go space.
I wish there was some way to bury Rust's borrow checker for those parts of an application where you don't want to care about it and then surface it gradually when you do want it. Because the elegance of the rest of the language is what pulls me back every few months.
I'm always interested in trying to figure out how to explain these things better, if you ever want to vent some frustrations at someone :)
The problem with that is, if you did, you're back to> bury Rust's borrow checker for those parts of an application
What I can say is that after you get over the hump, the borrow checker isn't really a big deal. Or rather, it _is_ a big deal, but when it errors, I know it's caught a bug for me, and I can just fix it without much effort. Small comfort for those before that point thought :/> I spent a huge amount of my time inside the debugger trying > to figure out why a pointer wasn't ... pointing.I swear I've seen more than one person gripe about this. Mostly from a change of thinking but it seems recurring. Might hurt adoption. I'd have expected Rust proponents to have a link on-hand for this to a guide that teaches this stuff in a way to reduce the effect. To be clear, this is not a critique of the Rust team so much as an observation of a larger problem in PL adoption that might be affecting Rust.
The trick, IIRC, was to have some smart people create a series of programming exercises that are complex enough to be a learning experience, teach a subset of the language at a time, and gradually let the concepts sink in. Practical Common LISP and Land of the LISP do this pretty well for a very confusing language. Rust will probably benefit from such a work, even more than CL. Just a suggestion in case someone's not working on it. ;)
That stuff works wonders for ease-of-adoption but such writing takes talent to produce. Takes someone with strong, tech skills who can also break anything down into English a layperson can understand. As in, it's really a series of consistent abstractions that form an effective, mental foundation for using and applying the language. Not regular definitions and examples but a true, gradual, practical process. Hopefully, you've seen such a great work vs a regular, language guide so you know what I'm talking about.
I mean, yeah, I can link you to several. But reading a bunch of rules isn't the same as programming with them for a long time. Even once you understand the rules, the compiler will still catch you. If humans could reliably program safely without the compiler being involved, well, Rust wouldn't need to exist; C and C++ code would be written in a safe way.> I'd have expected Rust proponents to have a link on-hand for this to > a guide that teaches this stuff in a way to reduce the effect.Anyway, like I said, I'm doing my best. More experience reports is the only way that I can do that, basically :)
I'd actually like to have those links in case I take up Rust or someone I know trying it gripes about the problem. Good to have them stashed away.
I see what you mean, though, if it's just rules you have to memorize and apply in many situations. Might be potential for my proposal but I'll take your word for now.
"Anyway, like I said, I'm doing my best. More experience reports is the only way that I can do that, basically :)"
Makes sense.
The official docs are https://doc.rust-lang.org/book/ownership.html and the following two sections. They explain the basics. I'm currently working on the next draft of the book, which will be more in-depth.
http://chrismorgan.info/blog/rust-ownership-the-hard-way.htm... and http://codrspace.com/buntine/aha-understanding-lifetimes-in-... are two blog posts that I can remember.
Emailed an experience report to your profile address. Hope it helps.
From a career perspective, Go is currently the language you'd want to learn. Here's my list of some of the largest companies from a few months ago, excluding a bunch of Chinese ones I haven't heard of (of which there are many, considering that China is most likely Go's largest adopter (http://herman.asia/why-is-go-popular-in-china)).
Walmart, Apple, Facebook, eBay, Intel, Google, Mozilla, IBM, Microsoft, DigitalOcean, Zynga, Yahoo, BBC, VMware, Uber, GitHub, Getty Images, Twitter, Stack Exchange, Docker, SpaceX, Baidu, Qiniu, Imgur, CloudFlare, Bitbucket, Dell, Twitch, Dailymotion, bitly, Cisco, Verizon, Dropbox, Adobe, New York Times, HP, Canonical, Cloud Foundry, 99designs, BuySellAds, CoreOS, MongoDB, Basecamp, Rackspace, Booking, MalwareBytes, Kingsoft, Iron.io, OpenShift, Heroku, Square, Spring, Tumblr, VMWare, Symantec, Comcast, CBS, SendGrid, Digitally Imported, Pivotal, Couchbase, Koding, Shopify, Shutterfly, MaxCDN, Linden Lab, SolarWinds, IMVU, EMC, Teradata, and I'm sure many more which I'm unaware of, are all using Go to some capacity.
HN didn't like your link touching the parens: http://herman.asia/why-is-go-popular-in-china
Ah, cheers for the correction, it's unfortunate I can't edit it =(
Career wise, you should pick up popular languages, Java/C#/Python/Ruby/JavaScript.
Between Go and Rust, I think you should pick Go because there are a significant number of developers from Python/Ruby/JavaScript enjoying programming Go. Many startups start using Go[1] and couple of universities use Go in their classes[2]. Rust targets system development primarily occupied by C/C++ developers. Many still prefer C++ and I rarely see Rust job.
[1] https://news.ycombinator.com/item?id=10822019
[2] https://github.com/golang/go/wiki/Courses
Edit: I may be biased since I enjoy programming in Go.
The TIOBE Index for January, 2016 has Java at number one. Rust is at 47 and Go is outside the top 50:
Visual Basic.NET more popular than Javascript? Assembly language more popular than Ruby? That doesn't seem right to me.
I don't find it too surprising. Check out IEEE Spectrum's index from 2014:
http://spectrum.ieee.org/static/interactive-the-top-programm...
You can break it down by classes of development (web, mobile, enterprise, embedded) as well as weighting (Spectrum, trending, jobs, open, custom). Spectrum's index (even though it's from 2014 and includes things TIOBE doesn't like SQL) isn't so very different from TIOBE's index.
TIOBE is stupid. Better to look at job sites if you are choosing for career purposes.
Go is probably a difficult term for TIOBE to get it right.
It absolutely is, but there's even more to it than that. From their documentation (http://www.tiobe.com/index.php/content/paperinfo/tpci/progra...):
"In order to filter out false positives, two mechanisms are used. First of all a confidence is defined for a language. By default the confidence is 100%, but for some difficult search queries such as "Basic Programming", the confidence will be lower. Apart from the confidence, sometimes also exceptions or mandatory additions are used to weed out false positives."
What they do is that add the term "+Google" to the search terms, yet for the other incredibly popular word "Rust", they don't add "+Mozilla". TIOBE is laughable.
Can they get "C"?
TIOBE is bullshit.
Its based on search engine 'search' text typed by users. 'Go' and 'Rust' are both words used for a wide variety of purposes apart from programming languages. Same with Python.
Don't trust TIOBE on these things.
Go is a lot easier to learn than Rust, and there are jobs programming Go available now. This means that you could be working professionally with Go quite soon.
Rust is more challenging, and there aren't many jobs available yet. But there is a possibility for Rust to displace C/C++ for certain classes of applications, and that is a very big deal. Also, skill in a more difficult language is a scarce commodity. If Rust does take off and you're one of the relatively few people who understand it well, this would make make you quite valuable.
One perspective could be that Rust is the more interesting talking point, even if you don't work on it in the job you are actually applying for. But if you purely want to get a job in one or the other, Go is currently much more widely used. I have hopes that this year will see a large jump in industry adoption of Rust, but that still remains to be seen.
But as others have said - pick the one you think you'd enjoy the most. Learning anything is good. And why not try a bit of both?
(Spoken as a contributor to the Rust ecosystem)
Interesting point there. All things being equal, I would favor someone who is learning Rust over someone who is learning Go--even if I were hiring for a job that involved writing Go!
Learning a single tool is a small value proposition to an employer. Showing an employer that you can learn a tool quickly and effectively is a large value proposition. Either one would do that.
Pick the one you enjoy most.
If you don't have many languages under your belt (and wanting to spend 3-4 months and asking for advice what to choose suggests that), you don't really want to go with a language that popped semi-stable only several months ago, hence will be most probably a subject to deep changes (either in the language itself or in standard library). Rust is not (yet) the way to go.
Rust is more than semi-stable: we take backwards compatibility very seriously. It will not be subject to deep changes from here on out, or at least, those changes will not break existing things.
> we take backwards compatibility very seriously.
You're yet to display that. Half a year is too short time to give that confidence.
Theres two components of "display that": process and follow through.
On the first point, we've set up a lot of tools and process to deal with stability, including testing releases against all open source code in existence. It's not perfect, but it does demonstrate commitment.
The second is the actual follow through. Due to said tools, we can calculate exactly how good we've done at it: so far, it's something like 97% of all code that was ever published still builds with 1.5. I'm on mobile so I don't have the real number on me. And that breakage was due to soundness updates, which we introduce over multiple releases, starting with warnings, so there's time to adapt.
Yes, it's early days, but that doesn't mean that you can't say anything.
> Rust is not (yet) the way to go.
Not sure if that was intended, but that was one epic pun!
It's unfortunate that they're often talked about as comparable things (as Go vs Rust) because they're totally fundamentally different languages, including what spaces they target.
I think part of this is due to Google initially trying to position Go as a systems programming language and sorta like an easier C.
In reality, Go is so far distant from C or C++ that it would be better to describe it as Java related honestly.
The real question is what do you want to do or why do you want to learn.
Do you want:
* Something where you can quickly produce working code
* Something with a large, complex, and questionable quality ecosystem (as ruby/python have, but a smaller scale)
* Something that's pragmatic, but not elegant
* Something that's well suited for writing a webserver, cli tools, or daemon
* An ecosystem of people who do not like complicated languages and rarely talk about complex language-theory concept
* Something that fills a similar role to python, ruby, java
* Something that has a massive foothold in the docker/container ecosystem
* A language driven by a semi-opaque "open source" process with a big company and closed doors at times
* Really easy to use concurrency (but also easy to shoot yourself with)
* Nice editor integration, autocompletion, etc.
Well, Go wouldn't be bad to learn
Do you want:
* Something where you'll actually learn new concepts, ideas, and be challenged in some ways
* A fledgeling library ecosystem where the libs that exist are decent quality, but most just don't exist
* Lots of opportunities to contribute
* A community-driven project where your opinion can make real changes happen
* A powerful macro system
* Actual type safety! With real algebraic types!
* No GC pauses
* Elegant error handling and abstraction powers
* Something it's hard to write working code in, but once it compiles it's probably pretty good
* Something great for writing an OS or low level tools in, and mediocre for webserver, cli, etc currently
* Something to replace C++, possibly D, possibly ocaml
* A language that is technically an ML but doesn't feel like one
* A super-smart community willing to talk about some of the coolest topics in language design and CS
Rust could fit for you
Grain of salt, I write lots of Go and am working on getting to know rust better still.
To all the people saying "Go is used professionally, rust isn't, don't learn rust from career perspective"... there's another axis!
You also have to consider what skills you'll pick up with each. Learning Rust will improve your ability to write safe C++ and help you reason about some types of problems in all other languages, so even though rust itself isn't directly marketable, the skills you get will be helpful regardless.
Learning Go will help you reason about actors a little and some problems in other languages, but not nearly as many and, frankly, the community for Rust will teach you a lot more about everything.
What languages do you know currently? This will probably be an unpopular opinion but unless you know more than you can count on two hands, it's unlikely that Rust or Go will be give you the best ROI if your focus is career enhancement. The largest career ROI is probably in getting to advanced-intermediate level in a couple of the following (in absolutely no order, I intentionally put ones I don't know first):
- Python
- Ruby
- JavaScript
- PHP (especially for WordPress if your focus is web)
- C#/F# and the .NET ecosystem generally (especially for corporate)
- Java (especially for corporate)
- VB.Net if you want a government job
- C/C++
- Enough SQL to do whatever you want with the above
You forgot to include JavaScript. I don't think that one should be excluded at this point.
You are correct! I added it.
What kind of projects to you want to work on (from a career perspective)? Rust seems to trend towards more systems programming tasks while Go seems to trend towards network server projects.
From a career perspective, I think it depends what you want to focus on in your career.
Go is actually very diverse in its applications, but certainly has the edge on rust for building web type applications.
I learnt Go in 2014 (largely by doing HackerRank puzzles) and its good to have it in your repertoire,
But right now I'm interested to learn Rust, because its a total different approach to anything I've ever done before.
I learned Go but now I am more curious to try out Rust. I never ever thought I would be learning so many languages including Javascript apart from Java which I know. And I am glad that because of simplicity of Go and Javascript I am much more confident of my abilities to learn new things and comfortable to try out new languages, which wasn't the case before.
You'll probably learn more if you choose Rust, but from what I've seen, way more companies use Go at the moment (since you mentioned this was from a career perspective).
What I really love about Julia Evan's posts/talks is how refreshingly honest she is
Good presentation with a great, artistic style. Also liked her articles about speeding Java up and "A/A testing."
Far as this one, the only correction I have is regarding the slide that says you can't write an OS in Java. Several have been written w/ JNode and JX OS coming to mind immediately. JX is my favorite given its interesting architecture is mostly compatible with high assurance requirements. Just needs a high assurance implementation. A re-write of such an architecture in Rust might be interesting. Or SPIN OS as it was done in Modula-3 before.
Yes indeed, and of course we must not forget Singularity/Midori which were implemented in a derivative of C# and .NET
I'd really like an OS built this way to become competitive. 64 bit flat address spaces and fully type safe designs really let you simplify things a lot in some fundamental ways. And you'd be able to run existing Java desktop apps without much in the way of porting effort.
Unfortunately all the Java OS's out there are hobby/academic projects that never got very far beyond a basic window manager.
Yeah, that is unfortunate. JX OS at least might be useful for single or minimal purpose appliances. Maybe soft-real-time or non-real-time embedded, too.
Singularity, esp Midori per Duffy's blog, were the biggest pushes into an inherently better OS's for desktops. I hope we see more Midori move into Windows or other tech.
Another great piece of content from Julia Evans :)
I like the idea of rust but what does this cartoon have to do with anything? Am I missing something?
It's a presentation.
This should be made into comics strip "RustOS" ^_^ Thanks for fun read.
I know C++, and have never encountered the 'let' keyword, until I tried some haskell.
What does let mean ?
It just means to bind a variable:
In Haskell, it's used for temporary definitions, or pure definitions in do blocks:let x : u32 = 0;let f = \x -> x + 1 in f 2
Rust is Pyramid scheme