Right now the second link you posted isn't loading, so I'm not sure if that is something that matches the Go Tour interface (maybe it is, and it's not loading because it's failing to init some virtualized environment for test code to run in?).
My problem wasn't that good documentation wasn't available, it certainly is. The first and second editions of the rust book rust book (https://doc.rust-lang.org/book) are what I read through and they're great.
What I meant was very literal -- I don't know of a site with Go tour's exact (or close to exact) interface, where you can run through ~30/40 slides (that's how long go tour is AFAIK) and write some code right in the browser to get a feel for the language.
Rust is considerably more complex than Go, so I'm not sure it could be so succint, but I can say that at least for me, going through Go Tour really did make me feel more confident in starting a project with Golang.
It's not loading because I set up a redirect to its new home, https://doc.rust-lang.org/rust-by-example/, and it seems to work for some people, but not for others. I'll have it fixed sometime soon.
> What's the relevance of learning Rust for someone into web development?
Rust is a language that cares a lot about correctness. If I were particularly interested in making sure the code I wrote worked in production, Rust would be my first choice in the set of a dozen languages I know.
Rust is probably quite a bit faster than whatever you're using for web development. The normal counterpoint to this is that web requests tend to be rate limited by the database. This is mostly true but using Rust pretty much guarantees this will be the case. I believe that this point isn't that compelling with current architectures but would be worthwhile in a CQRS architecture where formatted data gets pushed/cached by the web servers and servicing requests stays on-machine.
Rust is one of the more compelling web assembly languages due to not needing a garbage collector. Demos exist but this is mostly in the exploratory stages.
Longer term, I expect Rust to have a unified async networking stack. You can do blocking IO networking in Rust but I expect most network clients/servers to be mostly async once the Tokio stack settles. This is all expected in node but the networking libraries tend to be fractured in most languages.
I don't think you should run out and switch over to Rust for general web development. There's going to be a big release in the fall that rolls up a bunch of ergonomic/convenience stuff that should make it easier to pick up and less annoying to use. I also think that IDE support will be important for a lot of people learning Rust. The situation is improving but the support is not up to par compared to more mature languages. All told, it's serviceable but I don't expect it to be particularly compelling as a web development language for at least another year or two.
As a web developer, you can write servers that take orders of magnitude less space, memory, and CPU than a similar JS server, without having to deal with the madness that is first-time C development.
This does look interesting. I don't see a difference between this and any other server-side templating language though. I actually need an isomorphic representation on the client and server. (this is what makes renderToString() valuable) I guess I could be extremely careful in writing the server output, and writing the client output to match, but at that point, I'd be writing it twice... and I could use any language... unfortunately, it'd probably end up being Handlebars.
It's for client side, not for server side. It's compiled into Wasm and delivered to client. You can use same code for server-side pre-rendering (for faster loading or for search engine indexing), but it is not main goal of Yew.
You should look at the all-F# SAFE Stack, then. It uses F# and .net core for the whole application and supports elm-style UI programming on the client side with react and server side rendering:
https://github.com/fable-compiler/fable-react/blob/master/do...
I'm not very familiar with the React ecosystem but I thought the entire point was letting the client-side handle rendering and passing structured data via API calls? renderToString() sounds like it's doing what every scripting language and templating framework has been doing for the past 20 years?
Look up server-side rendering in React. The major benefits are better/faster first page load experience and better SEO, especially for crawlers that don't have good JavaScript support. This way you can run the same code on the client or server depending on the circumstances.
The fringe benefit being I don't have to represent my app twice (once for server-side markup, the second for client-side JSX). As the size of any give app grows, keeping things in sync would be a nightmare.
We have an entire working group dedicated to looking at the end-to-end web story this year, both backend and front end. Things are still a bit rough, but coming along nicely. The next release of Rust includes a major language feature that’s helpful when writing asynchronous code (impl Trait), for example.
It gets you very close to native performance while running in your browser and browser sandbox. That's mind-blowing.
You'd still use JS for UI stuff, but WASM lets you run algorithmic or CPU intensive tasks like e.g. games, video decoding, image resizing, AI, or anything else you need fast performance for client-side.
There was a demo the other day of Rust outperforming JS for stuff JS usually does. Presumably this will continue to improve, so it won't even be a case of equivalent, it'll be a case of "thoroughly beats the pants off".
"Very close to native" means "much more efficient than JS", because JS is nowhere near native.
(Have we really gone so far that people hear "native" and think of the browser? Like the web browser is the machine we target, and not the metal box the end user purchased?)
Mostly it lets you not use JavaScript, which you may or may not be excited about, depending on how much you think the problem with web development is JS.
There are plenty of languages that compile to JavaScript. They don't save you from having to interface with the DOM and other JavaScript APIs, but neither does WebAssembly (which currently has no such capabilities at all, save through JavaScript FFI).
You can run code written in a language you are comfortable with and run web code really, really fast. It's not an "either JS or WebAssembly", they can work together. Worth reading up on if you are interested - https://developer.mozilla.org/en-US/docs/WebAssembly
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.
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.
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.
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 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.
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.
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).
> 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.
> 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.
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).
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.
> 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
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?
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.
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.
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.
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).