Logic bugs are logic bugs, they're pretty much unavoidable. I've spent a lot of years maintaining REALLY hairy projects in C++ each several million lines in scope and decades in development, and even though the legibility of the language is pretty bad, people just get used to it and find them easily enough. Buffer overflows are actually easy enough to instrument and check, it's all easily shaken out. What remains is just... tough weird shit, which can suck up an immense amount of time. Iterator invalidation, at times. Memory ownership issues. Exceptionally confused design with regard to multithreading, which took single threaded, overly object oriented code, where each object has like half a kilobyte of largely inherited fields 20 deep in hierarchy, most of which pretty much do nothing, and i mean... whenever threaded code tries to do something, even when it accidentally gets locking correct, this is still not very good, because well for one there's that overhead, and for other, there's just cache eviction, false sharing, a lot of it. And i know the issue with this code isn't bad MT, it's bad design, because there is so much remote interdependency, that you have no chance in hell of understanding what it really does. Oh you say golang's race checker will stamp it out in no time? No it won't, it's just asan. Asan is OK, with asan you can get to where your locking is again accidentally correct. What i wish instead is that over all these 15-20 years that the codebase was alive before i had to touch it, somebody or something had forced a better, saner architecture, and it vaguely looks like Rust's approach is more or less capable of shifting things in that direction. It also makes sense for the program to hard quit when there's a fundamental code problem rather than allow it to be catchable, because ultimately it will lead to a better codebase, even if a particular behaviour cannot be statically checked - as long as the type of software that you're shipping affords offensive rather than defensive approach to quality. In my opinion, offensive is usually a better choice on the desktop, in videogames, and non-critical uses, to keep the cost of development down and quality up. Which is not to say i'm sold on Rust entirely. But between C++ and that, i might pick it up for the next bigger project. If i were to at any point decide that it's untenable, bet i can just do a complete rewrite in C++ in a SHORT time. But then my computer is a literal dumpster-dive and LLVM can't target Hitachi/Renesas SuperH processor architecture, which are both serious limitations for me. Then again i don't see a solid case for Go either, for nearly throwaway things, i might as well write them in D, and i don't care whether the language is a "mess", it's fun. You can't document code... in rust??? rustdoc documentation extractor is right part of the distribution... No way to run unit tests? To your left, scroll down, chapter 21, "testing"? Oh i bet i'm getting banned from the channel. Up front, the decision to write things in Rust might not seem to make sense, and especially it makes less sense for smaller tools where you can just see the complete scope with your naked eye, or written by a single person, but i think in large teams with long-running projects, it can be absolutely invaluable, because at the end of the day, nasty shortcuts happen and then they just stay that way. In several years, there's a hairy codebase that you may wish it was written in Rust, but then it's too late. Businesses usually don't have the capability to reason in long-term goals. They must be the first to get to market, ahead of some competitor, because both are working on a really obvious idea for which the time has come. They must implement more features, survive just 2-3 more years, and these short term decisions are incentivised at every level, where aspiring managers want to rank up and so they need to overpromise AND overdeliver on buzzwords and bulletpoints, and if they leave a mess of technical debt for a newly hired low ranking manager who replaces them to sort out, then well that's just par for the course! The requirement for higher performance and getting more mileage out of hardware is probably driving the gradual shift from interpreted runtimes to statically native compiled languages probably, just as long as it can be done at little engineering cost. But ultimately it's all guesses and expectations at this point how well Rust will perform in long-living codebases. It will be interesting to see how it really turns out. Funny thing, garbage collection can be really good for performance. The fastest memory management strategy is: not to! Just leak all of it, leave the mess for the OS to clean up, because it won't have to tediously walk malloc data structures, it'll just unmap the pages in bulk and done. If you don't need to have destructors which all they do is call delete on things, returning from functions and walking up the stack is much faster. It works to a point, of course, but say if it's short lived batch tools, that can work just fine. Compilers for example often just don't free any memory. Typical conservative garbage collection can add one layer of improvement, where until you're under memory pressure, the behaviour and performance is the same as all-leak strategy, and when memory pressure occurs, before it can cause performance issues for the whole system, there will be a memory clean-up run. There are some tradeoffs. It's usually not great for interactivity, as you can have just a 10-200ms pause while the GC counts up the live pool. It's usually not great for memory fragmentation, as the best case scenario for that is that you delete things in reverse order from which you allocate them. These are both subject to tweaking though.
@@spguy7559 I'd choose go in 95% of the projects I start. When the development speed/ runtime speed ratio maters, choose Go. In the rare cases you are eager to pay the development cost to trim the last percent of performance, choose rust. I'd also add, do not choose rust if specifications are unclear and/or fluid and iterations are to be made on them, rust will slow you down. I'd say that even on projects where performance is really important, starts with Go and rewrite some parts in rust when you have proven that it's actually going to matter. I've been doing go and rust professionally for some time now, and this is my real-world experience
Not to argue, but rust has automatic browsable (HTML) documentation for all projects (`cargo doc`) derived from inline doc comments. Also, unit testing and unit performance benchmarking via `cargo test` and `cargo bench` respectively. Both are often written inline but don't have to be.
I spent 6 months in Go, I learnt it pretty quick. Being a Javascript developer for 10yrs. I even made a RPG game in GO. now switched to RUST, will not go back to GO. ;) #rustlang
I've seen what looks like better game support in Rust, so I would agree, even though that one guy who famously swayed an entire game studio to switch ultimately left and they went back to C++.
GO lacks many useful features, forcing you into writing a lot of boileplate code that can lead to a lot of bugs. Here's an example of a logic bug which like you said is the source of most of the bugs (although I disagree on that). When you execute an API request, you can model in Rust the response using enums for Success and Failed responses. This makes it super obvious for the developers that is using the client to know what is expected by executing the request and handle correctly each case. Because of the lack of enums in GO the way to handle this case is to make some manual checks which are not forced by the language and of course this is more prone to bugs than the enum solution. It's a similar scenario with the NULL values that a lot of languages have, where it's up to the developer to check for them, and you as you know they were the result of a massive amount of bugs because, well, we're humans and when the application grows up, it's much harder to track all of those things.
33:10 is interesting because while it is kinda weird to drop the return keyword in functions, the last expresssion in a block having no semicolon makes sense. It allows for blocks to be treated as expressions, you can see this well in match expressions. So you can basically write a block of statements, make it end with an expression and make the entire block evaluate to the result of that expression. I've seen this become useful in declarative macros.
I think that people want to pit languages against each other is because after investing time to learn a language, people don't want to accept the fact that they may benefit from learning another one. Go is great. I haven't used it extensively, but really sometimes when writing Go I literally start writing Python code on accident because the simplicity of the language is that similar. There definitely are some differences and Go is more complex, but not by that much. But, there still is a place for languages like Rust. In fact, I think that what Rust is trying to accomplish is great, and it can almost be compared to Go. Go brings high speed into the realm of very easy to learn and write languages, whereas Rust brings some more simplicity to the top-performance realm. Yes, Rust is much more complicated than Go, but they aren't really competing in the same space. People have to understand languages are tools. Great video.
Interesting points. I think the strongest argument is developer friction with the tooling. Debug compile time is not very slow in my experience. However I trust the correctness of something written in Rust much more highly. For example, your chars complaint. A lot of the strings you're going to be interacting with may contain unicode chars, and so you do not by default actually want to iterate over bytes, a char in the real world is not a byte! It is a good thing that rust forces you to be very explicit in what you mean in this case.
if i had to choose a program witten in rust or go i would go with rust, if i had to develop one i would choose go as my skills and time are constrained
I really _really_ hate Go's syntax. It's like they changed things just to be different and then shoehorned in some thinly veiled excuse like "readability", which is entirely subjective.
Go has the most readable and correct syntax of any language I've ever coded (and I've done more than a dozen at this point).
4 ปีที่แล้ว +30
Man, even if Go is more familiar syntax wise. If I cant find material/good docs on the language I cant learn it. So yeah, you took 30 min to read and understand string looping I never found that material for Go. Also, docs and unit test in rust are pretty obvious and addressed in the Rust Book
Absolutely, developer ergonomics are so damn important, especially for open-source projects where other people are supposed to contribute. And yeah, all the safety guarantees of rust are slowing down development of simple user-space programs like CLIs. It’s important to choose the tool best for the job at hand. Some opinions, though: Totally see your point about string handling in Rust, but I think that’s just an artifact of the language being so low-level. Strings are just super complicated when utf-8 is involved, and when programming close to hardware you have to be aware of that fact. Unit-tests don’t have to be in the same file as the actual code, but it has established itself that you put unit tests into the unit you’re testing and integration tests outside, which makes sense imo.
Hard to believe all those languages came up in convo, and no real mention of Elixir. You can use a NIF to dip down into C (or Rust) if you need to raw horsepower. Otherwise, Elixir's (Beam VM) concurrency model is a perfect fit for the modern web (multi-core machines in a cluster). Go just doesn't even compare.
@@rwxrob Do it! IMO, start with Elixir. You can pick up Erlang along the way. I have yet to find a better technology for the modern web (distributed services / containers, concurrency, fault tolerance, etc.). And when you need raw computing power, either call a dedicated container with C/Rust, or use a NIF.
One thing that you did not mention in the main part of your talk is that in Go, you can do substantial work without ever leaving the standard library. Anyone who has gone through NPM hell knows what it means to rely on third-party libraries (broken/abandoned dependencies, etc.).
some interesting points, however if you value "developer productivity" then Go doesn't provide anything over other managed languages such as Java or C# in fact if anything its actually WORSE since Go is so primitive in comparison (missing many basic language features such as Generics). I would actually contest that if you look at the "overall productivity" of a project it is simply not JUST the time it takes to develop a particular solution. You have to factor in debugging, refactoring, and maintenance over the lifetime of a running software. In the "long term" I suspect Rust actually outweighs Go's "short term" time advantages. Sure we can slap together some solution in Go, but I'd rather take a small time hit during development then have to fix problems in production at 3AM in the morning! Perhaps you don't like Rust and sure I understand that it's not your "cup of tea" and you know that's fine. There are plenty of languages for everyone's taste! but to make some very sweeping claims without solid evidence certainly hasn't convince me that "Go" is demonstrably better.
Go is an amazing language. I've started in C and Object Pascal 15 years ago, and after it, have been exclusively coding in Lua for the past eight years. Since 2018/2019 I saw myself looking for a different language due to better job positions in the market and tried both (Rust and Go) and nothing made me so excited about coding again than Go.
hi sir , i have question ... if Go is not a systemic lang ,, so why did the deno want to built in GO ,,, and why finally they decided build it on rust ?
Its an opinionated video and not a fact. But admire your passion for 'Go'...'Go' is good in some use cases but not for all.. That applies to any programming language. We must accept the fact the 'Go' is not a systems programming dialect and can't replace C, C++ or Rust when it comes to speed.. Though will also stress that 'Go' has perhaps the best network programming capabilities among any modern language.
^ unpopular opinion apparently, getting f*ing roasted for it, but people who matter understand and have made their decision, Go is king of Cloud Native. Rust has a niche following for "high performance" edge cases that overlap with C and C++.
I've edited this comment too many times...this is a rant and not a logical comparison. It's so biased it doesn't even worth listening to the points (in my biased opinion).
I never said it wasn't biased, but my bias is based on the same objective aversion the entire industry has to Rust and why Go is the industry standard for Cloud Native development. That's not an opinion. Rust isn't and never will be.
Sir, what I can think of is that most of the people who love C will write their programs in Go when they don't need that much runtime speed as C. But the people who are frustrated over C++ can not find any other language than Rust, as it meets their requirements. C++ people really don't want to go to another language which has garbage collection. So, people in position where they need to write C++ , even though they hate it, they see only Rust as the only option. I guess that's where the most loved programming language title came from. I think in future, more C++ programmer will move to Rust. But more C programmers will just write C + Go to meet their fast requirement for developer speed. Linux community will be a good example for it if they do such. But maybe Microsoft C++ developers will fully move to Rust
Actix is a Rust server and it's the fastest HTTP server. "The world want development speed mnot execution speed that's why interpreted language have been so popular." that's not at all correct, depends on what you want to do, that's why we're constantly trying to improve execution speed on interpreted language (mostly on Javascript, which is accelerated using WebAssembly which is usually written in Rust), we need these fast execution speed low level languages to these interpreted languages (and that is was Rust was made for), good luck writing AAA games in python (or any interpreted languages), some needs fast development and some prioritise execution speed. The compilation time are slower in Rust, that's true but the Rust compiler has more things to do than Go compiler because in Go a lot of things are handled at runtime (like memory management) and Go has been made but once compilation cache is created Rust compiler is very fast.
Interesting, I recently started learning Rust because I wanted to learn a more modern alternative to c++ Now I am keen to learn Go as well which is hopefully better than Java.
Tests are definitely easy to write in rust and the documentation doesn’t need to be published anywhere, cargo has a tool to build it locally. cargo doc -open and viola it is in your browser. You can’t technically even get the crates without the documentation being available as it is part of the source. Over all I like many of your points but these two are a bit misleading. I especially like your comments on keeping things simple and that is without a doubt the most undervalued part of gaining programming experience.
The problem with simplicity is simplicity itself. A transistor is simple, a GATE is still simpler, but the problem is, all these simple things, doesn't let you do anything substantial unless you build a complicated system with them , which people term it as computer. Complexity is necessary,. Talking about web servers, choosing a language that has more developer productivity is way better than one written in Go where you have to take care of memory leaks, lack of stack-trace and reduced developer speed over time. .
Agreed, I find Go source code so easy to read and understand. It's the only language that I've gotten when I looked into a git repository from scratch, and actually had an idea what the code did.
I loved C (NOT C++) programming and still have a soft-spot in my heart for it. The reason that I loved C is that I knew the whole language. I don't mean that I knew the whole standard library, but that I could look at any piece of C code and never see a construct that I did not recognize or could not understand -- there are no "magic" things in C. I love the same thing about Go. From the first time that I read "The Go Programming Language", I felt that I could grok the entire language -- there are no strange symbols or constructs that do things that I have never encountered before.
I'm surprised to see that my university is focusing on Go instead of the usual Java. I tried Rust before, but now I just fell in love with Go because of many things such as simplicity and higher productivity. It's sad to see that a big part of the Rust community (or the most vocal) is so cult-like and sometimes toxic, it doesn't deserve this. Good video!
@ 20:05, here it goes. Languages "safety paradigms" are just seat-belts. Proper security comes with thought through software architecture, clean documentation and review processes.
I tried Go about two years ago, and it was awesome. However I felt that the language was way too basic for what I wanted to do. I often ended up having to write a lot more code than in other languages. Maybe the Go generics will help. Another thing is the million dollar mistake repeated with nil. I'm also wondering how Go will be able to compete against Rust when it comes to webassembly. Rust is very small in size when compiled.
Thanks buddy. I was wondering about Go. Someone in my Discord showed me it and I shrugged it off as "This is slower than Rust? NAH" but I now see why it's better for me.
Hey, first video I've watched of yours...but I thought I had my stack all set for a project....you gave me the jitters.....and I will re-examine my decisions. :) better now than when the project starts.
Go is great up to a point, but then it gets in the way. Zig is a bit tougher to get rolling, but so much sweeter once you get into it. Zig is a good spot between go and rust. It's not 1.0.0 yet, but it's already on parity with dev productivity compared to go IMHO. Ps I've been using go professionally for around 5 years now. It's starting to peak in popularity for sur, and the community around go is noticably diluted now. I can see it heading off the rails soon though, unfortunately.
I completely disagree that speed of programming trumps speed of execution. Go is orders of magnitude slower at runtime than rust but that's expected because these two languages are like comparing apples and orange's.
Interesting opinions. And I found myself nodding quite a lot during the talk. However what prompt me to write a critical comment is a point made at around 40:00. Namely about multi cores and concurrency. Concurrency is not parallelism. I'm sure you can find one of the Rob Pikes talks in relation to Go about this particular subject. And I'm not aware of any sufficient answer Go has.. as it seems the only way to ensure safe parallel code is ownership model.
You take a slightly roundabout route to get there, but end up making a good point: Rust is not a general purpose programming language. It has a specific set of use cases and in those it will excel; in others it will flounder.
Great video! I’m currently taking a graduate level course in parallel programming and have worked on projects in both Go and Rust. I personally prefer Go without question.
System programmers just complicate things a lot, I love both languages but it's true Rust is way harder to write and read, it's getting very close to C++ level of complexity.
As stated in the video, different languages have different pros and cons, and thus tailor to different markets. Rust may have a steeper learning-curve than Go, coming from eg. javascript, which may mean it is less suitable for projects with high turnover rate/influx of new short-term developers.The longterm pros (and cons) for eg. rust may be harder to see before going past the initial learning-curve. Though I agree that Go may be faster and safer in terms of getting an API to market in a larger development team, I find some of the "critique" stated in the video towards rust to be misguided. Personally, I believe that my projects *will be* quite faster and safer - as in execution, *and* time-to-market - with rust. Though I'm still climbing the learning curve (which has more to do with getting a deeper understanding of code (that rust pushes me to) - and thus becoming a better programmer as a whole - than any potential rust-specific quirks). For those interested, a perspective from someone with years of experience with rust (more researcher than backend developer): th-cam.com/video/DnT-LUQgc7s/w-d-xo.html (titled "Considering Rust", skip to 51 for cons).
Mid way through this video I was thinking, wait so this "Go" thing has a better parallel/concurrency than async/await (which i only know from C# and JavaScript and actually can work with fine), and then I found a video of a guy explaining Go concurrency and it really looks quite interesting. And then I looked at how async/await works in rust and it looks like trash, compared to the Tasks API in C#.
Yeah, if people want async/await fine. But I absolutely loathe it and so do most of the beginners I have worked with when presented with that v.s. an imperative (thread/form/goroutine) model.
im mid 40s. I have at least 12 languages known, and 5 of them, I have very complex systems in production today. Originally I watched this video thinking rob is full of it. However I realized I am full of it. Why spend weeks figuring out how to write good rust.... WWEEKS for someone that has more crap in production... im done... back to Golang.
Came here eager to point out unfair/inappropriate arguments. Ended up agreeing with most of the reasoning. Still disliked the video solely due to the click-baitness of its title.
Compared to rust, I love C/C++ because of dangerous things like memcpy, memset and (void*) pointers. You cannot get such "bare metal" feelings from a "safe" language.
I really want to learn go but I can't find any documentation on it. And all the videos on TH-cam are like for beginners or not well covered. On top of that, gopls is terrible, completely unusable. That brings me to rust. Clear documentation, fast language but complicated in so many ways. The compilation times generally make me wanna cry.
Respectfully disagree about Rust's documentation being better than Go's. I love that Tour of Go is the first thing that they show you and once you're through that, off you go with your Go adventure. Which is exactly what most people need. I don't want to read an entire book before I can start writing something.
Hmm... sorry for commenting three times. I found myself watching the vid over again just to be sure. You are welcome to the views. I swear last time I visited none of my previous comments showed up here. Dang, now I have to apologize for posting four times....
One of the things that drives a lot of people away from Rust is the lack of community. It's big and strong, but not a community, but a cult. Making a video like that, or saying anything against Rust in general, whatever it is (cuz the video is really arbitrary, ngl) will result in your lynching, canceling and if it happens IRL maybe killing in the near future, idk. How is any language supposed to get mature and improve on itself when everyone is radically claiming it is perfect and every objection is irrelevant and the one who made that objection should be burned? Just get your shit together and work for the good of the language rather than endlessly finding subjective flaws in other languages. It puts a bad name on a good language.
![Why Bash and Not Zsh? [20210309155400]](/img/n.gif)
Logic bugs are logic bugs, they're pretty much unavoidable. I've spent a lot of years maintaining REALLY hairy projects in C++ each several million lines in scope and decades in development, and even though the legibility of the language is pretty bad, people just get used to it and find them easily enough.
Buffer overflows are actually easy enough to instrument and check, it's all easily shaken out.
What remains is just... tough weird shit, which can suck up an immense amount of time. Iterator invalidation, at times. Memory ownership issues. Exceptionally confused design with regard to multithreading, which took single threaded, overly object oriented code, where each object has like half a kilobyte of largely inherited fields 20 deep in hierarchy, most of which pretty much do nothing, and i mean... whenever threaded code tries to do something, even when it accidentally gets locking correct, this is still not very good, because well for one there's that overhead, and for other, there's just cache eviction, false sharing, a lot of it. And i know the issue with this code isn't bad MT, it's bad design, because there is so much remote interdependency, that you have no chance in hell of understanding what it really does. Oh you say golang's race checker will stamp it out in no time? No it won't, it's just asan. Asan is OK, with asan you can get to where your locking is again accidentally correct. What i wish instead is that over all these 15-20 years that the codebase was alive before i had to touch it, somebody or something had forced a better, saner architecture, and it vaguely looks like Rust's approach is more or less capable of shifting things in that direction.
It also makes sense for the program to hard quit when there's a fundamental code problem rather than allow it to be catchable, because ultimately it will lead to a better codebase, even if a particular behaviour cannot be statically checked - as long as the type of software that you're shipping affords offensive rather than defensive approach to quality. In my opinion, offensive is usually a better choice on the desktop, in videogames, and non-critical uses, to keep the cost of development down and quality up.
Which is not to say i'm sold on Rust entirely. But between C++ and that, i might pick it up for the next bigger project. If i were to at any point decide that it's untenable, bet i can just do a complete rewrite in C++ in a SHORT time. But then my computer is a literal dumpster-dive and LLVM can't target Hitachi/Renesas SuperH processor architecture, which are both serious limitations for me. Then again i don't see a solid case for Go either, for nearly throwaway things, i might as well write them in D, and i don't care whether the language is a "mess", it's fun.
You can't document code... in rust??? rustdoc documentation extractor is right part of the distribution... No way to run unit tests? To your left, scroll down, chapter 21, "testing"?
Oh i bet i'm getting banned from the channel.
Up front, the decision to write things in Rust might not seem to make sense, and especially it makes less sense for smaller tools where you can just see the complete scope with your naked eye, or written by a single person, but i think in large teams with long-running projects, it can be absolutely invaluable, because at the end of the day, nasty shortcuts happen and then they just stay that way. In several years, there's a hairy codebase that you may wish it was written in Rust, but then it's too late. Businesses usually don't have the capability to reason in long-term goals. They must be the first to get to market, ahead of some competitor, because both are working on a really obvious idea for which the time has come. They must implement more features, survive just 2-3 more years, and these short term decisions are incentivised at every level, where aspiring managers want to rank up and so they need to overpromise AND overdeliver on buzzwords and bulletpoints, and if they leave a mess of technical debt for a newly hired low ranking manager who replaces them to sort out, then well that's just par for the course! The requirement for higher performance and getting more mileage out of hardware is probably driving the gradual shift from interpreted runtimes to statically native compiled languages probably, just as long as it can be done at little engineering cost.
But ultimately it's all guesses and expectations at this point how well Rust will perform in long-living codebases. It will be interesting to see how it really turns out.
Funny thing, garbage collection can be really good for performance. The fastest memory management strategy is: not to! Just leak all of it, leave the mess for the OS to clean up, because it won't have to tediously walk malloc data structures, it'll just unmap the pages in bulk and done. If you don't need to have destructors which all they do is call delete on things, returning from functions and walking up the stack is much faster. It works to a point, of course, but say if it's short lived batch tools, that can work just fine. Compilers for example often just don't free any memory. Typical conservative garbage collection can add one layer of improvement, where until you're under memory pressure, the behaviour and performance is the same as all-leak strategy, and when memory pressure occurs, before it can cause performance issues for the whole system, there will be a memory clean-up run. There are some tradeoffs. It's usually not great for interactivity, as you can have just a 10-200ms pause while the GC counts up the live pool. It's usually not great for memory fragmentation, as the best case scenario for that is that you delete things in reverse order from which you allocate them. These are both subject to tweaking though.
finally you would choose rust or c++ in your next project ??
our ENG is not perfect but i trying understand comments of masters
@@spguy7559 I'd choose go in 95% of the projects I start. When the development speed/ runtime speed ratio maters, choose Go. In the rare cases you are eager to pay the development cost to trim the last percent of performance, choose rust. I'd also add, do not choose rust if specifications are unclear and/or fluid and iterations are to be made on them, rust will slow you down.
I'd say that even on projects where performance is really important, starts with Go and rewrite some parts in rust when you have proven that it's actually going to matter.
I've been doing go and rust professionally for some time now, and this is my real-world experience
Not to argue, but rust has automatic browsable (HTML) documentation for all projects (`cargo doc`) derived from inline doc comments. Also, unit testing and unit performance benchmarking via `cargo test` and `cargo bench` respectively. Both are often written inline but don't have to be.
I spent 6 months in Go, I learnt it pretty quick. Being a Javascript developer for 10yrs. I even made a RPG game in GO. now switched to RUST, will not go back to GO. ;) #rustlang
I've seen what looks like better game support in Rust, so I would agree, even though that one guy who famously swayed an entire game studio to switch ultimately left and they went back to C++.
GO lacks many useful features, forcing you into writing a lot of boileplate code that can lead to a lot of bugs. Here's an example of a logic bug which like you said is the source of most of the bugs (although I disagree on that). When you execute an API request, you can model in Rust the response using enums for Success and Failed responses. This makes it super obvious for the developers that is using the client to know what is expected by executing the request and handle correctly each case. Because of the lack of enums in GO the way to handle this case is to make some manual checks which are not forced by the language and of course this is more prone to bugs than the enum solution. It's a similar scenario with the NULL values that a lot of languages have, where it's up to the developer to check for them, and you as you know they were the result of a massive amount of bugs because, well, we're humans and when the application grows up, it's much harder to track all of those things.
33:10 is interesting because while it is kinda weird to drop the return keyword in functions, the last expresssion in a block having no semicolon makes sense. It allows for blocks to be treated as expressions, you can see this well in match expressions. So you can basically write a block of statements, make it end with an expression and make the entire block evaluate to the result of that expression. I've seen this become useful in declarative macros.
Yeah, I completely agree and have changed my opinion of that in particular --- especially after coding a bunch of Perl again lately.
I think that people want to pit languages against each other is because after investing time to learn a language, people don't want to accept the fact that they may benefit from learning another one. Go is great. I haven't used it extensively, but really sometimes when writing Go I literally start writing Python code on accident because the simplicity of the language is that similar. There definitely are some differences and Go is more complex, but not by that much. But, there still is a place for languages like Rust. In fact, I think that what Rust is trying to accomplish is great, and it can almost be compared to Go. Go brings high speed into the realm of very easy to learn and write languages, whereas Rust brings some more simplicity to the top-performance realm. Yes, Rust is much more complicated than Go, but they aren't really competing in the same space. People have to understand languages are tools. Great video.
I'd be interested to see a side by side comparison of unit testing showcasing the advantages go has over rust
Interesting points. I think the strongest argument is developer friction with the tooling. Debug compile time is not very slow in my experience. However I trust the correctness of something written in Rust much more highly. For example, your chars complaint. A lot of the strings you're going to be interacting with may contain unicode chars, and so you do not by default actually want to iterate over bytes, a char in the real world is not a byte! It is a good thing that rust forces you to be very explicit in what you mean in this case.
if i had to choose a program witten in rust or go i would go with rust, if i had to develop one i would choose go as my skills and time are constrained
I really _really_ hate Go's syntax. It's like they changed things just to be different and then shoehorned in some thinly veiled excuse like "readability", which is entirely subjective.
Go has the most readable and correct syntax of any language I've ever coded (and I've done more than a dozen at this point).
Man, even if Go is more familiar syntax wise. If I cant find material/good docs on the language I cant learn it.
So yeah, you took 30 min to read and understand string looping I never found that material for Go.
Also, docs and unit test in rust are pretty obvious and addressed in the Rust Book
Absolutely, developer ergonomics are so damn important, especially for open-source projects where other people are supposed to contribute. And yeah, all the safety guarantees of rust are slowing down development of simple user-space programs like CLIs. It’s important to choose the tool best for the job at hand.
Some opinions, though:
Totally see your point about string handling in Rust, but I think that’s just an artifact of the language being so low-level. Strings are just super complicated when utf-8 is involved, and when programming close to hardware you have to be aware of that fact.
Unit-tests don’t have to be in the same file as the actual code, but it has established itself that you put unit tests into the unit you’re testing and integration tests outside, which makes sense imo.
Hard to believe all those languages came up in convo, and no real mention of Elixir. You can use a NIF to dip down into C (or Rust) if you need to raw horsepower. Otherwise, Elixir's (Beam VM) concurrency model is a perfect fit for the modern web (multi-core machines in a cluster). Go just doesn't even compare.
I really, really want to learn Elixir and Erlang.
@@rwxrob Do it! IMO, start with Elixir. You can pick up Erlang along the way. I have yet to find a better technology for the modern web (distributed services / containers, concurrency, fault tolerance, etc.). And when you need raw computing power, either call a dedicated container with C/Rust, or use a NIF.
One thing that you did not mention in the main part of your talk is that in Go, you can do substantial work without ever leaving the standard library. Anyone who has gone through NPM hell knows what it means to rely on third-party libraries (broken/abandoned dependencies, etc.).
some interesting points, however if you value "developer productivity" then Go doesn't provide anything over other managed languages such as Java or C# in fact if anything its actually WORSE since Go is so primitive in comparison (missing many basic language features such as Generics). I would actually contest that if you look at the "overall productivity" of a project it is simply not JUST the time it takes to develop a particular solution. You have to factor in debugging, refactoring, and maintenance over the lifetime of a running software. In the "long term" I suspect Rust actually outweighs Go's "short term" time advantages. Sure we can slap together some solution in Go, but I'd rather take a small time hit during development then have to fix problems in production at 3AM in the morning!
Perhaps you don't like Rust and sure I understand that it's not your "cup of tea" and you know that's fine. There are plenty of languages for everyone's taste! but to make some very sweeping claims without solid evidence certainly hasn't convince me that "Go" is demonstrably better.
Go is an amazing language. I've started in C and Object Pascal 15 years ago, and after it, have been exclusively coding in Lua for the past eight years. Since 2018/2019 I saw myself looking for a different language due to better job positions in the market and tried both (Rust and Go) and nothing made me so excited about coding again than Go.
Really I love most that people are making their own conclusions for their own reasons (instead of being all cult-like about it).
hi sir , i have question ... if Go is not a systemic lang ,, so why did the deno want to built in GO ,,, and why finally they decided build it on rust ?
You look like you invented UNIX and C
he looks like he learned from the guy who invented UNIX ;)
Between Rust and Go, I choose Nim
Nim is awesome. It's sad that basically no one is using it
Julia to the rescue
Its an opinionated video and not a fact. But admire your passion for 'Go'...'Go' is good in some use cases but not for all.. That applies to any programming language. We must accept the fact the 'Go' is not a systems programming dialect and can't replace C, C++ or Rust when it comes to speed.. Though will also stress that 'Go' has perhaps the best network programming capabilities among any modern language.
"Go is faster for developers to write." This is soooo underrated.
Rust is faster for developers to write once a level of knowledge is reached especially for asynchronous design.
^ unpopular opinion apparently, getting f*ing roasted for it, but people who matter understand and have made their decision, Go is king of Cloud Native. Rust has a niche following for "high performance" edge cases that overlap with C and C++.
Deno is built with Rust, after changing from Go.
Yep, and that is a decision I whole-hearted agree with.
I've edited this comment too many times...this is a rant and not a logical comparison. It's so biased it doesn't even worth listening to the points (in my biased opinion).
I never said it wasn't biased, but my bias is based on the same objective aversion the entire industry has to Rust and why Go is the industry standard for Cloud Native development. That's not an opinion. Rust isn't and never will be.
Sir, what I can think of is that most of the people who love C will write their programs in Go when they don't need that much runtime speed as C. But the people who are frustrated over C++ can not find any other language than Rust, as it meets their requirements. C++ people really don't want to go to another language which has garbage collection. So, people in position where they need to write C++ , even though they hate it, they see only Rust as the only option. I guess that's where the most loved programming language title came from. I think in future, more C++ programmer will move to Rust. But more C programmers will just write C + Go to meet their fast requirement for developer speed. Linux community will be a good example for it if they do such. But maybe Microsoft C++ developers will fully move to Rust
Actix is a Rust server and it's the fastest HTTP server. "The world want development speed mnot execution speed that's why interpreted language have been so popular." that's not at all correct, depends on what you want to do, that's why we're constantly trying to improve execution speed on interpreted language (mostly on Javascript, which is accelerated using WebAssembly which is usually written in Rust), we need these fast execution speed low level languages to these interpreted languages (and that is was Rust was made for), good luck writing AAA games in python (or any interpreted languages), some needs fast development and some prioritise execution speed. The compilation time are slower in Rust, that's true but the Rust compiler has more things to do than Go compiler because in Go a lot of things are handled at runtime (like memory management) and Go has been made but once compilation cache is created Rust compiler is very fast.
Interesting, I recently started learning Rust because I wanted to learn a more modern alternative to c++ Now I am keen to learn Go as well which is hopefully better than Java.
It's not about the destination, it's about the friends we made along the way
U forgot to disable comments when u were hidding dislikes
Tests are definitely easy to write in rust and the documentation doesn’t need to be published anywhere, cargo has a tool to build it locally. cargo doc -open and viola it is in your browser. You can’t technically even get the crates without the documentation being available as it is part of the source. Over all I like many of your points but these two are a bit misleading. I especially like your comments on keeping things simple and that is without a doubt the most undervalued part of gaining programming experience.
The problem with simplicity is simplicity itself. A transistor is simple, a GATE is still simpler, but the problem is, all these simple things, doesn't let you do anything substantial unless you build a complicated system with them , which people term it as computer. Complexity is necessary,. Talking about web servers, choosing a language that has more developer productivity is way better than one written in Go where you have to take care of memory leaks, lack of stack-trace and reduced developer speed over time. .
Agreed, I find Go source code so easy to read and understand. It's the only language that I've gotten when I looked into a git repository from scratch, and actually had an idea what the code did.
I loved C (NOT C++) programming and still have a soft-spot in my heart for it. The reason that I loved C is that I knew the whole language. I don't mean that I knew the whole standard library, but that I could look at any piece of C code and never see a construct that I did not recognize or could not understand -- there are no "magic" things in C. I love the same thing about Go. From the first time that I read "The Go Programming Language", I felt that I could grok the entire language -- there are no strange symbols or constructs that do things that I have never encountered before.
I'm surprised to see that my university is focusing on Go instead of the usual Java. I tried Rust before, but now I just fell in love with Go because of many things such as simplicity and higher productivity. It's sad to see that a big part of the Rust community (or the most vocal) is so cult-like and sometimes toxic, it doesn't deserve this. Good video!
@ 20:05, here it goes. Languages "safety paradigms" are just seat-belts. Proper security comes with thought through software architecture, clean documentation and review processes.
go func(){ for the win}()
I tried Go about two years ago, and it was awesome. However I felt that the language was way too basic for what I wanted to do. I often ended up having to write a lot more code than in other languages. Maybe the Go generics will help. Another thing is the million dollar mistake repeated with nil.
I'm also wondering how Go will be able to compete against Rust when it comes to webassembly. Rust is very small in size when compiled.
Thanks buddy. I was wondering about Go. Someone in my Discord showed me it and I shrugged it off as "This is slower than Rust? NAH" but I now see why it's better for me.
Hey, first video I've watched of yours...but I thought I had my stack all set for a project....you gave me the jitters.....and I will re-examine my decisions. :) better now than when the project starts.
I love Rust but I don't think I will be able to implement it in a enterprise environment, guess I'll have to give Go a try.
Go is great up to a point, but then it gets in the way. Zig is a bit tougher to get rolling, but so much sweeter once you get into it.
Zig is a good spot between go and rust. It's not 1.0.0 yet, but it's already on parity with dev productivity compared to go IMHO.
Ps I've been using go professionally for around 5 years now. It's starting to peak in popularity for sur, and the community around go is noticably diluted now. I can see it heading off the rails soon though, unfortunately.
I completely disagree that speed of programming trumps speed of execution. Go is orders of magnitude slower at runtime than rust but that's expected because these two languages are like comparing apples and orange's.
Yeah, if that was true. Everything would be in Python.
Orders of magnitude, really? Stop with the hyperbolic arguments or nobody will listen to what you say, just a friendly advice.
Interesting opinions. And I found myself nodding quite a lot during the talk.
However what prompt me to write a critical comment is a point made at around 40:00.
Namely about multi cores and concurrency.
Concurrency is not parallelism. I'm sure you can find one of the Rob Pikes talks in relation to Go about this particular subject.
And I'm not aware of any sufficient answer Go has.. as it seems the only way to ensure safe parallel code is ownership model.
You take a slightly roundabout route to get there, but end up making a good point: Rust is not a general purpose programming language. It has a specific set of use cases and in those it will excel; in others it will flounder.
Great video! I’m currently taking a graduate level course in parallel programming and have worked on projects in both Go and Rust. I personally prefer Go without question.
If you ever choose to write about how you came to those conclusions, even from personal opinion, I would love to read them.
try Julia or Lisp
Thanks, Rob! You are the reason Im a gopher now
nice
Love how you redefined secure code. Thanks about it
System programmers just complicate things a lot, I love both languages but it's true Rust is way harder to write and read, it's getting very close to C++ level of complexity.
while i was able to pick up c++ pretty easily, rust was a nightmare. maybe im too stupid for it.
As stated in the video, different languages have different pros and cons, and thus tailor to different markets. Rust may have a steeper learning-curve than Go, coming from eg. javascript, which may mean it is less suitable for projects with high turnover rate/influx of new short-term developers.The longterm pros (and cons) for eg. rust may be harder to see before going past the initial learning-curve.
Though I agree that Go may be faster and safer in terms of getting an API to market in a larger development team, I find some of the "critique" stated in the video towards rust to be misguided. Personally, I believe that my projects *will be* quite faster and safer - as in execution, *and* time-to-market - with rust. Though I'm still climbing the learning curve (which has more to do with getting a deeper understanding of code (that rust pushes me to) - and thus becoming a better programmer as a whole - than any potential rust-specific quirks).
For those interested, a perspective from someone with years of experience with rust (more researcher than backend developer): th-cam.com/video/DnT-LUQgc7s/w-d-xo.html (titled "Considering Rust", skip to 51 for cons).
Language is just a tool. There's use cases for both.
thank you! very informative. I am new to programming and you really highlighted some important differences and let me see the big picture
You say you like functional languages and that Rust has been inspired by them.. How many functional languages use explicit returns?
I don't know but ocaml is a big inspiration for rust
Mid way through this video I was thinking, wait so this "Go" thing has a better parallel/concurrency than async/await (which i only know from C# and JavaScript and actually can work with fine), and then I found a video of a guy explaining Go concurrency and it really looks quite interesting. And then I looked at how async/await works in rust and it looks like trash, compared to the Tasks API in C#.
Yeah, if people want async/await fine. But I absolutely loathe it and so do most of the beginners I have worked with when presented with that v.s. an imperative (thread/form/goroutine) model.
Nice one! This video comes up as one of first when searching for "rust lang 2021"
im mid 40s. I have at least 12 languages known, and 5 of them, I have very complex systems in production today. Originally I watched this video thinking rob is full of it. However I realized I am full of it. Why spend weeks figuring out how to write good rust.... WWEEKS for someone that has more crap in production... im done... back to Golang.
Subscribed right away :)
y，i use golang😀
the moment I've heard "Go's replacing Python"...
You've got yourself a subscriber, sir!
Python most overrated crappy toy language ever
Julia is replacing Python
Thanks Rob. I was trying to decide between Rust and Go for a new project, and you made the case for Go very clear.
Interesting.
Came here eager to point out unfair/inappropriate arguments. Ended up agreeing with most of the reasoning. Still disliked the video solely due to the click-baitness of its title.
Compared to rust, I love C/C++ because of dangerous things like memcpy, memset and (void*) pointers. You cannot get such "bare metal" feelings from a "safe" language.
i feel the same way
I really want to learn go but I can't find any documentation on it. And all the videos on TH-cam are like for beginners or not well covered. On top of that, gopls is terrible, completely unusable.
That brings me to rust. Clear documentation, fast language but complicated in so many ways. The compilation times generally make me wanna cry.
The rust community and documentation far outshines that of golang without a doubt
But yeah, compiling is kinda slow
The main difference is that Rust is a system programming language, Go itsn't.
Fantastic video, love the analysis from a person who is clearly really experienced!
Respectfully disagree about Rust's documentation being better than Go's. I love that Tour of Go is the first thing that they show you and once you're through that, off you go with your Go adventure. Which is exactly what most people need. I don't want to read an entire book before I can start writing something.
Hmm... sorry for commenting three times. I found myself watching the vid over again just to be sure. You are welcome to the views. I swear last time I visited none of my previous comments showed up here.
Dang, now I have to apologize for posting four times....
One of the things that drives a lot of people away from Rust is the lack of community. It's big and strong, but not a community, but a cult. Making a video like that, or saying anything against Rust in general, whatever it is (cuz the video is really arbitrary, ngl) will result in your lynching, canceling and if it happens IRL maybe killing in the near future, idk. How is any language supposed to get mature and improve on itself when everyone is radically claiming it is perfect and every objection is irrelevant and the one who made that objection should be burned? Just get your shit together and work for the good of the language rather than endlessly finding subjective flaws in other languages. It puts a bad name on a good language.
finally, hope to see more projects in GO
I'm not disappointed. I mean, I have never expected a language called 'Rust' to be fast. :D