[aviaro]

I know that this is irrelevant, but is it worth the trouble to learn an esoteric language such as Rust? For me it seems a waste of time to learn a language along with its ecosystem where there are few job prospects.

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.

[evincarofautumn]

I think it is worthwhile. If you know a less mainstream language, you can find opportunities to use it at work when it provides a significant advantage, such as being more naturally suited to a particular problem, or having libraries that do what you need. You can also borrow useful ideas and patterns from it and bring them over to the language(s) you do use at work, if they offer ways to improve expressiveness, correctness, maintainability, and so on. Knowing an array of significantly different languages gives you a far broader array of mental tools to use in the design and implementation of software systems than if you stick to one language family or paradigm, even if you only ever use a few mainstream languages at work in practice.

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.

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

[tayo42]

If your goal for learning is to just be more employable then yeah I think its a waste of time. The language is probably worth keeping an eye on though and knowing enough about it to consider it in the future if it does pick up significant traction.

And to go even more off topic. I thought the go hype was kind of dying down?

[aviaro]

Go is probably going to stay. Last when I looked at job boards, I saw a fair number of Go keywords

[necubi]

I've been casually following rust for ~5 years now, but finally decided to really put in the effort to learn in in the past several months. It's definitely a slog to really "get" the Rust mindset (as well as learn the various sharp corners of the borrow checker and lifetime systems), but I think it has made me a better programmer.

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.

[crispinb]

It depends very much on where you are in your career. If you're at the stage where you feel confident that you can maintain a living, then of course it's 'worth the trouble'. I don't know Rust, and don't imagine it's something I'll ever use professionally, but it's definitely on my (too long, and increasing rather than diminishing) list of things to learn.

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.

[always_good]

If you aren't marketable and know no other languages, then yes, you should probably start in something more mainstream. Just seems more time efficient.

If you are, then it doesn't matter. Learn a new thing and try it out.

[platz]

https://trends.google.com/trends/explore?q=java,golang

[NamPNQ]

java query include jav full hd

[thomastjeffery]

Rust and Go are not in the same category of language. Go is garbage collected; Rust is not.

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

[cbcoutinho]

For comparison, think about the python paradox [0]

[0] http://www.paulgraham.com/pypar.html