Right now Go seems to be on an upward trajectory, and despite its ugliness and how primitive it is, it is the job which can pays off when hunting for jobs.
For example, I didn’t have any idea how to do parallelism and concurrency correctly in C++ until using them in Haskell and porting the ideas back over. Same goes for a lot of techniques that were easier to learn in other languages and translate over, like writing parsers, implementing constraint solvers, enforcing complex invariants with types, &c.
I see Golang replacing Java longterm and Rust replacing C/C++ (yeah, even C) due to the memory safety and preciseness + speed it offers. It may never be truly C speed, but from where I stand the tradeoff is worth it (and when it becomes NOT worth it, rust/c interop is SUPER easy).
While I like Rust a lot, I think it's definitely not the language to learn if you want a job right now. If you want a job right now, go learn Java. Unfortunately, depending on the company you go into, you can basically throw away the next X years of your life working with uninsteresting/stagnant codebases, unmotivated peers, and clueless management -- OR you'll find companies that are using Java in a progressive way.
If you want to invest in a language that will likely become a big player in the next 10 years, and is soundly written, maintained and progressed in the open, then commit to rust.
Also a sidenote, most good managers/engineers realize that syntax doesn't actually really matter. Good engineers get up to speed in languages they've never used in days/weeks -- if you know the paradigms, and how to design good programs, it's a matter of just changing what you type.
Knowing X language isn't what makes a good developer, it's knowing some sufficiently multi-paradigm langauge X well enough that you've moved past the basics and started re-discovering paradigms, design patterns, and answers to problems in a few problem domains.
True enough as far as it goes. But in practical terms, as platforms have multiplied in number and increased in surface area, being a useful and/or marketable developer means in-depth knowledge of specific platforms. It's much harder to spin up quickly on a platform than a mere language. However well you know java, you're not going to be a useful Android programmer without a decent understanding of the gamut of Activities, Fragments, dexing, etc. Cocoa is far more the key to iOS development than is Swift (or Objective-C). Go/Javascript/Java (etc) knowledge doesn't get you more 1/10th of the way to productivity with AWS.
All this is making it increasingly difficult to be a convincing generalist.
- mobile development in particular is the worst possible case of this. mobile platform companies are in the best case optimized only for their own case, and in the worst case maliciously trying to create developer walled gardens. However, I would point out that knowing one of these often helps in knowing the other (Android vs iOS) -- there are often 1:1 concepts that map over, because in the end what you want to do is very much the same, and the way the platforms have modeled how to do certain things is often similar.
- AWS is not really a programming language, even if you could CloudFormation templates, which surely will be turing complete if they aren't considered to be already. "Familiarity with aws" roughly equals "familiarity with deploying an application to managed remote servers", which is orthogonal (IMO) to pure application development, but is increasingly a required skill.
I do agree that being a convincing generalist is difficult, and I think this is why generic `Backend Developer` or `Software Engineer` positions often pay more than `Mobile developer` or `Frontend Developer` positions (at least in my experience they have). This is also why people try to hire for "smarts" in interviews rather than just testing language/syntax knowledge -- generalists make for better cogs ("are more fungible" would be the nicer way to say it I guess).
I was offering AWS as an example of another platform rather than a language. If you're called on to (for example) implement a bunch of microservice type stuff, there's quite a bit to learn about RDS/dynamo/lambdas/IAM etc, and then all the quite complex deployment stuff to make it truly production ready.
I think in all these cases, the language is a relatively trivial component. I generally can get quite productive in a new language (that isn't greatly paradigmatically different, ie. allowing for exceptions like Haskell, Rust etc) in a couple of days to a week. A new platform? More like weeks to months.
Yeah, that's definitely true pretty much why projects like react native and flutter exist. I personally have done toy projects on iOS and Android, but do not do it for my day job (and really have no desire to), so I stick to projects like react native and flutter and try to avoid mobile development like the plague.
> I was offering AWS as an example of another platform rather than a language. If you're called on to (for example) implement a bunch of microservice type stuff, there's quite a bit to learn about RDS/dynamo/lambdas/IAM etc, and then all the quite complex deployment stuff to make it truly production ready.
Yeah, absolutely -- funnily enough, I'm relatively sure that AWS wants it this way. AWS can be come so complex so fast, especially when they have many ways to do the same thing (often built upon each other) and it isn't necessarily immediately clear which is the best for your usecase. The additional management they give you for some services is minimal -- I'm thoroaughly convinced that most of the "value" offered by RDS is more-or-less thanks to tools like postgres being well-written/robust software.
I agree on the language being relatively trivial too -- maybe the importance of platforms ties into that -- Once the language difference becomes trivial the next big differentiator must indeed be platforms/the well-used structures that are built on the base language. I'll make sure to express that more clearly in the future
Oh yes. Capture is definitely the name of the game. For 'engineers' or 'software developers' to become instead 'iOS/Android/AWS developers' is good business for the corporations concerned (and ultimately, in my opinion, very bad for us).
To me, the possibility of Rust replacing C is the most interesting aspect of the language.
(I'm not sure I see it replacing C++, but maybe competing with it; choose between evolution or revolution!)
The general hype around Rust is fascinating to me though. I assume it's mostly driven by former C/C++ programmers, but the process has been noisy enough to attract attention from the general developer community? If anyone wanted a non-GC language, C++ has been here since forever and is still being worked on. But Rust has somehow made non-GC seem cool?
> It may never be truly C speed, but from where I stand the tradeoff is worth it
I'm a Rust newbie and haven't benchmarked anything, but the sense I get from the docs is that it theoretically can be as fast depending on how much you limit yourself. Kinda like how C++ can be as fast as C, if written with care.
It would be great to see a write-up comparing Rust and C overhead, e.g. cpu/memory overhead of function calls, slices, etc.
I think Rust is interesting to the people already using non-GC languages is precisely because it offers the speed of C/C++ with LESS of the footgun aspect. Writing C/C++ is accessible and familiar, but it is far from simple, there are tons of pitfalls. Rust has less of those, and takes a modern approach to much of it's toolchain bits and ergonomics.
> I'm a Rust newbie and haven't benchmarked anything, but the sense I get from the docs is that it theoretically can be as fast depending on how much you limit yourself. Kinda like how C++ can be as fast as C, if written with care.
Almost axiomatically, if Rust could be built 100% with ONLY zero cost abstractions, then it could certainly be as fast as C. Concretely, I don't think that's possible, because usually abstractions will cost you something even if it's just a single extra function call redirection. However, you can definitely get to a point where the difference is negligible, and the downsides (maintainability taking a nosedive) make the tradeoff worth it.
I think if you were to compare rust and C overhead in terms of function calls, slices and the like , you'd just be comparing compilers and micro optimizations implemented in both. I think it's kind of hard to test for the things that really make rust shine -- it's all the time you DON'T spend on race condition bugs, and the time you DON'T spend debugging pointer issues.
It's more complex than that. You also have to consider the expert vs the general case. So for example, Rust can automatically apply the equivalent of restrict to many of your pointers. An expert with 100% accuracy could do so in C, but an average C programmer may not. Thanks to the compiler, the average and the expert Rust developer will both do this all the time.
Then, there's the cases when being safer and checked by the compiler means you can be more aggressive. When writing code that needs to be maintained over time, you need to make decisions that will ensure correctness even as you modify the code. And as your staff turns over. Rust lets you do very aggressive things, while making sure that you won't say, introduce thread unsafety accidentally. Not only that, but currently, since LLVM does all optimizations, we have to deal with the ones that are designed for C or C++; Rust is already quite fast without Rust-specific optimizing.
Anyway, in the end, we'll be sometimes slower and sometimes faster than C, just generally. I think it'll be very interesting to watch over time.
Go does not let you manage memory manually.
From what I can tell, Rust seems mainly to have attracted people from dynamic interpreted languages who weren't deeply invested in C or C++. I think it's easier to sell a Ruby programmer on performance than it is to sell a C++ programmer on an unfamiliar safety mechanism.
And to go even more off topic. I thought the go hype was kind of dying down?
To write Rust you have to be very conscious of how you're sharing data between functions, structs, and threads. This is a common source of bugs even in GC languages, so working with a compiler that will point out your mistakes teaches you how to avoid such issues in other, less prescriptive languages.
I also think rust is a lot of fun! I haven't had a chance to use it professionally yet, and it doesn't seem to have made much impact in industry yet, but I think it will get there. Right now it's pretty hard to write networked services (the main market for Go it seems), but that will get a lot better this year as libraries mature and async/await is stabilized.
If you're not yet 'secure' (no-one ever really is, but you know what I mean), then, you'd probably be better off learning something more immediately bankable, and coming back to Rust later.
Though there's no rule. An early-stage developer might have a passion/aptitude for Rust, and the resources to work hard learning it, contributing to open-source, pitching themselves at companies they've researched and like the look of, etc.
If you are, then it doesn't matter. Learn a new thing and try it out.
The value of a language is not defined by how experience with it looks on a resume. If that is your only concern, of course you won't find Rust worthwhile (yet).