Last year Rust was a language I badly wanted to learn. I've had many false starts learning a lower level or "systems" language, which I felt would round off my toolbelt quite well. A lot of principles of CS you don't get exposed to when writing web servers and UIs.
The problem I had was basically the IDE integration in VSCode. RLS was okay but unreliable. And if it only works most of the time, it may as well not work at all. Especially when it only sometimes gave me code completion and type checking (A lot of "unknown" would fill my code).
Then Steve pointed out Rust Analyzer in a previous thread and I was off to the races. Rust Analyzer has gotten _so good_. Having a VSCode setup that gives me immediate feedback for my mistakes and code discovery makes a huge difference (to me at least). Maybe a bit of feedback is that I wish Rust Analyzer hadn't been so hard to discover. Though maybe that's just because it was new.
That, combined with my nightly march through The Rust Book has me well beyond, "I wish I could learn a systems language but !@#$ C and C++ are just so complicated and unforgiving" and into "wow, it's no-longer a matter of _if_ but a matter of how much I want to hone my understanding." Rust is a beautiful language that way. It guides me away from rookie mistakes that would leave me disenchanted after hours of debugging something dumb. (It's hard to be unrelentingly dedicated to learning something new now that I have young kids. When I was a teen it was easy)
I don't want to come off as a Rust fanboy. I have yet to implement much of anything (though hopefully by next year I'll have a Game Boy emulator to show you all). But I want to give thanks and proselytize a little because it has been such an empowering experience.
I like Rust a lot. And used it for about half a year in my spare time. But in that time, my impression with it is that it is a VERY hard language to be productive in when its something you rarely use. So I wouldn't mind learning it and using it in my dayjob or if I had more free time. But trying to fit it in between work, family, and leisure time didn't work out so well for me.
Yea, the survey says that IDE support is the third-highest item for increasing adoption (https://blog.rust-lang.org/2020/04/17/Rust-survey-2019.html#...). Rust users would benefit greatly from the Analyzer work that is in flight. Really looking forward to this becoming stable. The tooling it offers is great.
I have used both, and I’ve found rust analyzer to be better but not amazing. It seems it often “gives up” and autocomplete stops working. It is improving over time though.
One of the issues preventing the type inference from working in the presence of associated types was fixed this week, so the next release should be even better.
C complicated? It is a very small, simple language for a system programming one.
C++ complicated compared to Rust? They offer roughly the same features and both are complex languages if you want to understand what is really going on.
Rust is a very good language that competes with C++. The main feature it brings to the table isn't simplicity (Rust, like C++, isn't simple at all), but the borrow checker.
Please avoid making comparisons between languages if you don't know them (as you claim).
>C complicated? It is a very small, simple language
That's a bit misleading though. Yes, C is very small - but that doesn't mean it's magically easy to understand. It's size has a huge consequence; the language doesn't do much for you, so it's up to you to fill in the gaps, e.g. correctly manage memory
I find C much simpler to learn and to write simple things in.
If you learn C, you'll find that most used languages are compatible with C way of thinking. You can pick up C#, Java, Javascript, Python, PHP with ease as you kind of think in the same way.
While Rust, the language might not be terribly complicated, you have a totally different paradigm, the restriction on variables and the borrowing system makes it totally different than the languages people are used to, to the point that for beginners is totally unintuitive.
You can't just declare a variable, initialize it, pass it to a function and get a result back.
You can't have self references in a structure.
No, siree, as a beginner learning Rust you have to do a lot of complicated dancing around the borrow checker.
Comming from C like languages I find even functional languages like F# easier to pick up. Because they feel more intuitive. Unlike Rust you kind of feel what kind of code you need to write to get a workable result.
Right now I feel that the only advantage of Rust over other safe by default languages is speed. You can use low level constructs and unsafe features like raw pointers in C#, but the garbage collector for the safe code slows it down.
I don't think garbage collected languages can ever be as fast as Rust.
Reference counting like in Swift is another way to provide simplicity, but I see Swift is even slower than garbage collected languages.
So if your use case needs both performance and safety, Rust is your best bet.
It seems that from simplicity, performance, safety you can only pick two at once.
Microsoft Research is working on a language inspired by Rust. I'm curious if they can come up with something as safe but easier to use. I wouldn't bet on it. They aren't convinced of the outcome since they recommended to write or rewrite parts of their software in Rust instead of waiting for the new magical language.
A good thing from Microsoft evaluating Rust to use in their huge code base is they learned about a few weak points and are making recommendation to Rust team.
One side effect of Microsoft embracing Rust might be that other corporations like Google and Oracle might avoid it to distance themselves from Microsoft.
To better illustrate this, compare with Brainfuck. It is also a very small, simple language.
Its simplicity is at the same time its own worst enemy, in that it pushes down all the difficulties, complexities and verbosity for you to manage yourself. Perhaps an extreme comparison but just to show that simpler language doesn't always yield a simpler program.
I was going to compare how many pages the rust standard has, and compare it to the C standard (plus 20% for the "correctly manage memory" that you pointed out as something extremely complicated).
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
Anyway.. C is a rather simple language. No matter what the opinion of rust programmers is.
Please don't respond to this post. At least not with the bog standard "undefined" "unsafe/memory" and other shallow conceptions.
Sorry. "correctly manage memory" in C is not 20% more problematic, it's like dividing by 0, infinity% more problematic.
Nobody has gotten it right. Ever. Nobody.
The Mozilla team switched from C to C++ trying to get memory right. Failed. Then they tried GC. Failed. Then they tried to go back to manual. Sill failed.
So they wrote their own language to solve the problem--Rust.
Jury is still out, but the situation is a lot better than when Mozilla started.
> which the "systems language" Rust necessarily runs on
Strictly speaking, Rust does not need to run on a kernel. If anything, the Rust developers have explicitly steered the language to be suitable for bare-metal situations.
> So the Linux or BSD kernels... have not gotten it right
...Because they haven't? Just look at the CVE databases. A cursory search gives:
In addition, Microsoft has said that ~70% of their CVEs are memory safety issues [0], and have been for many years.
So no, easily accessible memory safety in C is not a solved issue yet. There are various techniques and tools that can be used to reduce or eliminate memory errors, but they have not seen widespread adoption for one reason or another.
That 70% CVE figure is misleading: C and C++ obviously have a far higher market share, especially in fundamental Internet applications and kernels. So they have a higher number of CVE reports.
But let's examine Rust despite its low market share:
If the 70% CVE figure can be interpreted as misleading then that was a failure of wording on my part. The intent behind the short list of CVEs was to refute GP's claim that high-profile open-source kernels no longer suffer from memory safety/management issues, and the 70% CVE figure was just to show that high-profile closed-source software isn't much better. I think that the 70% figure is an appropriate example in that case.
Now if you wanted to examine whether Rust programs suffer from fewer memory-related issues, you need to look at more than a few CVEs here and there for both Rust and C/C++ programs. As you pointed out, C/C++ programs are much more prevalent, so looking at the absolute number of CVEs isn't a good comparison. Ideally, one would need to find a Rust and C/C++ implementations of programs with very similar feature sets and look at the various vulnerabilities, such as by looking at fuzzer trophy cases for similar programs and compare how many of the uncovered errors are memory-related.
Note that none of these CVEs is exploitable without the developer _also_ misusing the API or exposing the vulnerability to some data that the attacker can control. It's unclear whether these can be thought of as bona fide security holes.
You might not want to throw that stone from the glass house that is the C standard library or the C++ standard library.
Both of those have had vicious holes (memcpy/memmove anyone? s/f/printf? I can go on and on ...) that STILL aren't fixed (at least most implementation now just pass memcpy to memmove and be done with it). And part of the reason why musl and glibc are incompatible is that they disagree on certain things that produce vulnerabilities.
There is nothing to fix in the functions you mentioned, and no sane implementation calls memmove() from memcpy().
I hope you realize those functions are some of the most fundamental in the ISO C standard, defined by dozens of major companies. I am pretty sure their engineers know what they are doing...?
Do you know how old and widely used C was when it got its spec ?
The work on ANSI C started in 1983, 11 years after C came out. And it took 6 years! to complete.
If Rust is as sucesful as C was during its 11 first years, Rust will most likely get a formal spec eventually. But don't hold your breath because it's going to take a loooong time to get there.
I teach Rust and C to college sophomores and juniors. By far the things they have the hardest time with in C are manual memory management, when to free variables, how to debug segfaults (usually called by incorrectly freeing memory), and how to correctly link code. We spend so much time on this I can't tell you.
With Rust none of these things are issues and we get to actually spend time solving problems in the language instead of just understanding the language. Yes, C is as simpler language, but it's got no safety rails, and when you're a beginner at systems programming it's nice to have a friendly compiler who can help you pinpoint errors rather than to be shown "SEGMENTATION FAULT" and feel like you're on your own.
For example, adding dependencies. And this one thing makes a lot of practical tasks simpler too, because there is a whole swathe of code you simply don't need to implement at all.
What's simpler: Implementing a HashMap in C, or `use std::collections::HashMap`? If you really need to understand what's going on under the hood then yes C might be simpler. But when was the last time you needed to inspect the details of your HashMap?
There are also things like C's declaration syntax, which is anything but simple. And header files (even for your own code).
I'm with you on this one. The Rust and C# API's are more or less equivalent. That does still repudiate the grandparent's assertion that it's easier the use C#'s dictionary.
I agree with this. I've found that students who struggle with the borrow checker also write code that tends to segfault in C. Rust is nice in that once you get it to compile it pretty much works. It's not going to segfault. I've also found that when students master the borrow checker in Rust, they write better C code.
If you don’t need to understand/inspect the details of a HashMap implementation then you are not doing ‘systems programming’. The attitude that ‘someone has done it for me’ and therefore I don’t care about it is not a characteristic of ‘systems programming’. It may be simpler to just use some standard implementation of a data structure, but if that is the case, then you can get by with most of the commonly accepted language paradigms. I’m not saying everyone need to implement a unique hashing algorithm tailored to use case, but that is what systems programming is.
System Programming is the custom tailoring of data conditioning to a particular set of circumstances and then taking responsibility for the benefits and consequences of that those choices that differentiates systems programming from the other broad categories of program construction.
Rust is a fine language if it fits your use case, and you feel as though the purported benefits of the ‘borrow checker’ assist you in writing quality code, but if you just want a programming language that provides a large library of pre-written solutions, then the difference between language is dependent only on use case and usage requirements. Saying Rust is simpler than C because you can use a pre-written HashMap implementation is ridiculous, because you can do the same thing in C (I mean use someone else’s HashMap). But if ‘systems programming’ is the area of interest, being able to inspect/implement the actual HashMap is a key concern, and just dismissing that aspect is not an acceptable proposition.
> If you don’t need to understand/inspect the details of a HashMap implementation then you are not doing ‘systems programming’. The attitude that ‘someone has done it for me’ and therefore I don’t care about it is not a characteristic of ‘systems programming’.
Don't gatekeep. Rolling your own containers has no bearing on whether or not the language is a systems programming language.
I'm using it to do real time audio and graphics, but I don't have the time to hand roll my own data structures because I have a demanding day job and other responsibilities. I still get to have the benefit of using a fast, modern, bare metal language.
> Saying Rust is simpler than C because you can use a pre-written HashMap implementation is ridiculous
No it's not. HashMap is literally there in std::collections to import and use. You don't need to find a library, know about the linker, etc.
Rust makes working in this domain so much easier than C and C++. You can go from zero to productive in a reasonable amount of time.
> Rust makes working in this domain so much easier than C and C++
C++ has a hash map in its standard Library since 10 years.
> You can go from zero to productive in a reasonable amount of time.
That's definitively a very WRONG assumption.
Anyone starting to use Rust, even with 10 years of C++ experience, will spend from HOURS to DAYS fighting the borrow checker.
It is not "zero to productive", Rust is not easy to learn, nor productive for beginner.
Is it however worth the effort ? I believe it is. Especially if you are looking for a language providing you safety first.
> C++ has a hash map in its standard Library since 10 years.
OP was talking about C, not C++/STL.
> Anyone starting to use Rust, even with 10 years of C++ experience, will spend from HOURS to DAYS fighting the borrow checker.
You might have learned Rust pre-1.0 or non lexical lifetimes. They've made a tremendous amount of work to improve the language and make it beginner friendly.
A few weeks ago I watched one of my coworkers implement a simple toy state machine app after having just read a tutorial. The compiler literally hand holds you now.
> You might have learned Rust pre-1.0 or non lexical lifetimes. They've made a tremendous amount of work to improve the language and make it beginner friendly.
I still use Rust almost every week for personal projects, I enjoy it and I still would not qualify it as quick "zero to productive". It still fall behind C++ in term of productivity for me.
Many things that few lines of C++ allow you to do in few lines requires mental gymnastic to wrap around the borrow checker, strict typing and Rust error report system in 10-20 lines.
Comparatively speaking, I program in C++ since 15 years and in Rust since 3 years. Still, everything I do in rust takes between 1.5X to 3X more times to do than in C++, even if the tooling is better.
I know I am going to make enemies saying that with the number of Rust fanboys on YC, but... this is my experience.
And it is not a surprising experience.... Anyone that programmed in OCaml or strict typing language like ATS already experienced that... The strict typing gives you runtime safety and make your program "just" run (less bug-prone) compared to Weaker typed language....
But... it has a cost... like everything... And the cost is much more mental gymnastic... meaning time... meaning less productivity.
I'm using C++ daily at work and know Rust since it's alpha versions. C++ is miles harder to learn and write in than Rust, partially because of layers of legacy cruft in the standard, some bad decisions made that they can't undo now so they will stay forever (e.g., 50+ ways to initialise an instance, with constructors and all that, vs. Rust's lack of ctors). I still reach for reference all the time when writing in C++, but barely if at all when writing in Rust.
C++ might not be harder in theory but at least for me right now it is a lot harder to learn than rust.
C++ just has so much stuff and different ways of doing things (of course, it's been in use for decades) that it I feel quite lost as a beginner on what to actually use.
Also in my experiences the rust compiler errors are extremely helpful, especially compared to the c++ template stuff.
There's nothing wrong with that. People need to see that everyone around them is catching the Rust bug.
I want people to feel like they're missing out so that they too will take the plunge. The sooner everyone knows Rust, the sooner employers will start using it internally.
You don't need people who are learning their first "systems language" to evangelize. You actually need to convince C and C++ programmers, who are largely put off by the hype.
Rust seems to be popular only in the web sphere, where Javascript and Python programmers are tweeting that they now know a "systems language".
> Rust seems to be popular only in the web sphere, where Javascript and Python programmers are tweeting that they now know a "systems language".
I see that is the best thing Rust brings to the table, as the scope of learning and using Rust is pretty much “scoped “. Once you are comfortable with the compiler, you can use Rust reliably and deloy code to production. Whereas C/C++ is very “open” to learn, you can learn the syntax and basic in a couple of weeks, but to use it correctly and reliably (to a certain degree) WITHOUT SUPERVISION from another advanced programmers takes years of experience under your belt.
Yeah! I'm not about to go acting like I'm a systems programmer. I'm not writing drivers. But there's a lot of CS principles you just don't get exposed to when writing web stuff and that's what I'm after. Just knowing those things better will make be a better programmer, even if I never use rust professionally.
>Rust seems to be popular only in the web sphere, where Javascript and Python programmers are tweeting that they now know a "systems language".
This is great because now we are starting to get faster, more performant libraries and code. People switching from Node to Rust see huge speedups. Perhaps we'll also switch from JS to rust with WASM. Rust is nice because it's high level enough to write code with algebraic data types, like in TypeScript, so that maintenance is easier. Personally I'd love to see as many people as possible move from JS and Python to Rust.
I believe that the CLion/IntelliJ plugin and rust-analyser were authored by the same people, and that one of the primary maintainers now works with Ferrous Systems.
the rust plugin for intellij is pretty damn good. sometimes it doesn't catch downstream errors when you mess something up but it's on point probably 80% of the time.
After reading your comment I tried Rust Analyzer and wow, it makes a huge difference. I was previously using rls and it was misssing a few key features (I didn't even realize it).
rust-analyzer doesn't work well for me, I can't click through functions to get to definitions. There's a bunch of things that just stop working. So I'm still on RLS and it's not great.
Networking in Rust has gotten _so much_ better this year.
My old server needed nested callbacks, wrapping everything in refcounting, loops via recursion, and Either for control flow. Still easier than C, but not pretty.
Now it's just `do_this().await.do_that().await` and I'm done! Huge congratulations on shipping that.
I started learning and coding Rust full-time over the last couple of months. I expected a learning curve, but boy what a steep curve it was. Simple things are simple enough, but for experienced programmers porting your patterns (especially functional programming patterns) can be challenging and interesting at the same time.
The answer is obvious only if you know a fair deal of Rust. Thanks to the Rust team's amazing momentum I am sure the compiler will improve over time, but for now I found passing functions and closures around a bit harder than I expected. Totally loving the language though.
The learning curve is misleading. You can achieve parity with a higher level language by copying and pasting solutions such as the one in your stack overflow post. Yet, unlike in other languages, an opportunity presents itself to learn far more about the underlying tooling used to create such a solution.
NPM rewrote one of their services in Rust. It took them one hour to rewrite it in Javascript , two days to rewrite it in Go and one week to rewrite it in Rust.
Even if we account 90% of that time to the lack of experience in Rust, it still feels like a massive productivity hit.
So unless you absolutely need to squeeze the most performance you can from the hardware it might not be the best choice.
It is kinda unfair to compare the time of writing a service in go and rust if your team already work with JavaScript.
Go was designed to be extremely simple (simplicistic, if you want to be ugly with terms) while rust was designed with very different goals in mind.
Moreover the mental model of JavaScript is much closer to the one of go than the one of Rust.
If you are learning rust and you are not from C/C++ or similar low level languages you are basically re-learning how computers works. Usually on go you don't really care of the difference between the stack and the heap, in rust you have to.
Said so, it is really true that rust has a steep learning curve, however once you get over it the productivity is at least as high as go especially in the long term.
For one off script of ~100 lines I would pick go as well.
Sure but it's worth noting that they went with the Rust implementation in the end even though it took the longest to write.
Their reasons appear to have been that Rust code has fewer bugs (who cares if you get your JS code done in an hour if you spend a week fixing trivial runtime bugs?), had better performance, and they didn't like Go's dependency system.
I definitely have noticed when writing Rust code I spend way more time getting it to compile, but I also have that "wait it worked first time? Impossible, I must have done something wrong" feeling waaaay more in Rust than I ever did with C++ or Typescript. I'm even starting to get used to it and think "sure it worked first time, it compiled after all!".
I wonder how their opinions on Go would change though, given that it now has arguably the best designed dependency system of any language.
> The rewrite of the service in Rust did take longer than both the JavaScript version and the Go version: about a week to get up to speed in the language and implement the program.
So that was an hour for a programmer who knew JS, and then a week for a developer who didn't know Rust.
Secondly, to me those times are acceptable, because they don't tell the whole story. JS is very easy to quickly prototype things in, but that doesn't mean it's great to maintain. Just yesterday in our JS code we have found in some places we are writing timestamps as an epoch number, and some places we are writing them as a DateTime string. It's not as fast as native code, nor as easy to parallalise, etc.
They are better than most docs, but sometimes they have gaps in their sample apps.
The WASM book, for example, goes from "hello world" straight to "game of life".
It's certainly an interesting algorithim and probably hits a sweetspot because its computation heavy(?), but at least for me it was too much noise around actually learning Rust and WASM.
Please don’t forget that the survey closed in December last year, so it’s pretty close but may not reflect rust actually today. In particular the IDE landscape has been changing rapidly.
Having not used Rust at all, I'm impressed with its momentum. I know every language has their issues, but Rust seems to have a strong community, is well organized and seems to have good tools available: all things that make me believe that I would be able to use it effectively were I ever to work with it. I've been watching Gamozo on Twitch use it to build a hypervisor kernel and I really enjoy seeing how the language works for him.
When people want better docs, do they mean better doc tooling or better doc writing? Because personally, I'm a huge fan of cargo-doc and its integration to the ecosystem. Just yesterday I found out about #![deny(missing_docs)] - which combined with executing code snippets in cargo test - enforces really good documentation discipline and ensuring that everything is doc'd, and that docs don't become stale.
Ask HN: Do you recommend learning C++ first then Rust? My logic is that learning C++ and navigating its pitfalls would lead to a better understand of Rust and the underlying reason behind certain design decisions.
I think it will take years of working in c++ to fully appreciate the nightmarish many-tentacled footgun monster it can be.
At the end of it you might even develop Stockholm syndrome and be one of those posting “if you just restrict yourself to these parts of the standard and run this 6 static analysers on your code then c++ is perfectly safe if you’re not an idiot”.
If you don’t want to learn c++ for its own sake, that’s time you could better spend learning a language that’s not actively trying to harm you.
Source: coded c++ for 20 years, now writing rust as much as possible.
> If you don’t want to learn c++ for its own sake, that’s time you could better spend learning a language that’s not actively trying to harm you.
With enough time, you will realize that any language try to harm you and has quirks. Just different quirks in different scope. Rust included.
> Source: coded c++ for 20 years, now writing rust as much as possible.
I coded for C++ for a smilar time. Now I write Rust on my free time and I still enjoy C++.
This "nightmarish many-tentacled footgun monster" is still a pleasure to use for many use cases and far more powerful than Rust for some scenarios ( constexpr/consteval, template with const litteral, overloading, low level control on memory allocator and a gigantic ecosystem of high quality libraries)
I looked into D once or twice. Found learning materials severely lacking. Having to read up on the differences between 2 (3?) compilers and choose between them wasn’t a great intro.
For the work I do GC is also a non-starter. I know it’s got some level of no-gc now but the last time I looked it wasn’t well-supported.
In short it seemed interesting but on-boarding felt hard. And with that the value proposition wasn’t there or well-advertised: It’s supposedly “better” in some ways such as faster compile times and better meta-programming and frankly that didn’t seem worth the effort.
Rust by contrast does an excellent job of onboarding and making it easy to learn the language (at least at an introductory level). It also comes with a very straightforward value proposition: just as fast as c++ but whole classes of bugs simply aren’t possible. Add in a little bit of ergonomics and functional flavour and I was hooked.
I love D's community and what they were trying to achieve, but it appears that the language has lost its opportunity to adoption or sense of direction.
What I liked on it over Java and .NET languages, is no longer relevant after GraalVM, and the low level features in C# 7/8 adopted from Midori, came to be.
Also C++20 now makes much D less relevant.
Unfortunately the recent @safe and @live discussions don't inspire confidence in which direction they want to drive the language design.
1. The learning materials are much better. The official Rust book is excellent. And it doesn't take long to do a first run through it.
2. You'll learn much quicker with Rust. With C++ it could take you years of experience to gain a full appreciation of the pitfalls because they're often not apparent when you first write the code, only when you actually run into the bug further down the line. With Rust, you'll get a compile error and enlightenment is quick google and a reading of a blog post away.
3. Some parts of Rust only seems to be difficult for C/C++ programmers who have learnt the C(++) way of doing things and expect that to translate into Rust. They get frustrated when Rust doesn't let you use certain patterns. However as C++ is generally less strict, if you learn the Rust way first, then you'll generally be able to translate that fairly directly into C++.
Regarding learning materials, I do agree about the quality of the Rust book, but I will say that if you're the type to learn from a project, especially if said project is a game or GUI Application, life will be easier and learning materials better in C++.
There's definitely a dialog between Move semantics in C++ and Rust's ownership model.
If I weren't a C++ programmer first, I don't know that I would really grok the value proposition of Rust (not dealing with Move Constructors) or the trade-offs (library code has to provide differently-named functions that trash resources as an optimization, rather than just providing an overload that eats temporaries).
> As for platforms that users develop on - Linux and Windows continue to dominate.
That seems like a very odd way to characterize the results (55% Linux, 24% Windows, 23% mocOS). Why draw the line between the two platforms that are 1% apart instead of between the two that are 31% apart?
You need a standard web/networking framework. Built in to the standard library, like in Golang. That will speed up adoption. Rust's competitor is C++. C++'s biggest weakness is build tooling, which Rust is demonstrably better at with cargo. C++'s second biggest weakness is poor networking support. Rust isn't any better. That's driving away the JavaScript/RoR/hipster crowd which is the lifeblood of Rust's adoption.
I think that networking frameworks go out of date much more quickly than base languages (see Python for an example). By not including it in the standard library, the recommended Rust library for web and network programming can change over time.
Rust already has synchronous TCP and UDP in the standard library (https://doc.rust-lang.org/std/net/index.html). But most people want to use async versions, at which point there very much isn't one way to implement it.
Once you get to higher level protocols like HTTP, you also have questions like "should HTTP header be strings or encoded as types. There very much isn't just one way to implement it.
That's pretty fundamental and completely changes your API.
And, before you reply, you might want to know that while the majority of things do it with callbacks, both the lowest embedded AND highest custom networking systems implement networking with polling (for different reasons).
It absolutely does not belong in the standard library. That said, Rust does need a "go-to" stable library for web serving, like what Express is for Node. It might make sense for the core team to endorse one, or even spend time helping one of the most prominent ones move forward, but I think it needs to remain separate.
Node has an HTTP server in the standard library. A framework it's another thing. My view is that (for example) Go's HTTP implementation will age well, because it is consistent with the design of the rest of the standard library. An HTTP client/server can certainly have a place in a standard library, providing that it is well defined, consistent in style, and keeps its scope sufficiently small.
Node and Go are both purpose-built for the web. Rust's target market is much broader than that; some people even use it on embedded devices. One of its headlining features is its slim standard library. That trait shouldn't be thrown away without good reason.
If Rust's competitor is C++, you don't need to attract Rails developers, you need to attract C++ developers.
If anything, i would say that over the last year or so, too much effort has been put into making Rust a competitor for web development, what with async, and lots of attention paid to web frameworks. Meanwhile, C++ people i know mostly look at it and say "meh, no const generics, no placement new".
> First of all, we tend to work on what users are asking for. This survey shows a lot of interest for web and rust.
If (if!) Rust's mission was to replace C++, that would be a mistake.
That's pretty obvious, right? You decide to replace C++. You make a language which isn't a great C++ replacement. You attract users who aren't C++ programmers. They aren't interested in the things C++ programmers are interested in. You build features which don't appeal to C++ programmers. Lather, rinse, repeat.
I think at this point, in practice, Rust's goal isn't to replace C++. It's to become a better Rust.
> They aren't interested in the things C++ programmers are interested in.
This assumption only holds if people didn't want to do systems programming before. Many people who wanted to do it crashed into C++ and then said "yeah okay, not for me", which calls this into question.
One of the unusual things about Rust is how wide a segment of developers it's trying to please. Everyone from C to JavaScript. It's fascinating how well it's doing so far, but it leads to inevitable compromises at a certain point.
GUI tooling like Qt or XAML, even OWL, MFC, wxWidgets, VCL, if I go pick 90's examples.
async/await runtime as part of std. C++20 async/await isn't relying to competing external libraries.
Mixed language IDE based development experience, including debugging across languages on the same session, e.g. Java/C++, .NET/C++, Objective-C, Swift/C++.
> C++20 async/await isn't relying to competing external libraries.
Standard library is a liability. It's only a matter of time before any non-trivial stuff will turn out to be worse than a 3rd party solution, and won't be able to catch up due to std's constraints (C++ regex being extreme example).
Rust has already learned that lesson with channels. So instead of having to say "don't use std's, use the other faster nicer thing", Rust skips over the tech debt part, and recommends the other faster nicer thing immediately.
And a clean separation of await from its runtime is actually pretty cool. I'm writing a GTK+ app right now, and I can await button clicks on its event loop.
C++ programmers will not switch to Rust. Most of them are older than the maximum age where you can learn new things, let alone be willing (or allowed in their company) to do so.
Rust will be most popular with those who are 18 years old now and wanting to try native programming. When you compare the two, tabula rasa, it's just a no-brainer.
I'm not trolling. I'm confused why this is so controversial since it's widely accepted folk wisdom (and confirmed by science). Learning gets harder as you age. Just bing it.
People used to say the same about C++ vs. Java. (But hey, C++ devs were young back then, and many of them did switch to Java; didn’t hurt C++ though - it was the best who stayed.)
What's wrong with Rust's networking support? I actively wouldn't want it in the standard library, because you'll almost certainly end up stabilising something suboptimal. And then your stuck with it. Its not like it's hard to use 3rd party libraries in Rust. Its literally a case of adding one line to your Cargo.toml file.
I agree that with the rapid change in the language, it's probably premature to standardize on one API for networking. But as a newcomer to Rust, it's really overwhelming when there are like 5 different async websocket libraries, none of which is a clear standard in the community, each with relatively sparse documentation (other than the method signatures/impls).
Also, I haven't been following the Go ecosystem lately, so I could be wrong, but they seem to have done a good job at creating standard libraries for common stuff like http serving, and those libraries seem to have aged just fine.
I believe the strong build tooling you mention is what makes it much less painful to have things like high-level networking frameworks in 3rd party packages.
As other people have pointed out, despite being a “systems language” Rust has attracted people from a whole bunch of areas and programming languages and limiting itself to just systems programming would limit its uptake and community for very little benefit.
Not that this means that every demand needs to be acquiesced to, there’s balance to be found.
Web development projects in a new language is a good starting point because you can do something with pretty UI quickly and with minimum configuration. But it has no staying power. A web developer will be gone after a couple of months (fun to learn!), leaving behind nothing, and suddenly Rust will have lost its footing (systemdevelopment).
I’m always happy if people use Rust. But why call out an unrelated field with a use case nearly opposite of Rust’s design requirements as “the lifeblood” of adoption?
I also don't quite understand the appeal of Rust for applications that can tolerate a GC. Other than perhaps borrow checking, I don't see the benefits over statically-typed, GC languages.
I used to code a lot in C++, but I've come to the conclusion that manual memory management is a cost that has to be considered seriously. e.g. one burden is that when you're declaring a field on a struct in Rust, you have to consider whether it needs to be a reference, value, automatic reference counted, boxed, if its a reference, what the lifetime is, etc. The only thing I miss about manual memory management is the RAII pattern.
Rust moves down a level of abstraction that IMO is not useful for most applications.
There’s one specific substantial benefit in comparison with typical Java-like languages: concurrency is much easier in Rust. Having “is this thing thread safe?” answered at compile time is something I missed in Kotlin a lot. Of course, it does not necessary outweigh the need to think about references vs owned values, etc.
I think Rust was relevant in bringing affine types into mainstream, after the ATS and Cyclone attempts.
Thing is, with ongoing efforts on managed languages to integrated similar capabilities into their type systems, we can get most of it, even if we don't get access to the full package.
If your requirement is compiling to native binaries, then perhaps dlang with GC enabled? Admittedly it would be a really poor choice in 2020 though given the lack of adoption. Golang is GCd and native, but of course the language is lacking in many ways compared to Rust.
So I guess you're right, nothing I can think of quite fills the niche that Rust does, if compiling to a native binary is a hard requirement. Also I'm not aware of any widely-adopted language with borrow checking, if that's a feature that's valuable for your use case.
Java has servlets and Spring.
Go has net/http.
Ruby has Rails.
Python has Django and Flask.
C++ has ASIO and gRPC.
Rust belongs with the above but it has...checks notes...actix-web which was run by one guy who ragequit and apparently no one else is capable of taking the reins.
Servlets are not in standard library (and it's not even library, it's a specification). Standard Java has HTTPURLConnection which is sometimes used and com.sun.net.httpserver which is not used by anyone. Spring is not in standard library either.
Also you forgot netty which is best Java networking library nowadays.
Java is a good example why batteries-included standard library is a bad idea. The fact that Java keeps reinventing things (Old I/O -> New I/O, Newer I/O; java.util.Date -> java.time.*; File -> Path are just a few examples) also proves that point.
Standard library must contain fundamental interfaces which are required by most libraries to interoperate with user code and with other libraries. String type is used everywhere, so standard library must contain String type, otherwise people will invent QString, CString, Glib::ustring and billion other string which do not interoperate with each other, so instead of writing useful code you'll convert one string to another. Array, Set, Map are used everywhere as well, so standard library should provide those interfaces. Filesystem paths, streams are useful. And similar things. But not big libraries like HTTP library. They should be implemented as independent projects, so the best one wins.
> Servlets are not in standard library (and it's not even library, it's a specification). Standard Java has HTTPURLConnection which is sometimes used and com.sun.net.httpserver which is not used by anyone. Spring is not in standard library either.
You're arguing against a strawman. These things are not in the standard library, but the ecosystem builds around them, and there are published JSRs that define the interfaces for foundational libraries (including both servlets and DI - of which Spring is just one of many compatible implementations).
No-one's arguing that Rust should have a web framework in the language standard library (I hope). But there should be one or more established options that the rest of the ecosystem knows about and interoperates with.
Popularity among whom? The hobbyists? I program professionally with Rust and that entails a lot of web development. Actix-web remains the most comprehensive, vetted solution.
You can't compare a general use networking server such as hyper with actix-web. Hyper is used for a much broader range of scenarios than just web development.
I truly hope that programmers continue to broaden the ecosystem, but progress has been slow.
Haskell's an old language, pushing 30 years now... Rust is still a relatively young technology. There are lots of improvements that could be built but only a handful of people to build them.
Rust offers complete control over asynchronous streams of data with uncompromising safety. I believe that this will make Rust a contender for the Golden standard in data engineering, which supports data science. The survey category may need to distinguish the two or data science will include it.
It is good enough for introduction but not much more. What I meant to say is, there are no books that teaches you how to create programs using Rust. Patterns and stuff...
- a CPU emulator
- a fully functional NTP client
- a skeleton grep implementation
- how decimal numbers are represented in Rust
- developing your own format for representing numbers
- a memory scanner so you can learn how game cheaters cheat
- handling UNIX signals
- inspecting binary files for hidden patterns
- an OS kernel + bootloader
- an L-Systems implementation
I think that its a reflection of where much of the market's jobs are: "backend web app" might as just well be replaced with "thing moving data around with RPCs" which is what so much of the value software provides in the economy is tied up, these days. Also, for startups who live-or-die by their cloud hosting costs, reducing CPU utilization by 2x and MEM utilization by 5x versus GC'd languages, the value proposition is real.
That's not how it works, since most startup run python / ruby / nodes code, the cost of your app is definitely not a big concern, especially since you can have performat code in any language, you don't need rust speed in 99.9% of the cases.
Sometimes performance matters. At my previous company we settled on a Rust solution for one component (ingesting analytics data) after cycling through python and node prototypes that were just too slow (we had 100+ GB of data to process, and the node.js app was taking 15 minutes to process one 500mb file).
And once the data processing code was in Rust, it made sense to have the endpoint that collected the data in Rust too. It would probably have been possible to optimise the node/python versions. But it was easier to write it in Rust that is designed for these high-performance scenarios.
An unexpected bonus was just how reliable our Rust code turned out to be. I'd definitely consider Rust for non-performance critical code on that basis.
I still think web applications massively out-scale mobile apps. The majority of software written is not general purpose consumer level "shink wrap" apps and never was.
Still, a very large portion of mobile apps are connecting to some back end service. I think I have exactly one app that stores it's data locally without a server connection (not counting games).
Even there Rust needs to compete with the productivity, libraries, IDE support and compile times from JavaScript, TypeScript, Java, .NET and Go.
Additionally really don't see a need for having to deal with the borrow checker in distributed computing applications, instead of tracing GC + value types.
Rust's ideal place is like where Oracle, Apple, Google and Microsoft are placing C++, OS low level libraries, audio codecs, graphics drivers.
I was surprised to see the title "System Architect" was the second most-common job title among respondents. Use of that phrase is culturally taboo within Google. Are there regions in the world where its common to use that title? I see that the respondents were from all over the world in 14 languages.
So many weird job titles/euphemisms for programmers. Engineer, Architect, Developer, Scientist. How about none of them. You're a programmer. You're not building bridges.
While it is true that some developer builds yet another e-commerce cart on JavaScript or PHP, some of is work in critical systems.
Systems that in one way or another allow our world to keep working.
What if DNS stop working? What if the service that get unemployment claims stop to work? What if the system that manages patients in a big hospital stop working? What if an avionics system in a big Boeing is done wrong? What if a database that keep track of citizenship corrupt data?
Those are problem just as serious as bridges falling down.
Some structural engineers build houses some other huge bridges. Some software engineers build carts for e-commerce, other fundamental systems of our world.
It doesn't mean the job is not important. It just means it's a different job from the other job titles which have existed for hundreds of years in the physical domain.
Programming is more like being a lawyer than engineering. But let's stop making analogies to other professions and just call it what it is: programming.
Just answering the question, not saying that it's true: it's seen as describing someone who has opinions about how to develop software or design systems without having the engineering expertise to back up those opinions.
Whether they have the chops or not, the Architect role has little to no skin in the game. The half-life for their knowledge of the system is on the order of a year, and it's a role you want some longevity in.
I've had better luck splitting architecture up between three or five leads (not four).
This is usually the problem, especially with Java architects. The many that I've encountered are often using dated methodologies/tooling that have been eclipsed by something else. The challenge is often keeping up with what's changed in the last x years, which has little incentive if one does not program much if at all.
I’m not just talking about industry standards. The system slowly changes away from them every time the people doing the work disagree, and sometimes even when they don’t. Eventually their model of the system and what it will do with new inputs or requirements becomes fiction.
I've seen some engineers making a distinction between "programmers" and "developers". The second imply "creating (developing) solutions to broad problems" where code is "just" (while a big) part of the solution.
There is no "developer" in the list, but "system architect" is what match the definition.
I get the feeling that it isn't the main Rust community that does that kind of thing. Most of the actual library authors and major Rust users I've interacted with and seen in the community seem to be very level-headed about it and don't think that it is a panacea.
its syntax is too irregular and permissive. (too much ruby?) people tend to disagree, but syntax is very important. that is, in fact, why python has won the scientific community. we don't wanna be spending brain cycles deciphering syntax.
as a side note, we blamed java for being verbose for years. in retrospective, java was right. i have never seen a piece of java that i couldn't understand. i may not know why the code is doing what it's doing, but i always know what the code is doing.
java has stellar readability!
with rust, only time will tell. my gut feeling is that the readability will not help the language when programs get old.
The scientific community just want's the easiest language that gets the math/job done. They focus on the science and don't want to be bothered with the rest. They'd still use Matlab if that got the job done.
Java is pretty much the opposite, very large focus on architecture with DI-magic and extremely verbose. The lasagna building has gone out of style and never
reasoned well with scientists which is why they never used it in the first place.
Can you elaborate on what exactly you don't like about Rust's syntax? I'm always surprised when I hear this, because a lot of the things that get pointed out tend to have good reasons for the way they are.
But it doesn't matter. If the language is unreadable, even if every syntactic decision followed by necessity alone from a set of first principles, it wouldn't prove the language was readable. It would only prove the selected principles necessitate an unreadable language.
Compare [x for x, y in v] to v.iter().map(|&(x,y)| x).collect::<Vec<_>>(). There is a good reason for every bit of ugliness, but that does not change the fact that it is ugly.
I agree that the snippet you gave is ugly, but I also think that it's not really the most straightforward way to right it. Any time the type that you're collecting into isn't inferred, you're free to define a binding and just type annotate it. Also, the lambda you gave is not defined in the straightforward way I think most people would define it. Putting those together, you get something like this:
```
let vec: Vec<_> = v.iter().map(|pair| pair.0).collect();
```
I don't think that's really _that_ ugly. Yes, the pithy Python example you gave is simpler, but by the same token, the assembly you would write to achieve this makes the Rust look really simple. If you're going to try to write efficient code in a systems language like Rust, you're going to need to express things more precisely than you would in a scripting language like Python.
Readability is very often nothing else but habit - code which looks like code you've seen often enough looks well. Case in point: The first example is just gibberish to me and I needed the second one to decipher it.
Also, I would write the second example different:
let r: Vec<_> = v.iter().map(|(x,_)| x).collect();
In my opinion that's superior in readability to both of your examples, but probably also only because I'm used to it.
These all seem like small personal preferences to me, which are entirely valid; I don't think it's possible for a language to have a syntax that pleases everyone. But the comment I was responding to described Rust as having an "awful readability problem", and I don't really see that being described here. In particular, the comment I was responding to described Java as having "stellar readability", so mentioning the generic syntax of Rust really surprises me. Is `Foo<? extends Bar>` really so much better than `Foo<T: Bar>`?
PL/I has done it, famously, and just as famously the language has turned out horribly misdesigned and complex, and it also has missed out on most new ideas. (Still in use though.)
The problem I had was basically the IDE integration in VSCode. RLS was okay but unreliable. And if it only works most of the time, it may as well not work at all. Especially when it only sometimes gave me code completion and type checking (A lot of "unknown" would fill my code).
Then Steve pointed out Rust Analyzer in a previous thread and I was off to the races. Rust Analyzer has gotten _so good_. Having a VSCode setup that gives me immediate feedback for my mistakes and code discovery makes a huge difference (to me at least). Maybe a bit of feedback is that I wish Rust Analyzer hadn't been so hard to discover. Though maybe that's just because it was new.
That, combined with my nightly march through The Rust Book has me well beyond, "I wish I could learn a systems language but !@#$ C and C++ are just so complicated and unforgiving" and into "wow, it's no-longer a matter of _if_ but a matter of how much I want to hone my understanding." Rust is a beautiful language that way. It guides me away from rookie mistakes that would leave me disenchanted after hours of debugging something dumb. (It's hard to be unrelentingly dedicated to learning something new now that I have young kids. When I was a teen it was easy)
I don't want to come off as a Rust fanboy. I have yet to implement much of anything (though hopefully by next year I'll have a Game Boy emulator to show you all). But I want to give thanks and proselytize a little because it has been such an empowering experience.