[hardwaresofton]

Rust and Go, while really similar, kind of are different in use -- the key differntiator is memory management, and memory safety. For a LOT of applications, this isn't necessary or a big deal (see: just about every program written in a language that isn't c/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.

[jkarneges]

> I see [..] Rust replacing C/C++ (yeah, even C)

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.

[hardwaresofton]

I think the hype around rust is actually pretty well warranted though -- people got really excited about Go and Rust because they were new "systems" languages, and the world hasn't really seen one of those in a while. "systems language" is a pretty vague term, but one of the things I think is important is that memory be manually managed -- I think most people would agree with that.

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.

[steveklabnik]

> Almost axiomatically

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.

[whyever]

> "systems language" is a pretty vague term, but one of the things I think is important is that memory be manually managed

Go does not let you manage memory manually.

[hardwaresofton]

You're absolutely right -- I didn't think I had to re-state that here since it's like the second sentence of the original comment. That's also why I went into qualifying "systems" language, some might consider golang a systems language, even though it very much does not allow manual memory management, which is why it's vague (and I put it in quotes).

[sevensor]

> I assume it's mostly driven by former C/C++ programmer

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.

[crispinb]

> Knowing X language isn't what makes a good developer, it's knowing some sufficiently multi-paradigm langauge ...

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.

[hardwaresofton]

I agree with that point, except for two minor things:

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

[crispinb]

You're entirely right insofar as (eg) an Android developer will learn iOS far faster than someone without mobile (or any other ui kit) experience. But the specifics are different enough such that it's hard to do both to a high level. Or perhaps I'm just speaking for my own limitations -- I do iOS & Android (native & a bit of react native), but I'm definitely less of an expert with either (or the various server things I also do) than I would be if I specialised.

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.

[hardwaresofton]

> You're entirely right insofar as (eg) an Android developer will learn iOS far faster than someone without mobile (or any other ui kit) experience. But the specifics are different enough such that it's hard to do both to a high level. Or perhaps I'm just speaking for my own limitations -- I do iOS & Android (native & a bit of react native), but I'm definitely less of an expert with either (or the various server things I also do) than I would be if I specialised.

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

[crispinb]

> I'm relatively sure that AWS wants it this way

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