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.
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.
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!
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.
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.
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
@@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.
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.
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.
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
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.
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.
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.
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++.
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.
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.
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
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.
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.
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 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.
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.
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.
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!
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 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.
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 :/.
@@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.
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.
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.
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.
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.
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.
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 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.
I am sold on making an investment in Rust; C++ is great but just too encumbered, I really cannot be happy with Python, but love many Python principles, but I need the performance and strong typing. Rust really seems to be a winner, but I need to use it for a while to be sure.
I would love to see you guys organize a "Rus(t) Fest" as an homage to "Silicon Valley (TV-Series)". You dont need a designer for location and setting, just whatch the last Episode :-P
Haskell is beautiful and safe, but not the most practical language. Rust was designed to be low level "programming" language, close to the machine. Haskell is mathematics which gets compiled to machine code ,.
What's funny? Let me remind you that Haskell is garbage collected language, do you know that? Rust's safety is for high performance application that Haskell will never archive. Don't get me wrong, Haskell is more beautiful and elegant than Rust, I love the functional features that Rust borrowed from Haskell. I would choose Haskell over any OOPL.
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 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.
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
@@Claudible Friend of mine got banned for using Master/Slave term in relation to usb driver design, supposedly gave a PTSD to an admin... I gave Rust couple of months and I spent lot of time by reading trough their forums and shit like this seems to be quite common. I mean citing Lenin mid conversation about structs is just fucked. This cannot function for very long, so unless it gets run by sane people it will just die off. Or maybe if someone creates a parallel branch that gets maintained by a bunch of Rust purists that wont mix extreme politics into language design ...
I think Rust has a rusty syntax. Meanwhile John Blow's new language has a refreshing syntax. It looks to me that the people who started Rust had really no idea how to start afresh.
@85Damix. It's all about: responsibility. Humans are born, supposed to be Creators. Robotization's killing the creative activities, there's temptation to become "lazy" & degrading. So, if you're making robots -- you have to "offer" humans "sth. else, another creative activities. It's all affecting psychika. And programmers are not "nice people" generally.
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.
@@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".
I have been very sceptical of all the new programming languages that are popping up all the time, but I can see where Rust is trying to actually make a step forward. It's an interesting mix of programming concepts and tries to get the best from many languages like C (obviously), Fortran even Python, but adds it's own flavour to round everything off. I can see how many interesting constructions could work really well in large-scale and production code projects. Since I usually work on rather small-scale or embedded problems, I am curious to see how well Rust will be able to adapt to those problems. I guess the biggest challenge will be to get all of those highly efficient code libraries for big-data, signal-processing or control systems to adapt Rust, because what is the point of having this neat and safe language if it still has to rely on unsafe C/C++ code.
@@moha6859 I think there has to be a distinction here. Using a language just for the sake of using a newer language, because it's "cool" is pointless, I agree. However I feel that the people developing Rust are trying to make a serious effot at creating alanguage that is less prone to commong problems that occur in C. Therefore it could possibly be suitable for large projects that deal with a lot of memory operations, for example.
What I find really strange here is that safety was presented only in regards to desktop applications. You mentioned embedded systems ; Many C users work in this field because the performance aspect is critical as well as safety. Mentioning safety and railroads but avoiding solutions like Ada / SPARK in the discussion (only mentioning C++ or Go and forgetting an industry leading solution) is very strange imho.
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.
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.
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.
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!
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 :)
nobody: ...
Rust language team: hehehe we have :: thats a *TURBOFISH*
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.
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.
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
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.
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.
simplicity is what made Go successful.
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
The rust project is so ambitious, I like that a lot
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??
37 years left
35 years left
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.
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.
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++.
What programming domains is Rust best suited for?
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.
air brakes - spring applied, air pressure released
She convinced me to start using Rust after 10:51 of the start of the video. She better has gotten a raise!
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.
Fantastic presentation- thank you .
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.
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/
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
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.
I’m struggling to make a user input with parse to isize
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.
Thank you, Good honest presentation. I am leaning RUST now. Have a great day?
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
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.
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.
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?
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.
4:39 "Nice"
- Michael Rosen
With that many intermediate targets, no wonder Rust compiles so slow.
38 years remaining
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!
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 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.
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.
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 yeah of course it is. Still can't allocate structs on the heap without creating them on the stack.
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!
Why aren't there bookmarks?
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.
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.
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++
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.
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.
Won me right of the bat (mixed metaphors much?) with that jersey! 😁🐧
*38 years
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.
r/hydrohomies
IM THIRSTY
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.
This girl sure drinks a lot of water. I guess she really likes rust.
Cracked me up
how RUST is better than ZIG in language design
Excellent talk, thanks a lot!
what is the multi option name about?
No doubt that Rust code will be safe. Only if you can write it!
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.
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
guess i'll have to try Rust then ?
Have you seen/tried APL? (e.g. Dyalog) Something totally different.
I am sold on making an investment in Rust; C++ is great but just too encumbered, I really cannot be happy with Python, but love many Python principles, but I need the performance and strong typing. Rust really seems to be a winner, but I need to use it for a while to be sure.
I would love to see you guys organize a "Rus(t) Fest" as an homage to "Silicon Valley (TV-Series)". You dont need a designer for location and setting, just whatch the last Episode :-P
As Haskell programmer it's really funny listen about rust's safety
Haskell is beautiful and safe, but not the most practical language. Rust was designed to be low level "programming" language, close to the machine. Haskell is mathematics which gets compiled to machine code ,.
@@pushstack1593 really ?
What's funny? Let me remind you that Haskell is garbage collected language, do you know that? Rust's safety is for high performance application that Haskell will never archive. Don't get me wrong, Haskell is more beautiful and elegant than Rust, I love the functional features that Rust borrowed from Haskell. I would choose Haskell over any OOPL.
@@KhoaNguyen96 Learn before comment something dude ;) wiki.haskell.org/GHC/Memory_Management
push stack you are completely incorrect
Hi, 10cent means Tencent?
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.
nice presentation ..
Road to Zig 1.0 brought me here
Umm...I still choose C++
There are people that write in PHP, which is more headache inducing language than c++. Use what works for you.
If it works for you - fine. If at some point it won't - try Rust, maybe it could help.
great talk!
"A Language for the Next 40 Years", this title smells like multi level marketing scheme.
Run Barry Run....I mean Rust Belt Rust!!!
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.
I won't adopt it. I spent years, successfully dealing with memory issues in my C++ code, have many memory tools, wrote some of my own and tools.
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
Great!
Y repentinamente un comentario en español
Rust is not bad, but the community behind is just insane. Especially people behind Rust foundation are truly mental.
85Damix How so?
@@Claudible Friend of mine got banned for using Master/Slave term in relation to usb driver design, supposedly gave a PTSD to an admin...
I gave Rust couple of months and I spent lot of time by reading trough their forums and shit like this seems to be quite common.
I mean citing Lenin mid conversation about structs is just fucked.
This cannot function for very long, so unless it gets run by sane people it will just die off.
Or maybe if someone creates a parallel branch that gets maintained by a bunch of Rust purists that wont mix extreme politics into language design ...
I think Rust has a rusty syntax. Meanwhile John Blow's new language has a refreshing syntax. It looks to me that the people who started Rust had really no idea how to start afresh.
@@NeuroScientician So rust had a good start but sneaked in sjws will ruin it eventually like they ruin everything. It's sad.
@85Damix.
It's all about: responsibility.
Humans are born, supposed to be Creators.
Robotization's killing the creative activities, there's temptation to become "lazy" & degrading.
So, if you're making robots -- you have to "offer" humans "sth. else, another creative activities.
It's all affecting psychika.
And programmers are not "nice people" generally.
Explain it that memory needs condoms to the senator. That's what he/she/whatsover understands.
In 10 years AI will develop systems without the use of any human programmable languages.
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.
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".
A very comprehensive, engaging and better yet, enthusiastic presentation. Thank you so much Carol!
I have been very sceptical of all the new programming languages that are popping up all the time, but I can see where Rust is trying to actually make a step forward. It's an interesting mix of programming concepts and tries to get the best from many languages like C (obviously), Fortran even Python, but adds it's own flavour to round everything off. I can see how many interesting constructions could work really well in large-scale and production code projects. Since I usually work on rather small-scale or embedded problems, I am curious to see how well Rust will be able to adapt to those problems. I guess the biggest challenge will be to get all of those highly efficient code libraries for big-data, signal-processing or control systems to adapt Rust, because what is the point of having this neat and safe language if it still has to rely on unsafe C/C++ code.
The difference between trying to solve a problem and trying to be cool
@@moha6859 I think there has to be a distinction here. Using a language just for the sake of using a newer language, because it's "cool" is pointless, I agree. However I feel that the people developing Rust are trying to make a serious effot at creating alanguage that is less prone to commong problems that occur in C. Therefore it could possibly be suitable for large projects that deal with a lot of memory operations, for example.
What I find really strange here is that safety was presented only in regards to desktop applications. You mentioned embedded systems ; Many C users work in this field because the performance aspect is critical as well as safety. Mentioning safety and railroads but avoiding solutions like Ada / SPARK in the discussion (only mentioning C++ or Go and forgetting an industry leading solution) is very strange imho.
Rounding is for Shmucks...Thats why Cobol is still king in IBM mainframes....
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.