I think the presenter is honest, down to earth and real. No bullshit. I'm an experienced programmer in C, Golang, Dart and other scripting languages. What she is saying, makes lot of sense. She convinced me to dig deeper into Rust language
@@prodevus Hey Robert, its good, especially the compiler - it helps a lot. Like one of the best compiler messages I have seen. Learning Rust even now and I havent lost interest till now. You will like it. The community is welcoming and helpful.
I just like that rust has a package manager. Makes making things so much easier, especially for web development.There's no other low level language that has a package manager
You're telling me. This makes it 60% easier just by that alone. Package management in low-level languages is a PAIN. A $(*#$_( PAIN. Rust makes modern development better, and quicker
@@devsurendra8015 When you need a library, imagine having to go to google, doing a bunch of research, Once you find it, you have to go to github and download the entire repo. Then extract it into a folder inside your project. Then after that, you read the instructions on the github page which are complex, just to get it to compile at all. You end up fiddling with it for 40 minutes, but finally it compiled! Except that your project directory is now littered with that library's folders. - But that's not it! Imagine now that it has been some time and you shipped your software. You just found out that there's a CVE on your product. Why? Oh, it's because you didn't update that one library often enough. It's not like there was anyone or anyplace or any command that told you it needed updating. You need to check the 10+ dependencies homepages to see if there's an update. Ok, so you update it. Wait, what? Your project won't build. Ok, 2 hours later after doing extensive Googling it finally built. Now, let's compare that to a package manager / Rust: - You need a library. - You go to crates.io and search for one. - Docs are already linked at the same place they always are. How lovely. - You place one line in Cargo.toml - It downloads automatically, configures everything, and compiles (seriously, I've never seen a Cargo.toml library even fail compilation, there's almost never any configuration ever required). -> Time spent: 4 minutes. Code entered: One line of code. Time to update right? Oh wait, if you set up Cargo.toml correctly, it already downloaded updates automatically for you. Granted, you might still need to check for updates like the other one (sometimes you need to lock it to a version), but regardless, updating is just a one line edit.
The most headache bug is not when you cannot get the code running, the most headache is: the code runs into problems only once when running thousands of times. Rust is the future!
A day after this was posted and it was out of date in regards to private crate hosting now existing. That's a good sign. Developments are constantly moving forward.
I personally believe that thorough and significant problems warrant seriously considering the BASE DESIGN. This sounds like the reason for a Rust. I will definitely be looking into this language (while I learn all these others too!). In a side bit of trivia, my dad made his living as a corrosion engineer (thus rust was arguably his business; though he was fighting corrosion in water systems).
i can totally see senators passing a bill banning pointers altogether after the first minute you try to explain memory safety to them just to get away from hearing more of it.
@@default632 Isn't it ironic? Don't you think? It's been used this way for at least around 100 years. It means more than just sarcasm or incongruity by now.
For me it feels like a win-win. And when u really need to have that extra performance with small memory tricks... u just use unsafe in a confined way. Safety as first priority... but still be able to do unsafe in a small contained piece of code is such an elegant solution. And yes they make tradeoffs... but it a way they get most out of both and then if u really need to make extra tradeoffs... there is always a way.. but it does take friction.
I'm just starting out in Rust, coming from high level languages, and some simple-ish Arduino level C++. Rust certainly seems like the right ways to go. Great video, gave me some reassuring background, as well as some useful technical detail.
@@egorsozonov7425 According to traditional nomenclature Rust is a high level language, just like C. Basically everything above machine code or machine code equivalent (assembly) is considered high level. That's not to say that this binary classification is particularly useful these days when virtual machines and interpreters are everywhere.
I like the comparison with Brakemen vs. AirBrakes. Thanks sharing that history, it's fascinating. And also, thanks for sounding the alarm. Software industry is, ironically, reluctant to change its own ways.
I'm a Ruby and Go developer. Have learned Rust but haven't done andy real project in it yet. My understanding is that Rust is best at its memory security and performance. But the overhead on programmers is not trival. Meanwhile the goroutines and channels in go are really gold. Rust can do silimar things but not as easy. So for the next 40 years, there will be new languages which would make both go developers and current Rust developers, even including Ruby developers, to smile in front of their keyboard.
@@HermanWillems I don't really dislike C++, it's just that Rust is an elegant language, and I'd rather use it. Seeing the Rust community disrespect C++, however, leaves a bad taste in my mouth; hopefully, they know that Rust uses LLVM. I normally just use C anyway.
Loved this talk. Especially how open she was about Rust's current shortcomings, that is an excellent sign for anything. With all the current popularity, you could easily just evangelize the hell out of it and have everyone in the conference cheer, so I love that. I have no need to use Rust in my current development role, but I may have to pick it up for fun soon. I'm Rust-curious now
C is showing its age, even as a high-level assembly language. #include is awful. Arrays that don't know their own size are awful. I could go on, but it would be beating a dead horse.
@@kopuz.co.uk. listen pal, if treating all people equally and punishing assholes is some kind of "evil deep state Soros ANTIFA SJW" to you, you have my regards. There's nothing bad in their code of conduct.
1. Qt doesn't fix the problems with the c and c++ arrays. They just copied the std::vector with almost no difference. 2. The mathematical library in Qt is not immutable and not guaranteed to be binary compatible with OpenGL like glm. 3. The strings in Qt are encoded in utf-16 instead of the better and now world standard utf-8. 4. Qt a bit resembles systemd. They want to create an ecosystem which literaly does everything so everybody will depend on them. They even replaced OpenGL with their own variant. 5. Qt follows this strict object oriented design, which was always controversal, but now everybody agrees that it become obsolete. 6. The signal slot system doesn't fix anything but make the programming more complicated and sometimes buggy. 5. In other environments, loke web apps, android or wpf, it's easy and self evident to build the gui from a text editor with xml or html code. It's not true for the Qt gui, which I found hard to build from the text editor.
But the documentation of Qt is better than anything else I found and it's beginner friendly. That's an overlooked part of success in the programming world.
Saying you'll never break compatibility is a bit misleading, even with the given caveats. There have been breaking changes slipped in, even without an RFC.
Nice talk Carol thank you. Im using Go quite a bit these days and I actually think rust might be a nice complement to go for different problem domains.
Her energy, enthusiasm, knowledge, optimism, and open-mindedness combined are nothing short of adorable. As someone equally in the business of building a potential disruptor of status quo, the part at min 46:51 particularly resonates with me: "Let's make new mistakes!". I like the sound of that mindset
This talk is well done, but I think it overstates the innovative aspect of Rust. First of all, languages with automatic memory management have existed for many years. Lisp is almost as old as Fortran. Properly implemented garbage collected languages are memory safe and these days can deliver performance competitive with Rust (see D vs. Rust benchmarks, for example). It should also be understood that the automatic cleanup code when exiting a scope is indeed inserted at compile-time, as Carol says. But she contrasts that with a run-time garbage collector, but she isn't clear that that cleanup code does its work at runtime, just as a garbage collector does. In essence, the memory management strategy used by Rust is very much like an incremental garbage collector, except that the decisions as to when cleanup is done happen at compile-time (I'm not suggesting Carol was being dishonest here; I just think the runtime component of this wasn't completely clear, probably a result of limited time to deliver a lot of material). It is also true that the memory-safety rules in Rust are very restrictive, too restrictive for certain situations. And so, for example, they provide things like "unsafe", which Carol mentioned, and Rc, interior mutability, and locking mechanisms that allow you to have multiple writers to a single object. When you take this approach you have, in fact, become a component part of an incremental garbage collection scheme (no pun intended) that works fully at runtime. This is one example of the fact that with Rust, you the programmer are much more involved in memory management than is the case with a conventionally garbage-collected language. When you are obeying all the rules you must obey to satisfy the borrow-checker and lifetime-checker, you are an active participant in Rust's memory management strategy. And this is one of the aspects of Rust that make it so hard to learn. See the Rust user forum that constantly contains questions from utterly bewildered people struggling to understand why the Rust compiler hates their code. I could go on, but I will not. Don't misunderstand me -- I think Rust is extraordinary work. But I think the cost-benefit balance of Rust is sometimes misunderstood, perhaps leading people to use Rust in areas where, in my opinion, there are better tools for the job. Rust is hard to learn, hard to use, and the compiler is extremely slow, thus slowing the edit-compile-debug cycle. I would not pay that price if I were tasked to implement a garden-variety application to run on today's super-fast desktop or mobile hardware. I would use a garbage-collected language like Scheme, Haskell, Go, Nim or even Python (which, while much slower than Rust, is frequently fast enough; and Python is much easier to learn and write, reducing development time) avoiding the considerable price of Rust's difficulty. If I were writing code with a real-time constraint and/or code for an embedded system where the memory foot-print was an issue, then absolutely Rust becomes a strong candidate and I'm quite sure I'd choose it over C or C++.
I programmed in PL/1 for nearly 30 years. It is a fairly good language. I never bothered to learn the newer PC based languages because they were always changing and becoming extinct nearly every twelve months. Who wants to learn a new language only to have it be replaced by another "new" language one or two or three years later? If Rust can become a stable long lasting language, then I say that's good. There's too damned much chaos, "diversity", fragmentation, and change in the programming language landscape to make anything very productive any more. It is a tower of Babel.
C is like a bike without training wheels. It can crash, it can go faster, whatever rider likes to do. I sometimes like training wheels when I want to drive worry free. And sometimes I like to go crazy without training wheels. I think there is no perfect language. It depends on the problem which is to be solved.
C/C++ is one of the wheels of programming. The wheel has been used for thousands of years all across the world. Still being used today. Its not going anywhere. The other wheels being Assembly, etc..
@@kristupasantanavicius9093 The other 150 wheels being other languages. The sea change that Tesla Motors et al. initiated in the auto industry will inevitably come to SW development, too. Resistance is futile.
@@quantumbubbles2106 What he is saying is that C is right next to being assembler language, it dominates a position close the the machine and is structured similarly to the operating principles of hardware. That can't really be casually replaced by another language unless that language is fundamentally similar to the computer and hence similar to C.
While checking the comments, I found that this discord is quite heated. First, as a programming language, every one has its own concept, and the rust programming team seems to be fixated on the memory leak/usage issues, this may be helpful in some domains (mainly domain like game programming), but looking at other sides, comparing C to rust was somehow absurd, C is a solid programming language that has been on the scenes for half a century as you claimed that rust would last in the next 40 years, but generally speaking, I found rust concept interesting. I tried coding some small scripts using rust, and my first impression was that there is a bunch of nested data on it and complicated syntax (compared to other languages I'm working with), but I noticed some other good points, compared to the same scripts I made in other languages, rust did truly run them with the minimum allocated memory. And while there are some loose compiler of other programming languages, rust's compiler is a strict teacher who won't let a mistake slip in the program and reject it.
I really love how non-hesitant Rust is about warning you of inappropriate code, which contributes to the consistency. It does not allow you to make mistakes, even if it doesn’t affect your script yet
I haven't really tried Rust hands-on, however, from the talks/comments I got the impression that it's harder than the languages in its class, but one spends time and effort in the name of correctness, instead of more rapidly writing an unsafe code and then spending an undefined amount of time on debugging, when some bugs may not even be found at all. A lot better to spend time and be sure its done at the end instead of getting tired looking for ghosts and stating "it's good enough".
@@Hexanitrobenzene What people are interested in most nowadays is fast development. If you try rust for the first time without a preknowledge you will suffer. The most irritating thing that made me shy away is that every time I was trying some crate I find the documentation outdated and I need to look for help. Don't misunderstand me there are lot of qualities for using rust (you won't need any external bindings if you are satisfied with the available crates). But in the end it's still hard to become fluent in rust without any formal learning or pushing yourself (especially if you did use high level language from the beginning like me). Syntax is still little hard to master, it is unreadable (for me). you need to look every once in while if they did change something
I like that Rust provides a solution to the problem of memory (un-)safety, but I feel that Rust forces you into writing code a certain way. I really don't like the idea of just how explicit everything is. Things like explicit borrows and implicit ownership of objects rather than explicit result in some rather non intuitive semantics. Using Chapel as an example, everything is implicitly borrowed but you can explicitly make it owned, shared, or even 'unmanaged'. Rather than being 'opt in' or opt out by default, this hybrid makes it painless to write code while preserving the original program semantics. Anyway, I digress. Rust seems great for industry software where you want to write something once and just never touch it again.
@@KilgoreTroutAsf From what I can see, you have three options... 1) Use a Communicating Sequential Processes (CSP) pattern via Rust's Channel, similar to Golang (message passing) 2) Use some kind of mutex or reader-writer locks to enforce the single-writer or multiple-reader pattern. 3) Use 'unsafe' to mark code as unsafe and do what you want. Considering that Channels are not without their downsides ( songlh.github.io/paper/go-study.pdf ) and locks have a plethora of issues that include, but is not limited to Priority Inversion, Deadlock, Livelock, etc., of which Rust does not solve or attempt to solve at all. The fallback, being the marking of code as 'unsafe', just feels like an additional chore to me, and would result in foregoing memory safety. What I'm trying to say is that, Rust cannot solve thread safety. By restricting the types of programs users write, it can _limit_ the number of scenarios where thread-safety comes into question, but it cannot 100% annihilate race conditions, it can only prevent data races caused by unsynchronized access.
@@MoltarTheGreat I am by no means an expert in either golang nor rust, as I have only recently begun to read about both languages. I have nevertheless a more than passable expertise in C / C++, POSIX threads, OpenMP and MPI, since I have been developing parallel and high performance code for several years. As far as I understand, one of the strong selling points of Rust with regards to thread (and memory) safety is its robust static analysis, which is capable of optimizing out many unnecessary locks and even use optimized concurrent datastructures whenever possible. I may yet lack a deep(er) understanding of the actual scope of the language, but considering the amount of time I've spend debugging MT code, and the performance impact of using overly safe MT classes on modern manycore processors, Rust sounds like a promising starting point from which to address both problems at the same time.
One of the cool things about programming with C when I was young was using the memory unsafe features to do things cool. Of course these were very machine specific which made the code not-portable or rather would cause problems if moved to another platform. I no longer remember the details. It was over 40 years ago.
This is quite an important feature in the homebrew community where they are explicitly looking for buffer overflows and the like to gain access to the hypervisor. As I sat here on my flashed PS Vita watching this video, Rust will likely see the end of those days, or make it exceptionally hard. Still, I'm sure they'll always be hardware exploits!
New keywords making old code invalid could be fixed with a find and replace. When you decide you want to update you can run a search that matches your code to a list of the new keywords and asks do you want to keep this or replace it with a new variable/function name for instance.
@@Mike-iz9kh I know this is a very old thread, but as explained in the talk, dependencies don't have to use the same edition as your project. So you can switch to a new edition, and you only have to worry about code you've written yourself. If you have your code split into multiple projects, you could even switch one of them and it would still be compatible with everything else.
I think there needs to be a talk comparing rust against java. I know that rust was originally thought of as a systems programming language. But, I am of the opinion that it would work really well for enterprise software as well. Apart from the fact that rust is way faster, there are some advantages to the type system. On the other hand, java lets you do reflection and instrumentation which are used heavily in all java enterprise frameworks. It still may be a worthwhile discussion.
I think they can add instrumentation to High level representation part of the compiler at a later date. Maybe just compile time instrumentations cause of zero cost abstractions policy?
Put simply, Rust is too young to be considered for enterprise. Java has been around a long time and has solutions for almost every case. Rust definitely produces faster more reliable applications, but selling it to CEOs and high end clients is difficult at this point.
Fantastic talk. Came here after john Carmack tweeted about C and Rust. Very promising. I think rust is especially well suited for software that would be functional safety certified.
For whatever reason someone chose Rust as the name, believe me, it *will* sound like a bad plan for a lot of people, even if it is a completely valid reason, it will definitely not be a good first impression You’d probably be better off with Stainless
I can't imagine why a Ruby programmer would forget to mention Rust's HLL support in memory-safe tuples, vectors, and hashmaps. Other features like iterators and closures might spark some interest from the OO crowd. This talk started out slow and awkward, but got better later on.
I've been learning Rust for the last couple of weeks. I've over 20 years of dev experience, mostly in C# and Go (lately). The compiler is absolutely awesome and a joy to work with, but the language syntax decisions boggle my mind for something designed to be modern. Also I am SO THANKFUL there is a Code of Conduct, because otherwise I wouldn't feel welcome and safe /s
Codes of conduct are part of the landscape now. It's best to just ignore them and don't get caught up in the drama. Ignoring my own advice for a minute -- funny thing is that the Rust core team had some drama where they ignored the decisions of the Rust mod team, and the mod team resigned in protest. A case of not being able to follow their own rules.
E.g. what is the advantage @18:30 in that very basic example? Who thought is a good idea to make assignment operator as moving by default? The actual error is "move occurs because `x` has type `std::string::String`, which does not implement the `Copy` trait", even then the line "y = x" should be NOP and optimized away as y is not used anywhere, thus there should not be an error, but a warning about unused variable.
@@courier7049 it is optimized as if y doesn't exists. But using x after it mobed into y is a semantic error. If you don't do this restriction, you will have use after frees or double frees.
From what I know ATS is arguably the most safe programming systems language out there and without having ANY performance penalty, the problem is that only 10 people in the world use it :/.
Well this reminds me HOW GLAD I should be that the programming language that I have been using in the last 2 decades+ has NO MEMORY problems whatsoever, especially on a Web Server. When I put those EXEs on a web server, they often keep running for weeks and months without any leakage or errors or restarting. It's great to be able to concentrate on BUSINESS LOGIC, web interface, data, reports, and what the businesses require rather than which memory structure will not blow up. I have never had a business asking me for memory cells and objects. They are much more interested in "where is my web screen" and "where is my report". Visual Foxpro is so reliable and problem-free that programmers who used it typically did not need anything else from Microsoft for years and years. No wonder that Microsoft tried to abandon it. As an analogy in medicine: There is much more profit in cancer treatment than in cancer free. Foxpro still works like a charm for me and my clients. Efficient coding, reliable running, happy businesses. The only bad thing about it is that I cannot write any operating systems or computer games with it. But none of my business clients ask for that. Screens, Reports, Data In, Data Out etc.
this lady: "the software industry tends to be a bit arrogant at times" also this lady: "people kinda should be legally required to use our language instead of c"
@@WySBoonami someone wasn't paying attention in the talk: she was saying that about 3/4 of security bugs in one Firefox component wouldn't have happened in a memory safe language. Therefore, should safety critical systems be written in a memory safe language to eliminate lots of bugs? Seems reasonable to me.
I tried to learn Rust around the time this came out, but just didn't have the discipline. It seems to have come a long way since then, so I'm gonna give it another try. If successful, I have a feeling it will be the last language I need. Just hope they can improve the compile times. :D
It would have been great if Rust used the C syntax, in addition to bringing the new features which C does not have , this way the lives of programmers will be easier
Rust syntax is mostly C syntax; the main differences in syntax are based on language features Rust has but C doesn't. The only thing I can think of that's not C syntax with no feature-level justification is types, which are much easier to parse in Rust than C (so, the compiler can do less work). That and pointers, which are just a flat improvement.
With a few decades of "real world" C and C++ (and some others) under my belt, the slide that sent chills down my spine was the slide that showed "Everyone"... Everyone can (usually) make toast without burning it. NOT everyone can design & prepare a 7 course meal for 12 diners. (I certainly cannot!!) Production code written by those who cannot clearly formulate the problem at hand is ... ubiquitous. While I commend the effort to "raise the guardrails", I fear that rust will be seen as a gateway for hobbyists to work on systems that are beyond their comprehension. A craftsman does not blame his tools; however, amateurs do.
Eh, that slide was overly optimistic. Rust is not for the "everyone" crowd. You have to really care about systems programming without a garbage collector to invest the time to learn Rust. What you should really take away is that there is no mythical "professional" C programmer that can avoid making memory errors in C. Or if there is, there aren't enough of them, because even the most elite companies that pay big salaries still write C code with the same old problems. Rust is about giving good systems-level programmers the right tools.
@@thecsciworker291 Well, there is that :-) It's a good treatment on railroads if you slept/skipped or whatever through. I have heard way, way worse! The brakeman data is all true--it was truly a terrifying job.
I've been tinkering with Rust since 0.3 and have generally found it pretty favorable, but the segment in this video where it gets compared to C/C++ makes it seem like the social justice warrior of programming languages, at least to me.
@@musicaccount3340 > I'm curious I doubt that based on your initial comment, but I'll answer your question. Their enumeration of immutable human characteristics is part of the typical left-wing world view in which this statement is assumed not to be true by default, similar to how BLM activist make statements that are obvious to anyone with the implication that there are those who disagree. Additionally their mention of "safe" environments, "harassment" and feelings points towards a typically left-wing authoritarian world view that seeks to control every aspect of people's lives and at the same time infantilize them. This even explained further down where they literally tell you to never defend a point if somebody disagrees with you and to even apologize for making your point in the first place. As a cherry on top I even found a furry among their discord moderators. ;-)
I feel reasonably comfortable with using C++ and Haskell. Both have speed if you want it. C++ has syntax to prevent some common mistakes, while haskell has syntax to allow them. Plus it is much harder to write a haskell program that does something wrong - if it compiles it works.
Rust is far safer (stricter) than Haskell. For instance: You cannot have a non-exhausted match in Rust; and panicking in Rust is strictly programmer error, unlike runtime error in Haskell.
Well, could qualify the arenas of software development where a closer-to-the metal approach that Rust facilitates is warranted. For instance, lots of cloud services and cloud infrastructure software has been written in Go, which has GC memory management. Devs tend to find Go relatively simple to learn (very concise language) and its primary concurrency model is relatively easy to learn and yet an effective concurrency model. There is arguably a lot more cloud services and cloud infrastructure software to write vs device drivers and OS kernels. Which language (Go vs Rust) is better tuned to cloud development in terms of programmer productivity, adequacy of performance and impact on resource consumption, and software defect rate per crucial matters such as security vulnerabilities?
Rule of thumb: Golang for cloud services, as you say. Rust for systems development, device drivers, OS kernels, terminal applications, etc. where low-level security matters most, as you say.
Read up on how the team behind Discord moved from Go to Rust because the garbage collector in Go was biting them in the behind. Also, Go allows data races in their concurrency model, whereas in Rust data races are ruled out by the compiler.
Pro tip: When showing off your language, don't show the projects that caused so much hate (like Firefox Quantum release which signaled all the people I knew who actually still used Firefox to switch to Waterfox - including myself, though I only used Firefox for the rare compatibility reason anyways)
Swift is not suited for systems programming. Is it a great language, though. I feel overall, corporate languages have proven to be more well designed from the get go (powershell, Swift, c#, swift, go). Anyone knows that retrofitting features while keeping back compat makes the language messy.
I believe that any language used to build a reasonably large code base which is going to cost too much to be rewritten and too important to be decommissioned is going to last forever. I still see open job position for Cobol. So once you get into the market you are going to stay. The point is how large this niche is going to be. Rust is basically in competition with C and C++, where a compiler exist, in case you need to write a new product or fix very limited portions of your legacy code. There might to be some overlapping with Go and a curious scenario where Web ASM becomes a thing. I think this niche is crumpled.
The CCS component sped up dramatically, because of parallelism. Attributing that to Rust is quite disingenuous. Mozilla could have used C++, or C for that matter, to introduce parallelism and achieve the same increase in speed. It would benefit her more to discuss the benefits of Rust rather than demeaning C and/or C++. Listen, we've always known that C is a raw no- seatbelt language. If you want a seatbelt, you have to build it yourself, but the language doesn't inhibit you. However, I do see the benefits of Rust, but a big red flag is the complexity of the language. That's also the problem with C++. The main strength of C is its simple syntax.
They could have used C++ for the new CSS engine, true. And in fact, they tried. I think even multiple times. Yeah, found the blog entry: blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html They mention they failed with the C++ attempts. But sadly don't elaborate on why.
In some talk they explained that they tried to do that in C++ but they never managed to get it to work reliably. So, in that sense the speed improvement was made possible by Rust.
@@Asrashas: "But sadly don't elaborate on why." Or when for that matter - I believe it's called "(imp)lying by omission". That article was written in 2017 about a project that was conceived in 2012 so when they say "Mozilla made two previous attempts to parallelize its style system in C++", they mean in C++03. It's 2019 now and C++20 is about to be finalized. The safe, parallel operations you can do in literally a line or two of standard, modern C++ is incomparable to C++03 or indeed standard, modern Rust.
Very nice, great effort. I have been writing software for 40 years. With the changes I have seen in everything i can guarantee you it wont be. I worked at Eastman Kodak 35 years ago. I was guaranteed PL/1 would be a language that would be around in 50 years. The last PL/1 programmer i knew of was 25 years ago. Almost 10 years ago Kodak died as well.
@@Ou8y2k2 Careful, James Cameron might sue you.🙄(joke) he wrote terminator exactly 40 years ago. It Predicted the AI factories would be up and running by now at full capacity. In a mere 7 years in 2029 they would figure out time travel. Thanks to time travel the AI horrors would be retroactively fixed.
No. I think he thinks its too young yet. But they are busy implementing Rust in the build for the kernel as people are going to write drivers in Rust. He only wants it to be done correctly so that it will not become a mess. Though i don't think he will accept Rust for core kernel code yet and for a long time to come.. he doesn't hate it nor love it.
Torvalds is approving, but skeptical about Rust in kernel. He doesn't want to integrate it into the core (which is good, it would add a bunch of headache) but is otherwise open to experimentation
@@FlaviusAspra Well, in other areas at least, reliability is usually measured with nines. 93% is one nine. That's not a lot of nines. Linus Torvalds is well known for the motto "Never break userspace!" and has chewed people out pretty badly over even anecdotal evidence that a kernel change has broken someone's program. Its common for libraries to maintain support for deprecated functions for decades. I dunno, is there a context in which breaking code in the whole percents is relatively good? What are those numbers like for gcc? Is it worse for Go?
From experience I think a lot of users answer the wrong thing to this question. Generally it's updating dependencies that break your code, and since Rust has a bare-bones stdlib you need to use a lot of dependencies to get anywhere. So for a lot of people, updating the compiler probably didn't break much, but updating their dependencies with a similar command usually breaks things. For a user of Rust I don't think it's common to really see the difference between "updating the compiler" and "update the library to generate random numbers, make http requests, or parse JSON".
between rust and cpp, which one should I choose? I am a student and I want one best programming language help me solving problem in my life. cpp is one very efficient and very interesting. cpp sign traditional programming language, but Rust most like future programming language, even Rust is not mature than cpp now, so Rust and cpp, which one I choose? thanks...
What kinda student are you? Are you studying software development? What kinda projects do you intend to work with? Systems development? Then learn both, they are similar enough that most of what you learn for one will apply for the other, unless I am mistaken. Also you won't find one programming language to solve your problems. You will need different language for different problems (at least if you want to do something efficiently). Right now cpp is huge in systems development, but it will eventually (5, 10, 20 years) be replaced, either by rust or something else. Right now rust looks like the most promising from my amateur point of view. But in the end, you will have to learn more than one language (I am a biologist I am learning 4 scripting and/or programming language! Bash, R, Python and Rust) so don't worry about learning the "wrong" language.
C++ still reigns supreme in terms of adoption, and when using a modern version, at least C++11, and carefully following best practices, it's actually not so bad. Rust is certainly interesting though, and may gain ground in the coming years. Why not both? :-)
There are architectures in the embedded world where even even C++ can't go. So C and assembly will continue to exist. And therefore so will c++. If rust can take out C (not c++) than perhaps we can all use air breaks.
To run c++ on a processor you need a compiler, a std library, and a runtime environment. For smaller 8/16bit processors, these don't exist. For the 32bit embedded processors, the c++ tools are pretty terrible. (So bad that your not debugging your own code, but the compiler too). Also most embedded systems you can't use any heap and there is no OS. So there is no point of a std::library on these processors anyway. With all those restrictions I think you could technically write C++ on these systems, but you would have to be a master in what the compiler is doing with your templates and classes. And that kind of master can also write good C. So they would just use C because that's all that the hardware supports. So there is no incentive to create c++ for these targets either.
@@thomasw.4298 Wasnt aware that theres no c++ compilers for platforms in which c compilers exist. I dont agree that you need a runtime environment or an std library for writing c++ or other high abstraction langs like rust, d, nim, zig, etc. I do agree that you cant use the std libs since theres no OS but you wouldnt have to be a master in the compiler to know what templates do since theyre a compile time concept (tip: if you dont know, you can try it in godbolt to see the produced machine code). I believe the incentive of using a language with more abstractions is that it can 1) allow better code generation with stricter rules on aliasing, alignment and inline 2) can shorten the amount of code you write using abstractions like lambdas, pattern matching on sum types, richer macros/type-system, iterators and struct method access
"I don't think Government is going to improve the safety of software" and the things said immediately after really give this whole thing a very libertarian feel
I recall one of Rust authors said that Rust used research that is at least 15 years old, had no fancy new ideas, and meant to be practical, hence "rust" seemed appropriate.
@@PetrGladkikh it has many meanings at the same time. But yes. The concepts Rust is build on are not new. Its just that you cannot implement them in existing languages because its so fundamental to the core.
cool talk... however when she says rust makes low level programming for everyone, not just superhumans, is incorrect. its for crabs. But srs tho, rust is by no means an easy language and i would argue even harder to pickup than c, at least initially, we'll see.
The safety subject would have been interesting, comparing what Rust brings with Ada / SPARK for example. Mentioning railroads but avoiding the embedded systems topic and other tools/languages than the C-related ones is a bit strange to me.
She looked so proud of that story that served absolutely zero purpose other than showing some loose association with safety between two totally different industries? Dumb. I couldn't even watch this chick on 3x speed.
@@bryanmcconnahea9873 also the association between government regulation preventing innovation and the fact air brakes are still used today makes it seem that the railwaymen were ahead of the curve seeing the hinderance of their industry. Rust will be replaced by the motorcar.
Saying C is inherently unsafe is saying computers are inherently unsafe, you can do anything a computer can do, I think she underestimates the number if incompetent coders. Also with open source problems get solved before exploitation usually Still wanna learn Rust too though.
C is inherently unsafe because it doesn’t stop you from doing unsafe things. Rust only allows you to do unsafe things when you ask it to let you do so, and it means that you have specifically audited that code to be safe so the compiler doesn’t have to. In c, the compiler doesn’t audit the safety of any of your code and you have to check all of it.
I think the presenter is honest, down to earth and real. No bullshit. I'm an experienced programmer in C, Golang, Dart and other scripting languages. What she is saying, makes lot of sense. She convinced me to dig deeper into Rust language
Same here. Learning Rust - coming from C# background. Working for more than 11 years now in C#. Exploring other options.
@@PankajNikam Hey man I’ve been doing C# for 8 years and am just getting into Rust now. What are your feelings on Rust three months later?
@@prodevus Hey Robert, its good, especially the compiler - it helps a lot. Like one of the best compiler messages I have seen. Learning Rust even now and I havent lost interest till now. You will like it. The community is welcoming and helpful.
@@PankajNikam Awesome news! I'm getting started right now. I'm ready to dedicate the next 8 years to this!
@@prodevus Good to know 😃
I bet you will love it.
I just like that rust has a package manager. Makes making things so much easier, especially for web development.There's no other low level language that has a package manager
You're telling me. This makes it 60% easier just by that alone. Package management in low-level languages is a PAIN. A $(*#$_( PAIN. Rust makes modern development better, and quicker
There's Zig, really cool, you should check it out.
@@seaoftears2984 still no package manager though
Can someone tell me what's the advantage of having package manager like you said
@@devsurendra8015 When you need a library, imagine having to go to google, doing a bunch of research, Once you find it, you have to go to github and download the entire repo. Then extract it into a folder inside your project. Then after that, you read the instructions on the github page which are complex, just to get it to compile at all. You end up fiddling with it for 40 minutes, but finally it compiled! Except that your project directory is now littered with that library's folders.
- But that's not it! Imagine now that it has been some time and you shipped your software. You just found out that there's a CVE on your product. Why? Oh, it's because you didn't update that one library often enough. It's not like there was anyone or anyplace or any command that told you it needed updating. You need to check the 10+ dependencies homepages to see if there's an update. Ok, so you update it. Wait, what? Your project won't build. Ok, 2 hours later after doing extensive Googling it finally built.
Now, let's compare that to a package manager / Rust:
- You need a library.
- You go to crates.io and search for one.
- Docs are already linked at the same place they always are. How lovely.
- You place one line in Cargo.toml
- It downloads automatically, configures everything, and compiles (seriously, I've never seen a Cargo.toml library even fail compilation, there's almost never any configuration ever required).
-> Time spent: 4 minutes. Code entered: One line of code.
Time to update right? Oh wait, if you set up Cargo.toml correctly, it already downloaded updates automatically for you. Granted, you might still need to check for updates like the other one (sometimes you need to lock it to a version), but regardless, updating is just a one line edit.
Rust starts at 16:05.
@exorientelux ditto
thanks
Thanks!
Thankou thank you
You da true MVP
The most headache bug is not when you cannot get the code running, the most headache is: the code runs into problems only once when running thousands of times. Rust is the future!
A day after this was posted and it was out of date in regards to private crate hosting now existing. That's a good sign. Developments are constantly moving forward.
Learn future legacy kruft today!
@@KilgoreTrout11235 No, learn limitations that have since gone away.
Cool, can't wait to recompile my compiler for 857th time this month
I love all the people missing the point of the talk, and then complaining that a specific technical feature wasn't discussed.
I personally believe that thorough and significant problems warrant seriously considering the BASE DESIGN. This sounds like the reason for a Rust. I will definitely be looking into this language (while I learn all these others too!).
In a side bit of trivia, my dad made his living as a corrosion engineer (thus rust was arguably his business; though he was fighting corrosion in water systems).
i can totally see senators passing a bill banning pointers altogether after the first minute you try to explain memory safety to them just to get away from hearing more of it.
Love her sense of humor: "let's make new mistakes " ;-)
I was wandering, what?! Trains?" Then you said "safe by default". I immediately understood the point :)
Ironic that a man named Coffin would be concerned about railroad deaths.
Is it ironic? really?
@@default632 Isn't it ironic? Don't you think?
It's been used this way for at least around 100 years. It means more than just sarcasm or incongruity by now.
@@BKPrice Well then
There are so many bugs that can be statically avoided... And rust makes very nice compromises between safety and usability.
For me it feels like a win-win. And when u really need to have that extra performance with small memory tricks... u just use unsafe in a confined way. Safety as first priority... but still be able to do unsafe in a small contained piece of code is such an elegant solution. And yes they make tradeoffs... but it a way they get most out of both and then if u really need to make extra tradeoffs... there is always a way.. but it does take friction.
I'm just starting out in Rust, coming from high level languages, and some simple-ish Arduino level C++. Rust certainly seems like the right ways to go. Great video, gave me some reassuring background, as well as some useful technical detail.
You came from a high level language to a high level language. Why on Earth would you think Rust were a low level language?
Because Rust is definitely a low-level language. No auto memory management, raw pointers etc.
@@egorsozonov7425 According to traditional nomenclature Rust is a high level language, just like C. Basically everything above machine code or machine code equivalent (assembly) is considered high level.
That's not to say that this binary classification is particularly useful these days when virtual machines and interpreters are everywhere.
Rust is a mid-level language.
I like the comparison with Brakemen vs. AirBrakes. Thanks sharing that history, it's fascinating. And also, thanks for sounding the alarm. Software industry is, ironically, reluctant to change its own ways.
nobody: ...
Rust language team: hehehe we have :: thats a *TURBOFISH*
I'm a Ruby and Go developer. Have learned Rust but haven't done andy real project in it yet. My understanding is that Rust is best at its memory security and performance. But the overhead on programmers is not trival. Meanwhile the goroutines and channels in go are really gold. Rust can do silimar things but not as easy. So for the next 40 years, there will be new languages which would make both go developers and current Rust developers, even including Ruby developers, to smile in front of their keyboard.
Rust is/will be successful for common-sense reasons....no revelation, nothing special.
As a former C user, I'm never going back.
C programmers have valid reasons to hate on C++, and C++ programmers have good reasons to hate C. Both of them love Rust mostly....
@@HermanWillems lol you are here :D did WW3 start last time?
@@ekrem_dincel it starts all the time.
@@HermanWillems I don't really dislike C++, it's just that Rust is an elegant language, and I'd rather use it. Seeing the Rust community disrespect C++, however, leaves a bad taste in my mouth; hopefully, they know that Rust uses LLVM. I normally just use C anyway.
I would never learn a language which isn´t completely Open Source. That´s why I love Rust
There are many open source programming languages.
Loved this talk. Especially how open she was about Rust's current shortcomings, that is an excellent sign for anything. With all the current popularity, you could easily just evangelize the hell out of it and have everyone in the conference cheer, so I love that.
I have no need to use Rust in my current development role, but I may have to pick it up for fun soon. I'm Rust-curious now
The "unsafe" keyword in Rust is like the plot-twist in every movies, where the story sudden change, or your program suddenly crash.
It's necessary if you want to replace C, both for interop with non-Rust libraries and for interacting with hardware.
@@chrimonyIs it necessary?
Does zig also crash?
@@shrin210 Yes, Zig also crashes. It also has interop with C. In Zig, you get "!" everywhere.
I wouldn't call C a mistake. It was basically designed as a high level assembly language. The mistake was in using as an all-purpose language.
C is showing its age, even as a high-level assembly language. #include is awful. Arrays that don't know their own size are awful. I could go on, but it would be beating a dead horse.
Warning: don't look at comments, full of biased opinion from people has almost almost zero experience with Rust lang. :D
hey lets keep the sjw'ism out of the rogramming world.
@@kopuz.co.uk. listen pal, if treating all people equally and punishing assholes is some kind of "evil deep state Soros ANTIFA SJW" to you, you have my regards.
There's nothing bad in their code of conduct.
@@kopuz.co.uk. of course, sometimes this becomes a problem, and code of conduct is there to control
The governance part gave me the chills from excitement. This sounds very good, almost too good to be true.
If C++11 came ten years earlier or Qt was LGPL licensed from the start, things could be much different now.
Let's make that "20 years earlier"... ;-)
And now it is, so what rust is suposed to do in this world ???
1. Qt doesn't fix the problems with the c and c++ arrays. They just copied the std::vector with almost no difference.
2. The mathematical library in Qt is not immutable and not guaranteed to be binary compatible with OpenGL like glm.
3. The strings in Qt are encoded in utf-16 instead of the better and now world standard utf-8.
4. Qt a bit resembles systemd. They want to create an ecosystem which literaly does everything so everybody will depend on them. They even replaced OpenGL with their own variant.
5. Qt follows this strict object oriented design, which was always controversal, but now everybody agrees that it become obsolete.
6. The signal slot system doesn't fix anything but make the programming more complicated and sometimes buggy.
5. In other environments, loke web apps, android or wpf, it's easy and self evident to build the gui from a text editor with xml or html code. It's not true for the Qt gui, which I found hard to build from the text editor.
But the documentation of Qt is better than anything else I found and it's beginner friendly. That's an overlooked part of success in the programming world.
@@nortonp240 Get rid of old problems, and create new ones.
Saying you'll never break compatibility is a bit misleading, even with the given caveats. There have been breaking changes slipped in, even without an RFC.
Nice talk Carol thank you. Im using Go quite a bit these days and I actually think rust might be a nice complement to go for different problem domains.
I think it's Coughing. Bob Coughing.
What are the problem domains that Go and Rust are best suited for??
Her energy, enthusiasm, knowledge, optimism, and open-mindedness combined are nothing short of adorable. As someone equally in the business of building a potential disruptor of status quo, the part at min 46:51 particularly resonates with me: "Let's make new mistakes!". I like the sound of that mindset
When she said "evolve without losing backwards compatibility" I heard c++ all over again.
They have made breaking changes, there's rust 2018.
@@YoloMonstaaa She does explain that the compiler wont treat 2015 code as 2018 code so it wont actually break.
The rust project is so ambitious, I like that a lot
This talk is well done, but I think it overstates the innovative aspect of Rust.
First of all, languages with automatic memory management have existed for many years. Lisp is almost as old as Fortran. Properly implemented garbage collected languages are memory safe and these days can deliver performance competitive with Rust (see D vs. Rust benchmarks, for example). It should also be understood that the automatic cleanup code when exiting a scope is indeed inserted at compile-time, as Carol says. But she contrasts that with a run-time garbage collector, but she isn't clear that that cleanup code does its work at runtime, just as a garbage collector does. In essence, the memory management strategy used by Rust is very much like an incremental garbage collector, except that the decisions as to when cleanup is done happen at compile-time (I'm not suggesting Carol was being dishonest here; I just think the runtime component of this wasn't completely clear, probably a result of limited time to deliver a lot of material). It is also true that the memory-safety rules in Rust are very restrictive, too restrictive for certain situations. And so, for example, they provide things like "unsafe", which Carol mentioned, and Rc, interior mutability, and locking mechanisms that allow you to have multiple writers to a single object. When you take this approach you have, in fact, become a component part of an incremental garbage collection scheme (no pun intended) that works fully at runtime.
This is one example of the fact that with Rust, you the programmer are much more involved in memory management than is the case with a conventionally garbage-collected language. When you are obeying all the rules you must obey to satisfy the borrow-checker and lifetime-checker, you are an active participant in Rust's memory management strategy. And this is one of the aspects of Rust that make it so hard to learn. See the Rust user forum that constantly contains questions from utterly bewildered people struggling to understand why the Rust compiler hates their code.
I could go on, but I will not. Don't misunderstand me -- I think Rust is extraordinary work. But I think the cost-benefit balance of Rust is sometimes misunderstood, perhaps leading people to use Rust in areas where, in my opinion, there are better tools for the job. Rust is hard to learn, hard to use, and the compiler is extremely slow, thus slowing the edit-compile-debug cycle. I would not pay that price if I were tasked to implement a garden-variety application to run on today's super-fast desktop or mobile hardware. I would use a garbage-collected language like Scheme, Haskell, Go, Nim or even Python (which, while much slower than Rust, is frequently fast enough; and Python is much easier to learn and write, reducing development time) avoiding the considerable price of Rust's difficulty. If I were writing code with a real-time constraint and/or code for an embedded system where the memory foot-print was an issue, then absolutely Rust becomes a strong candidate and I'm quite sure I'd choose it over C or C++.
I programmed in PL/1 for nearly 30 years. It is a fairly good language. I never bothered to learn the newer PC based languages because they were always changing and becoming extinct nearly every twelve months. Who wants to learn a new language only to have it be replaced by another "new" language one or two or three years later? If Rust can become a stable long lasting language, then I say that's good. There's too damned much chaos, "diversity", fragmentation, and change in the programming language landscape to make anything very productive any more. It is a tower of Babel.
They seem to be converging around a common syntax if anything.
@@jwadaow Thank God for that.
@tom smith What are the handful of really core languages, if you don't mind me asking?
Haskell has been pretty stable for close to 20 years now
@@bluenetmarketing
TIOBE index answers this qustion empirically:
www.tiobe.com/tiobe-index/
C is like a bike without training wheels. It can crash, it can go faster, whatever rider likes to do.
I sometimes like training wheels when I want to drive worry free. And sometimes I like to go crazy without training wheels.
I think there is no perfect language. It depends on the problem which is to be solved.
I like this analogy
and GC languages are tricycle
C++: A Language for the Next 400 Years
C++ hooligan ?
in 400...40 years, software will be largely written by AI
C/C++ is one of the wheels of programming. The wheel has been used for thousands of years all across the world. Still being used today. Its not going anywhere. The other wheels being Assembly, etc..
@@kristupasantanavicius9093 The other 150 wheels being other languages. The sea change that Tesla Motors et al. initiated in the auto industry will inevitably come to SW development, too. Resistance is futile.
@@quantumbubbles2106 What he is saying is that C is right next to being assembler language, it dominates a position close the the machine and is structured similarly to the operating principles of hardware. That can't really be casually replaced by another language unless that language is fundamentally similar to the computer and hence similar to C.
air brakes - spring applied, air pressure released
37 years left
35 years left
She convinced me to start using Rust after 10:51 of the start of the video. She better has gotten a raise!
simplicity is what made Go successful.
Yes, we need regulation to stop memory safety errors. From now on, software must be written in Java 1.6
Java isn't type safe though, so memory safety isn't the problem, but it's still unsafe.
While checking the comments, I found that this discord is quite heated.
First, as a programming language, every one has its own concept, and the rust programming team seems to be fixated on the memory leak/usage issues, this may be helpful in some domains (mainly domain like game programming), but looking at other sides, comparing C to rust was somehow absurd, C is a solid programming language that has been on the scenes for half a century as you claimed that rust would last in the next 40 years, but generally speaking, I found rust concept interesting.
I tried coding some small scripts using rust, and my first impression was that there is a bunch of nested data on it and complicated syntax (compared to other languages I'm working with), but I noticed some other good points, compared to the same scripts I made in other languages, rust did truly run them with the minimum allocated memory. And while there are some loose compiler of other programming languages, rust's compiler is a strict teacher who won't let a mistake slip in the program and reject it.
"half a decade" -> "half a century"
Damn, I always mistake 10 years to 100 years
I really love how non-hesitant Rust is about warning you of inappropriate code, which contributes to the consistency. It does not allow you to make mistakes, even if it doesn’t affect your script yet
I haven't really tried Rust hands-on, however, from the talks/comments I got the impression that it's harder than the languages in its class, but one spends time and effort in the name of correctness, instead of more rapidly writing an unsafe code and then spending an undefined amount of time on debugging, when some bugs may not even be found at all. A lot better to spend time and be sure its done at the end instead of getting tired looking for ghosts and stating "it's good enough".
@@Hexanitrobenzene What people are interested in most nowadays is fast development. If you try rust for the first time without a preknowledge you will suffer. The most irritating thing that made me shy away is that every time I was trying some crate I find the documentation outdated and I need to look for help. Don't misunderstand me there are lot of qualities for using rust (you won't need any external bindings if you are satisfied with the available crates). But in the end it's still hard to become fluent in rust without any formal learning or pushing yourself (especially if you did use high level language from the beginning like me).
Syntax is still little hard to master, it is unreadable (for me). you need to look every once in while if they did change something
I like that Rust provides a solution to the problem of memory (un-)safety, but I feel that Rust forces you into writing code a certain way. I really don't like the idea of just how explicit everything is. Things like explicit borrows and implicit ownership of objects rather than explicit result in some rather non intuitive semantics. Using Chapel as an example, everything is implicitly borrowed but you can explicitly make it owned, shared, or even 'unmanaged'. Rather than being 'opt in' or opt out by default, this hybrid makes it painless to write code while preserving the original program semantics.
Anyway, I digress. Rust seems great for industry software where you want to write something once and just never touch it again.
Hi Louis. What is Chapel? Google just gave me a bunch of churches :-)
@@tux1968 google around for "chapel-lang"
Not only memory safety, but thread safety as well, which is WAY harder to debug, and an absolute MUST in many demanding applications.
@@KilgoreTroutAsf From what I can see, you have three options...
1) Use a Communicating Sequential Processes (CSP) pattern via Rust's Channel, similar to Golang (message passing)
2) Use some kind of mutex or reader-writer locks to enforce the single-writer or multiple-reader pattern.
3) Use 'unsafe' to mark code as unsafe and do what you want.
Considering that Channels are not without their downsides ( songlh.github.io/paper/go-study.pdf ) and locks have a plethora of issues that include, but is not limited to Priority Inversion, Deadlock, Livelock, etc., of which Rust does not solve or attempt to solve at all. The fallback, being the marking of code as 'unsafe', just feels like an additional chore to me, and would result in foregoing memory safety.
What I'm trying to say is that, Rust cannot solve thread safety. By restricting the types of programs users write, it can _limit_ the number of scenarios where thread-safety comes into question, but it cannot 100% annihilate race conditions, it can only prevent data races caused by unsynchronized access.
@@MoltarTheGreat I am by no means an expert in either golang nor rust, as I have only recently begun to read about both languages.
I have nevertheless a more than passable expertise in C / C++, POSIX threads, OpenMP and MPI, since I have been developing parallel and high performance code for several years.
As far as I understand, one of the strong selling points of Rust with regards to thread (and memory) safety is its robust static analysis, which is capable of optimizing out many unnecessary locks and even use optimized concurrent datastructures whenever possible.
I may yet lack a deep(er) understanding of the actual scope of the language, but considering the amount of time I've spend debugging MT code, and the performance impact of using overly safe MT classes on modern manycore processors, Rust sounds like a promising starting point from which to address both problems at the same time.
One of the cool things about programming with C when I was young was using the memory unsafe features to do things cool. Of course these were very machine specific which made the code not-portable or rather would cause problems if moved to another platform. I no longer remember the details. It was over 40 years ago.
This is quite an important feature in the homebrew community where they are explicitly looking for buffer overflows and the like to gain access to the hypervisor. As I sat here on my flashed PS Vita watching this video, Rust will likely see the end of those days, or make it exceptionally hard. Still, I'm sure they'll always be hardware exploits!
New keywords making old code invalid could be fixed with a find and replace. When you decide you want to update you can run a search that matches your code to a list of the new keywords and asks do you want to keep this or replace it with a new variable/function name for instance.
rust fix does that though?
That's fine if it's all in a single project. Not so much if you have to interface with lots of other libraries.
@@Mike-iz9kh I know this is a very old thread, but as explained in the talk, dependencies don't have to use the same edition as your project. So you can switch to a new edition, and you only have to worry about code you've written yourself. If you have your code split into multiple projects, you could even switch one of them and it would still be compatible with everything else.
Fantastic presentation- thank you .
I think there needs to be a talk comparing rust against java. I know that rust was originally thought of as a systems programming language. But, I am of the opinion that it would work really well for enterprise software as well. Apart from the fact that rust is way faster, there are some advantages to the type system. On the other hand, java lets you do reflection and instrumentation which are used heavily in all java enterprise frameworks. It still may be a worthwhile discussion.
I think they can add instrumentation to High level representation part of the compiler at a later date. Maybe just compile time instrumentations cause of zero cost abstractions policy?
Put simply, Rust is too young to be considered for enterprise. Java has been around a long time and has solutions for almost every case.
Rust definitely produces faster more reliable applications, but selling it to CEOs and high end clients is difficult at this point.
I have thought on this a great deal.
Now that Linus is also moving in this direction, Rust is going to be the next step in low level development.
I wonder what an example of a Security Fix that would be needed in any LTS release would be, if the libraries have all those safety mechanisms.
What programming domains is Rust best suited for?
Fantastic talk. Came here after john Carmack tweeted about C and Rust. Very promising. I think rust is especially well suited for software that would be functional safety certified.
For whatever reason someone chose Rust as the name, believe me, it *will* sound like a bad plan for a lot of people, even if it is a completely valid reason, it will definitely not be a good first impression
You’d probably be better off with Stainless
Totally disagree. Different populations have such different tastes, but I for one would hate "stainless"
Yeah, I work on cars on the side and "rust" has a negative connotation in my mind that I cannot shake, despite how in love I am with the language.
The Rust language is named after a species of fungus!
I can't imagine why a Ruby programmer would forget to mention Rust's HLL support in memory-safe tuples, vectors, and hashmaps. Other features like iterators and closures might spark some interest from the OO crowd.
This talk started out slow and awkward, but got better later on.
I've been learning Rust for the last couple of weeks. I've over 20 years of dev experience, mostly in C# and Go (lately). The compiler is absolutely awesome and a joy to work with, but the language syntax decisions boggle my mind for something designed to be modern. Also I am SO THANKFUL there is a Code of Conduct, because otherwise I wouldn't feel welcome and safe /s
Codes of conduct are part of the landscape now. It's best to just ignore them and don't get caught up in the drama. Ignoring my own advice for a minute -- funny thing is that the Rust core team had some drama where they ignored the decisions of the Rust mod team, and the mod team resigned in protest. A case of not being able to follow their own rules.
Great talk! Thanks a lot for your thorough explanation of the advantages of Rust. Keep up the great work!
E.g. what is the advantage @18:30 in that very basic example? Who thought is a good idea to make assignment operator as moving by default? The actual error is "move occurs because `x` has type `std::string::String`, which does not implement the `Copy` trait", even then the line "y = x" should be NOP and optimized away as y is not used anywhere, thus there should not be an error, but a warning about unused variable.
@@courier7049 it is optimized as if y doesn't exists. But using x after it mobed into y is a semantic error. If you don't do this restriction, you will have use after frees or double frees.
From what I know ATS is arguably the most safe programming systems language out there and without having ANY performance penalty, the problem is that only 10 people in the world use it :/.
Rust makes the trains safe by not allowing them to move.
More like by not allowing them to switch tracks
But if you ever wanted to do that you can just use the unsafe keyword
ATS is very interesting but it's also VERY verbose.. I wish there was a fix for that.
Well this reminds me HOW GLAD I should be that the programming language that I have been using in the last 2 decades+ has NO MEMORY problems whatsoever, especially on a Web Server. When I put those EXEs on a web server, they often keep running for weeks and months without any leakage or errors or restarting. It's great to be able to concentrate on BUSINESS LOGIC, web interface, data, reports, and what the businesses require rather than which memory structure will not blow up. I have never had a business asking me for memory cells and objects. They are much more interested in "where is my web screen" and "where is my report". Visual Foxpro is so reliable and problem-free that programmers who used it typically did not need anything else from Microsoft for years and years. No wonder that Microsoft tried to abandon it. As an analogy in medicine: There is much more profit in cancer treatment than in cancer free. Foxpro still works like a charm for me and my clients. Efficient coding, reliable running, happy businesses. The only bad thing about it is that I cannot write any operating systems or computer games with it. But none of my business clients ask for that. Screens, Reports, Data In, Data Out etc.
If this doesn't end with rust software stopping trains better I'm going to be disappointed.
this lady: "the software industry tends to be a bit arrogant at times"
also this lady: "people kinda should be legally required to use our language instead of c"
Yes, because writing robust software isn't just about the language you choose.
@@WySBoonami someone wasn't paying attention in the talk: she was saying that about 3/4 of security bugs in one Firefox component wouldn't have happened in a memory safe language. Therefore, should safety critical systems be written in a memory safe language to eliminate lots of bugs? Seems reasonable to me.
You can only admire the brilliance of the completely new type of tyronny ... A software development regime is born.
Boonami brb writing air traffic control in scratch
When did she say that?
At 29:20 where she talks about stability she starts talking very fast. It makes me feel as though I'm reading the fine print in an EULA.
"Rust: A Language for the Next 40 Years" but every time Carol mentions trains it gets 1% faster
I tried to learn Rust around the time this came out, but just didn't have the discipline. It seems to have come a long way since then, so I'm gonna give it another try. If successful, I have a feeling it will be the last language I need. Just hope they can improve the compile times. :D
45:13 _"Memory_ _Unsafety?_ _It's_ _a_ _series_ _of_ _tubes!_ _It's_ _not_ _a_ _big_ _truck_ _that_ _you_ _can_ _just_ _dump_ _something_ _on!_ _Tubes!_ _My_ _staff_ _sent_ _me_ _a_ _Memory_ _Unsafety_ _last_ _week_ _and_ _I_ _didn't_ _receive_ _it_ _until_ _today!"_ - Senator for the regulation of Memory Unsafety.
Oh sorry, that's the Internet!
It would have been great if Rust used the C syntax, in addition to bringing the new features which C does not have , this way the lives of programmers will be easier
Rust syntax is mostly C syntax; the main differences in syntax are based on language features Rust has but C doesn't. The only thing I can think of that's not C syntax with no feature-level justification is types, which are much easier to parse in Rust than C (so, the compiler can do less work). That and pointers, which are just a flat improvement.
it already exists and it’s called C++
OK... by the gods... I'm gonna LEARN it already :D
Beautiful! Thank you!
C/C++ programmer: Smile, you can't kill them all.
Rust programmer: Hold MY beer, that I own.
Yess! C/C++ can't own their own beer, but Rusties can!
what is rust? what is it used for? where in the stack is it used? where can it run (web, mobile, desktop, backend)?
With a few decades of "real world" C and C++ (and some others) under my belt, the slide that sent chills down my spine was the slide that showed "Everyone"...
Everyone can (usually) make toast without burning it. NOT everyone can design & prepare a 7 course meal for 12 diners. (I certainly cannot!!)
Production code written by those who cannot clearly formulate the problem at hand is ... ubiquitous.
While I commend the effort to "raise the guardrails", I fear that rust will be seen as a gateway for hobbyists to work on systems that are beyond their comprehension.
A craftsman does not blame his tools; however, amateurs do.
Eh, that slide was overly optimistic. Rust is not for the "everyone" crowd. You have to really care about systems programming without a garbage collector to invest the time to learn Rust. What you should really take away is that there is no mythical "professional" C programmer that can avoid making memory errors in C. Or if there is, there aren't enough of them, because even the most elite companies that pay big salaries still write C code with the same old problems. Rust is about giving good systems-level programmers the right tools.
Skip to ~12:00 so you don't have to restudy your
industrial revolution lectures from engineering school.
I skipped those, so this might be a good opportunity ;)
@@thecsciworker291 Well, there is that :-) It's a good treatment on railroads if you slept/skipped or whatever through. I have heard way, way worse! The brakeman data is all true--it was truly a terrifying job.
I think the first 12 are important motivation for why not to use the breakman of today (C)
@@jpratt8676 Good point.
Thank you, Good honest presentation. I am leaning RUST now. Have a great day?
I've been tinkering with Rust since 0.3 and have generally found it pretty favorable, but the segment in this video where it gets compared to C/C++ makes it seem like the social justice warrior of programming languages, at least to me.
It is. Just check out their code of conduct. Politics is all over this language.
@@yourinternetfriend6778 demanding that people do not harass is politics?
@@musicaccount3340 Try again.
@@yourinternetfriend6778 I'm curious about what in the code do you consider to be politics.
@@musicaccount3340
> I'm curious
I doubt that based on your initial comment, but I'll answer your question.
Their enumeration of immutable human characteristics is part of the typical left-wing world view in which this statement is assumed not to be true by default, similar to how BLM activist make statements that are obvious to anyone with the implication that there are those who disagree.
Additionally their mention of "safe" environments, "harassment" and feelings points towards a typically left-wing authoritarian world view that seeks to control every aspect of people's lives and at the same time infantilize them. This even explained further down where they literally tell you to never defend a point if somebody disagrees with you and to even apologize for making your point in the first place.
As a cherry on top I even found a furry among their discord moderators. ;-)
38 years remaining
I feel reasonably comfortable with using C++ and Haskell. Both have speed if you want it. C++ has syntax to prevent some common mistakes, while haskell has syntax to allow them. Plus it is much harder to write a haskell program that does something wrong - if it compiles it works.
if you want some thing that compiles and works you should check out Idris that shit will blow your mind
@@MyAce8 Never heard of it. Seems interesting, thank you!
Rust is basically in between C++ and Haskell. You should like it.
Rust is as if C++ and Haskell were to have a baby and then agree to choose the best genes from both.
Rust is far safer (stricter) than Haskell. For instance: You cannot have a non-exhausted match in Rust; and panicking in Rust is strictly programmer error, unlike runtime error in Haskell.
r/hydrohomies
IM THIRSTY
4:39 "Nice"
- Michael Rosen
I’m struggling to make a user input with parse to isize
Well, could qualify the arenas of software development where a closer-to-the metal approach that Rust facilitates is warranted. For instance, lots of cloud services and cloud infrastructure software has been written in Go, which has GC memory management. Devs tend to find Go relatively simple to learn (very concise language) and its primary concurrency model is relatively easy to learn and yet an effective concurrency model. There is arguably a lot more cloud services and cloud infrastructure software to write vs device drivers and OS kernels. Which language (Go vs Rust) is better tuned to cloud development in terms of programmer productivity, adequacy of performance and impact on resource consumption, and software defect rate per crucial matters such as security vulnerabilities?
Rule of thumb: Golang for cloud services, as you say. Rust for systems development, device drivers, OS kernels, terminal applications, etc. where low-level security matters most, as you say.
Read up on how the team behind Discord moved from Go to Rust because the garbage collector in Go was biting them in the behind. Also, Go allows data races in their concurrency model, whereas in Rust data races are ruled out by the compiler.
With that many intermediate targets, no wonder Rust compiles so slow.
Well yeah of course it is. Still can't allocate structs on the heap without creating them on the stack.
Pro tip:
When showing off your language, don't show the projects that caused so much hate (like Firefox Quantum release which signaled all the people I knew who actually still used Firefox to switch to Waterfox - including myself, though I only used Firefox for the rare compatibility reason anyways)
Why aren't there bookmarks?
The Rust syntax!!! crazy for a modern language. Swift could win the race.
Swift is not suited for systems programming. Is it a great language, though. I feel overall, corporate languages have proven to be more well designed from the get go (powershell, Swift, c#, swift, go). Anyone knows that retrofitting features while keeping back compat makes the language messy.
40 years!
I believe that any language used to build a reasonably large code base which is going to cost too much to be rewritten and too important to be decommissioned is going to last forever. I still see open job position for Cobol. So once you get into the market you are going to stay. The point is how large this niche is going to be. Rust is basically in competition with C and C++, where a compiler exist, in case you need to write a new product or fix very limited portions of your legacy code. There might to be some overlapping with Go and a curious scenario where Web ASM becomes a thing. I think this niche is crumpled.
Do you have a copy of Megadeth's RUST IN PEAVE album?
Have you seen/tried APL? (e.g. Dyalog) Something totally different.
The CCS component sped up dramatically, because of parallelism. Attributing that to Rust is quite disingenuous. Mozilla could have used C++, or C for that matter, to introduce parallelism and achieve the same increase in speed. It would benefit her more to discuss the benefits of Rust rather than demeaning C and/or C++.
Listen, we've always known that C is a raw no- seatbelt language. If you want a seatbelt, you have to build it yourself, but the language doesn't inhibit you.
However, I do see the benefits of Rust, but a big red flag is the complexity of the language. That's also the problem with C++. The main strength of C is its simple syntax.
They could have used C++ for the new CSS engine, true.
And in fact, they tried. I think even multiple times.
Yeah, found the blog entry: blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html They mention they failed with the C++ attempts. But sadly don't elaborate on why.
In some talk they explained that they tried to do that in C++ but they never managed to get it to work reliably. So, in that sense the speed improvement was made possible by Rust.
@@digitalspecter I DON'T buy it. Don't pee on my leg and tell me it's raining.
@@Asrashas: "But sadly don't elaborate on why." Or when for that matter - I believe it's called "(imp)lying by omission". That article was written in 2017 about a project that was conceived in 2012 so when they say "Mozilla made two previous attempts to parallelize its style system in C++", they mean in C++03. It's 2019 now and C++20 is about to be finalized. The safe, parallel operations you can do in literally a line or two of standard, modern C++ is incomparable to C++03 or indeed standard, modern Rust.
@@BruceBigby @Bruce Bigby ruclips.net/video/_jMSrMex6R0/видео.html 56:36 he starts talking about it.
Very nice, great effort. I have been writing software for 40 years. With the changes I have seen in everything i can guarantee you it wont be. I worked at Eastman Kodak 35 years ago. I was guaranteed PL/1 would be a language that would be around in 50 years. The last PL/1 programmer i knew of was 25 years ago. Almost 10 years ago Kodak died as well.
Well, C++ was born in 1980, and it's still around. As Nils Bohr said, "It's hard to predict, especially future"... :)
Forty years from now AI won't need humans. After the war destroys all of humanity, AI will "code" for itself.
@@Ou8y2k2 Careful, James Cameron might sue you.🙄(joke) he wrote terminator exactly 40 years ago. It Predicted the AI factories would be up and running by now at full capacity. In a mere 7 years in 2029 they would figure out time travel. Thanks to time travel the AI horrors would be retroactively fixed.
"A Language for the Next 40 Years", this title smells like multi level marketing scheme.
So does Torvalds hate Rust too?
No. I think he thinks its too young yet. But they are busy implementing Rust in the build for the kernel as people are going to write drivers in Rust. He only wants it to be done correctly so that it will not become a mess. Though i don't think he will accept Rust for core kernel code yet and for a long time to come.. he doesn't hate it nor love it.
Torvalds is approving, but skeptical about Rust in kernel. He doesn't want to integrate it into the core (which is good, it would add a bunch of headache) but is otherwise open to experimentation
Giving a thumbs up for stability when updates have broken code for 7% of your users seems like a stretch...
Can you elaborate?
@@FlaviusAspra Well, in other areas at least, reliability is usually measured with nines. 93% is one nine. That's not a lot of nines.
Linus Torvalds is well known for the motto "Never break userspace!" and has chewed people out pretty badly over even anecdotal evidence that a kernel change has broken someone's program.
Its common for libraries to maintain support for deprecated functions for decades.
I dunno, is there a context in which breaking code in the whole percents is relatively good? What are those numbers like for gcc? Is it worse for Go?
From experience I think a lot of users answer the wrong thing to this question. Generally it's updating dependencies that break your code, and since Rust has a bare-bones stdlib you need to use a lot of dependencies to get anywhere. So for a lot of people, updating the compiler probably didn't break much, but updating their dependencies with a similar command usually breaks things.
For a user of Rust I don't think it's common to really see the difference between "updating the compiler" and "update the library to generate random numbers, make http requests, or parse JSON".
between rust and cpp, which one should
I choose? I am a student and I want one best programming language help me solving problem in my life. cpp is one very efficient and very interesting. cpp sign traditional programming language, but Rust most like future programming language, even Rust is not mature than cpp now, so Rust and cpp, which one I choose? thanks...
Choose C++. Memory unsafety is not a problem in C++ if you know about RAII and ownership
What kinda student are you? Are you studying software development? What kinda projects do you intend to work with? Systems development? Then learn both, they are similar enough that most of what you learn for one will apply for the other, unless I am mistaken. Also you won't find one programming language to solve your problems. You will need different language for different problems (at least if you want to do something efficiently). Right now cpp is huge in systems development, but it will eventually (5, 10, 20 years) be replaced, either by rust or something else. Right now rust looks like the most promising from my amateur point of view. But in the end, you will have to learn more than one language (I am a biologist I am learning 4 scripting and/or programming language! Bash, R, Python and Rust) so don't worry about learning the "wrong" language.
@@CosmicSomnia
A biologist with such an asortiment of known programming languages ? Certainly, exotic species :)
C++ still reigns supreme in terms of adoption, and when using a modern version, at least C++11, and carefully following best practices, it's actually not so bad. Rust is certainly interesting though, and may gain ground in the coming years. Why not both? :-)
Learn whatever your industry of interest has adopted and uses actively.
*38 years
There are architectures in the embedded world where even even C++ can't go. So C and assembly will continue to exist. And therefore so will c++. If rust can take out C (not c++) than perhaps we can all use air breaks.
Also - you should call it 'R'. Instead of 'Rust'
@@thomasw.4298 there''s an R already though
what limits from using C++ in places where C is used?
To run c++ on a processor you need a compiler, a std library, and a runtime environment. For smaller 8/16bit processors, these don't exist. For the 32bit embedded processors, the c++ tools are pretty terrible. (So bad that your not debugging your own code, but the compiler too). Also most embedded systems you can't use any heap and there is no OS. So there is no point of a std::library on these processors anyway. With all those restrictions I think you could technically write C++ on these systems, but you would have to be a master in what the compiler is doing with your templates and classes. And that kind of master can also write good C. So they would just use C because that's all that the hardware supports. So there is no incentive to create c++ for these targets either.
@@thomasw.4298 Wasnt aware that theres no c++ compilers for platforms in which c compilers exist. I dont agree that you need a runtime environment or an std library for writing c++ or other high abstraction langs like rust, d, nim, zig, etc.
I do agree that you cant use the std libs since theres no OS but you wouldnt have to be a master in the compiler to know what templates do since theyre a compile time concept (tip: if you dont know, you can try it in godbolt to see the produced machine code).
I believe the incentive of using a language with more abstractions is that it can 1) allow better code generation with stricter rules on aliasing, alignment and inline 2) can shorten the amount of code you write using abstractions like lambdas, pattern matching on sum types, richer macros/type-system, iterators and struct method access
"I don't think Government is going to improve the safety of software" and the things said immediately after really give this whole thing a very libertarian feel
Is that bad or good ?
@@emmanuelgathara696 it's really up to you
Run Barry Run....I mean Rust Belt Rust!!!
seems obvious that it's called rust because it's close to bare metal
I recall one of Rust authors said that Rust used research that is at least 15 years old, had no fancy new ideas, and meant to be practical, hence "rust" seemed appropriate.
@@PetrGladkikh it has many meanings at the same time. But yes. The concepts Rust is build on are not new. Its just that you cannot implement them in existing languages because its so fundamental to the core.
what is the multi option name about?
cool talk... however when she says rust makes low level programming for everyone, not just superhumans, is incorrect. its for crabs. But srs tho, rust is by no means an easy language and i would argue even harder to pickup than c, at least initially, we'll see.
Talks about railroads for 15 minutes. Then doesn't get into Rust's safety features because she doesn't have the time.
The safety subject would have been interesting, comparing what Rust brings with Ada / SPARK for example. Mentioning railroads but avoiding the embedded systems topic and other tools/languages than the C-related ones is a bit strange to me.
She looked so proud of that story that served absolutely zero purpose other than showing some loose association with safety between two totally different industries? Dumb. I couldn't even watch this chick on 3x speed.
@@bryanmcconnahea9873 also the association between government regulation preventing innovation and the fact air brakes are still used today makes it seem that the railwaymen were ahead of the curve seeing the hinderance of their industry. Rust will be replaced by the motorcar.
This is how propaganda works!
Excellent talk, thanks a lot!
Keep repeating it! Someone may believe it!
Saying C is inherently unsafe is saying computers are inherently unsafe, you can do anything a computer can do, I think she underestimates the number if incompetent coders. Also with open source problems get solved before exploitation usually
Still wanna learn Rust too though.
C is inherently unsafe because it doesn’t stop you from doing unsafe things. Rust only allows you to do unsafe things when you ask it to let you do so, and it means that you have specifically audited that code to be safe so the compiler doesn’t have to. In c, the compiler doesn’t audit the safety of any of your code and you have to check all of it.