i fully agree with this take. i've spent 5 years writing go backends and 3 years writing rust backends. i was a huge proponent of rust for everything up til last year. even tho i am up to speed on how it works, it's so slow to write and a way heavier mental model than go. another thing you didn't mention is it takes literal seconds to "compile" and run a golang script on any target. rust projects can take multiple minutes to compile and more often than golang, cross compiling will be an issue
You convinced me to get into go and learn a compiled language with your comparison videos a year or few years back i felt like i was on the wrong boat after the hype built around rust. I decided to stick with Go anyway because there are way more jobs in my field and i just felt it fit with me more philosophically in that, it seems to be for people who want to do things the simplest way whereas rust felt like it wants to do everything the 'smartest' way. I'm glad to see you've been moving back and doing more in go as i definitely agree with your points here, I've been enjoying the go htmx videos and hope to see more.
Lol I’m in the same situation rn. I started with go then that was the gateway drug to rust. Now i am stuck between the two for building mainly web servers. Leaning towards going all into go.
You are spot on. Rust is great for one offs, something with clear requirements that do not change often, preferrably coded by 1 to 2 developers. Go is in the class of C# and Java, for business logic and rapid development.
I have a question as someone who used to do backend in C# 10 years ago: what exactly is the benefit of using Go over C# and Java? Does it really make that big a difference if you compile to native instead of using .NET's JIT? And is the backend ecosystem in Go mature enough to handle everything that you'd need for backend like HTTP, URL rewrite, load balancing, database connectivity etc. ?
@@ruanpingshanC# will be better. In most cases the performance will be same similar or even better if you are ok with Microsoft. Microsoft's first party ecosystem will always be better than stringing packages together.
Well Said. Even for those one offs, code tends to grow legs. Even if it has clear requirements that 'shouldn't change' (Yeah I've heard that before!) I've had one line bash scripts we thought would just be a one time, run and done instance turn into several thousand lines of Go code with options, subcommands. Not that I hate rust, but I tend to take the path of least resistance and right now for me it's writing it in Go.
Two days ago: "I dont have a favourite language. I am too old for that shit" Two months ago: "My favourite language is rust! Rust is the best language!"
Currently working on a framework connecting Go and Flutter. The Dart team (also Google-managed) nailed null safety by 2020. Makes me wonder why Go hasn't followed suit. It would make things even slicker.
Been working on a Flutter project this year and maybe the best thing about it coming from Native Java for Android is the null-safety. I do wish they had sum and/or union types 😢
@@landerdumoulin8725you can use options in java 9-11 I don’t remember well. So yeah now is null safety, but java developers don’t read update notes and companies are stuck in java 6-8 when currently we have java 17 maybe java 20
The Polars library for Python? It can be seriously fast. On one project I had with 44m rows of data, it got the time to analyse it down from about 6 hours to about 2 minutes.
@@katrinabryce I don't know anything about Polars (maybe I'll give it a try after reading more about it) but back in the day we used PySpark to work with geospatial data (telco business, pandemic times) and were reading/transforming/modelling/outputting dataset (about 3 billion unique rows big) a day in less than 60 minutes before any optimizations. With some clever hadoop opt it was less than 40 minutes. The resulting dataset was 5k big. Developing and testing the whole pipeline (pulling data from all other place with hadoop->logging->pyspark->numpy->some graphs and clustering->logging->back to hadoop / flat files for reporting to government via ftp->visualization & reporting to higher-ups) took me about 2 weeks, I've written it in June 2020 and it's still running in production (on a cluster, and I wish concurrency in python was as easy as it's in go) without any hiccups to this day (even though I left that company over 2 years ago, good code for tracking people and their behavioural patterns (eg which fastfood do you like) still has its business value). Even though it's mostly python and not "the safest" rust. Most of the time people assume the language is slow and therefore bad when, more often than not it's not the case - they can't write good performance code / identify bottlenecks - either because of lack of knowledge of algos, or because of lack of understanding of what's going on under the hood (eg looping over whole pandas dataframe or apply lambda instead of pure vectorization/numba jit). Expand your horizons, try as many approaches as possible for semi-serious stuff (world doesn't need another todo app), pick the tool you're the most comfortable with and learn it well. Only then you will be truly blazingly fast 😂
@LemonKush-be9sgi think he meant something along the lines of "Rust is great for building tools with which we build stuff normal people use" (People who code in any language lower than javascript aren't normal 👍)
Wow, I generally agree with most of the thing you say, but in this case I don't fully get your points. Any single time I was forced in Rust to think harder than any other language about a concept, it was almost always the compiler saving me from a runtime error. And very much explicitly so, it points you exactly at the problem and how to think about it. Immutability by default (but at the same time the possibility to explicitly opt in to mutability), Option, Result, pattern matching, iterators, error handling, are concept that once ingrained in the everyday work are deeply missed when you return to a language that doesn't support them. About the web server part, I don't get it. I would understand if you had to design it from scratch, but there are phenomenal libraries in cargo that make creating a web server a child's play. At that point is it really that much more complicated than doing so in other languages?
Couldn’t help but immediately think of the “informed captain” thing at Netflix when I read the OP and Primes response. The decider would get to decide, owning the outcome but both would be on board since there was recognition that the other person isn’t an idiot even if they disagree.
(Go vs Rust by Michael Mullin) ruclips.net/video/E-47VLwMY_U/видео.html This video might shed some light on Prime's statement "Most semi-experienced Rust devs will write less performant code than a Golang dev". Alot of your points are about Rusts safety features via the type system. But that safety, means that Rust will not make any assumptions on how certain pieces of data will be used. An example given in the video i linked was about strings. The naive way to iterate through a string in Rust is much less performant than the way golang handles strings by default. So unless you know how certain pieces of data are represented at a rlly low level, languages with a smart runtime may be faster than the Rust counterpart. Ofc if you're very into how computers work, down to details that most people don't explore, Rust will be faster
💯 Go is a big step backwards in terms of promoting good practices like immutability, writing non-defensive code with good error handling and null safety. It's indeed easy to write code in Go, but it's also easy to write BAD code in Go, because the simplicity of the language comes with a cost. I've seen code in Go that performs really well, but was buggy and unmaintainable because it had so much hidden complexity caused by data mutation and no proper error handling.
Built my first project in rust - can confirm really good string support and ability to process data. The syntax however, and the immutability by default are a bit of a pain. Just building a simple cli tool to export data from an API, transform it, and then put it into an excel spreadsheet was way more work than it should have been
I think what you’re getting at is that Rust is amazing when the problem scope is well defined and understood. An LSP is a great example as are tools and definitely some systems programming stuff. Where Go shines is where the scope is not defined. When you’re starting up a new company, requirements change substantially. Same with web servers. It’s the language that has almost all of the performance, but the guarantee that you can work out the next batch of requirements without substantially changing your code base. Both languages can do either situation but given my experience I feel the same way.
I spent eight months learning rust and trying to write my project with it. My project includes json parsing, filesystem interactions, decoding compressed binary data, and making web requests. It was a battle every step of the way. I finally gave up and tried go, and within two weeks I had the project up to feature parity with the Rust version. The difference in productivity for me is nuts. I like a lot about Rust, but Go is way easier to use. And I agree that Go desparately needs tagged unions.
This isn't quite a fair comparison because the second time you write something it will always be much faster to write Also rust probably does have more of a learning curve but the real question is what are they like after you've used each of them for quite a while
I did all of these things over like 5 months as I learned Rust and I found it to be such a relief. To be fair, I did also write a ton of parsers, encoders and decoders in other languages, so I had an idea. But I did struggle at first too, but I followed my own principles for learning a new language: - Clone if I need to. I am not learning lifetimes at this point. It is a battle of itself that I would somewhat overcome later. - Don't think about the Rustcean way to do things at first. Think about how I'd do it with current experience as well as knowledge I gathered from reading docs (e.g. examples). This is the way I learned about iterators, and made things a lot easier after learning just a tiny subset of the API. - Read the docs and learn the built-in APIs before learning libraries. I ended up writing much more code with std libraries than if I had used libraries, because those provide lower level APIs, but.I also learned their limits in respect to time spent. 4) Switch the implementation with a library. I initially went with logos before I discovered nom for text parsing, and bytes before I discovered deku for bit-level binary decoding/encoding. 5) Read some open source code of things in similar vein. Search for things that are similar to what I am trying to solve and see how others are doing it. I learned a ton of libraries and other APIs from this, too. Like for storing some static state I found lazy_static immensely useful, before moving over to once_cell. Also I recommend watching Crust of Rust by Jon Gjengset and his other videos. He's extremely knowledgable in Rust, working for AWS building the Rust infra there, and is a really good explainer of things.
@@georgehelyar That's a fair point, the lessons learned the first time around undoubtedly skewed the results. However, I would estimate that 90% of the time taken in the rust version was rust-related, as the business logic of the app is fairly straightforward.
My first Rust program was a tool that required a lot of Json parsing and file system interaction and it honestly went great. Of course I still had to refactor a lot because I didn't have a good idea on how to structure my code, but that would have been the case in any new language for me. Serializing and Deserializing using Serde was really easy, only thing I was missing is internally/adjacently tagged enums.
I enjoy writing Go, but my biggest "wish-list" item, even more than enums or ternary operators, is that they would sprinkle in some syntatic sugar for error handling. A basic "try" keyword that would executing a command, and automatically return an error if the last argument was a non-nil error type and the function returned an error as its last return value. That alone would cover a ton of scenarios.
I'd hold his opinion higher than someone who's touched rust for 5 minutes and says its the greatest. Isn't it possible that he just got to know Rust well enough to see its weaknesses?
I was looking into Go and Rust for an API overhaul we're doing at work. Go (with Fiber) seemed like a way better option than Rust (with tokio/actix etc). I've had a pleasant experience so far with Go and learning its quirks. I'm a little disappointed because i wanted to have an excuse to use Rust, but ultimately I think its the best decision... and its way better than our current PHP solution.
I'm not a professional programmer and lots of what he says goes over my head. I've never used rust. But I have dabbled with Excel VBA macros, awk etc for text file manipulation involving dictionaries / maps. When a requirement came up where executable made more sense, better logging and DB access was involved, I tried out go. With zero time spent on language basics or concepts, I could write utility programs that are in regular daily use for couple of years now with no issues. It works. They deal with loading text files dumped in a certain folder to database with some manipulation and error checking etc. Or format conversion with mapping based on maps. I wanted to install rust but realised in windows, it requires much bigger download. I still want to learn it as it seems to be replacing C in Linux. Now that's not easy so it sure has something going for it!
With Rust, ive come to the point where if i need to summon the dreaded 'a on a type, I just make it a raw pointer instead. Easy to work with, let RAII handle it. (if needed, most the time you use a pointer in place of reference you wouldnt need RAII anyway, just a light wrapper around unsafe {})
Imo GO is better than rust because if I get a new team member, I need to upskill they can figure out GO where as if its rust, it will be my responsibility forever
So your solution is to hire someone moar stupid than you so that they can't challenge your seat on a bullsh*t jerb??? Sounds about right--you've just described most techies under-performing at luke warm gigs..
I thought this video was really good. I struggle with Go vs. Rust. I like Rust very much, but I agree it's a bit intimidating. I like the simplicity of Go, but miss some of the features of Rust. So I'm torn between the two. I thought this video was a good, truthful, realistic opinion about the choice between these 2 great languages.
I know it seems like a weird reason, but I don't like Go because of its syntax. The whole lowercase vars are private, uppercase ones are public, the way the projects are structured... just feels so weird. I think Go with Rust syntax and option type and Cargo like tools would be the perfect language for me.
go effectively has cargo like tools go get ... go run .. go test .. like most of that is straight forward, but i do want option / result types super much!
I learned that I need two programming languages. One for prototyping in like 10 minutes. The other language is for converting prototypes into mature programs that can be distributed to customers, employees, and contractors. Go is easily a top 5 prototyping language. Anyway, I suggest that all career programmers keep a list of features that you need from each language. One day you'll get skilled enough, where you can make your own compiler. That "features list" will come in handy. You'll also use that list to diagnose and plan which languages to use for certain problem. Good Video. Go is easily top 5 programming compilers and languages.
"One day you will make your own compiler" is such a bs statement, like saying "One day you will build a particle accelerator" to a physicist engineer. I am pretty sure that probably that is not going to happen. At least not to the level of recommending it to everyone and keep a list of features lol. People can decide which language to use without any type of list if you didn't know, it won't really help.
@@twothreeoneoneseventwoonefour5Making your own compiler used to be a 1 semester class in Computer Science Degree. It takes about a week to create the basics for a compiler. You're really just converting one language to another language. Its easy today in modern era. You never have to write machine code. JS was made in a weekend and now every idiot on the web is trying to use it for serious stuff. Now every front-end dev thinks they are a computer programmer; its a weird time to be alive. I'm guessing the Institutions stopped forcing programmers to do the compiler class. Its not hard at all especially if you know either Regular Expressions and/or Backus Normal Formal. I hope that helps someone that never knew of this stuff. I use language compilers every day. I use LLVM to export to another language. LLVM is probably the best right now.
@@complexity5545 Nono, I am not talking about the possibility of creating it, but the practicality of it. Yeah, people can make a children-like drawing of a tree, or write a 3 page story. But that is not actual art and is not an actual novel. What purpose is there? Most people, even if they can, won't create their own compiler, because it will not be anything useful for any task. Maybe only 1 in 10k developers would go as far as to create a usable language alternative to hundreds of others. That's what I am talking about. It just isn't worth the time and most people know it. That's why people usually just stop at libraries for what they want.
@@twothreeoneoneseventwoonefour5Yeah. At least you know what bracket you fall into. I know I'm in that 7-10% of programmers that uses their own compiler, DSL, database querying language, embedded system. There are actually job titles for that type of programmers called Compiler Engineers. All big time companies look for it. Your salary usually ranges between $150_000 and $270_000. They require us to make test and DSL. Usually its for testing and debugging the kinks out of compilers and proprietary languages that are used in some app. You make your own programming languages or DSL to accomplish it. Its literally a job search category. To get to that, you have to make your own programming language. I 've written several. They're basically LLVM specific syntax to reduce writing code. Nvidia, Lucas Film, Disney, SAS, IBM, Microsoft, AMD, AdaFruit, Yamaha, Boeing, Lockheed, Oracle, game industries, and the list goes on and on. Every main principal programming engineer in corporations has done it. Even Prime. Just to let certain people know. You'll use it in most high corporate principal engineering jobs. They really love contractors that can matriculate and gain trust to work on patented and intellectual property stuff. Its a career path for somebody that has a knack for it.
There is something to be said for a language designed so well that it funnels users to making the correct decisions simply by its syntax, and not requiring them to be a guru or understand the inner complexities of the compiler in order to game the system and get the best performance. Obviously Rust has much better potential in the "raw performance" category, but it all came at the cost of a clunky syntax and some very aggravating paradigms. I have been doing some Zig lately, and while it is not without its quarks, its approach feels to have struck a better balance between safety and usability. It has the guide rails, and forces the developer to be explicit when disregarding them, but not so obsessed about it that the language on a whole begins to suffer from it.
I rarely comment on RUclips videos but this is really really pragmatic take. I mean, I'm too old for that language choice so go is too good, too minimal to avoid over engineering. Rust when inputs and outputs can be chained together. Thanks for the clarity.
As a former go, now rust dev I get the point for learning curve. My biggest complaint with go is the ecosystem, I really don't like the way go modules are handled and they were always a huge pain to debug, cargo / crates in comparison felt like magic even if compile times are bad.
You also don't break your head while writing Rust, you have the compiler as a guide to reduce your mental overhead and you don't have to care much about memory safety either, which also reduces overhead. In Go you have no protection for data races, so guess what, you need to break your head to avoid them. In C you have all of the Undefined Behaviour, so guess what, you need to break your head to avoid UB. Every language has some mental overhead and Rust is a language which reduces a lot of the overheads you would have in other languages
lmao at guy that said go syntax is bad, like what? the way i got into golang was when i saw one of my clients backend code and i fully understood what was happening. I've had never written a production backend or seen golang code before that.
Rust is currently in a weird spot. The ecosystem is and community is shaking around a lot, generating uncertainty. Rust is simultaneously missing some required features, and also introducing feature creep in other places. There's too much boilerplate you gotta write sometimes, and no good ways to avoid it. It would actually be good if a lot of unstable features get stabilised, but don't know if that will ever happen.
@@hypnoz7871 Agreed to some extent. But if we'd wanted another C++ as a replacement for C++, we'd have just stick with C++. Rust isn't trying to make feature parity with C++, it's trying to cover the same domains as C++. Seriously though, I feel like a lot of things will improve if ppl just have a change in mentality towards Rust and a change in the technical management.
Prime, please make distinction between Rust Project and Rust Foundation. They're two different organizations. All drama we saw came from Rust Project, NOT the Rust Foundation. In fact, it seems that Rust Foundation has been a positive force in all of this
5:15 - This! All day, this! That one simple change would eliminate 90% of stupid mistakes that can crash your program. Even if you’re catching it well before you ever make a commit, it’d still just be a massive win to eliminate that issue(and the needed boiler plate by extension) entirely.
Personally for my new projects I use Kotlin. Lovely syntax, Multiplatform compatibility, null safety, ... I have everything I love from my past experience
I’m actually on board with this, but the tools for Go in some cases are just better. I love Kotlin for a lot of things, but the libraries for go cli’s are unbeatable.
After listening to this talk, I began to think that Zig might eventually surpass Rust as a system-level, low-level, real-time language if Rust so complicated to get right. And yeah RF sucks 😅
Performance is mostly about knowing using the right patterns and using those at the architecture level. The impact of doing that well or poorly dwarfs language differences (within a set of not horrible languages). Using rust to implement a poorly designed architecture is basically doing micro optimizations relative to say using Go but with a good design.
@@OpletalRobin And then we end up with so much bloated software on our PCs and phones. A big part of it is just shitty garbage-collected languages that generate 100 CPU opcodes for what can be done in 1. A big part of it is indeed the language. And why even choose an inferior language when Rust is better even without considering performance? If it compiles, it probably works. What other language can claim such a thing? What is more valuable than having correct code that a team of software engineers can confidently modify without fear of breaking things? It will directly lead to faster development times as well.
Honestly been having a good time with Rust after training myself for about 6 months. That initial struggle was real, though. Whatever language you pick, I never want to use Java again. Been using it professionally for about 5 years now and I need out of this space... I have worked on sooooo many overly complicated Spring Boot projects. Every feature MUST be behind a Controller, a Service interface and implementation, a Dao interface and implementation.... The apps all took 10 seconds to start due to component scanning.... I don't have Go experience, but Rust + axum has already treated me better in every possible way. I'm skilled enough at this point that most borrow checker problems have become a non-issue. Even if the compilation is slower, the startup time is so much better that I'm still iterating faster... Good god... I'm sure I'd love Go if I gave it a shot, but I'm sure we can all agree that basically everything is nicer to use than Java at this point...
FWIW, in Rust you can pack any chonkier struct into an Rc / Arc if you're *forced* to use a lot of clones. Incrementing the reference counter and *then* moving the Rc / Arc is often faster than cloning a large struct.
@@disguysn Arc is probably one of my favourite types because of that. People always bicker about its runtime overhead but it really is absolutely miniscule. The only thing that I kind of want is be able to pre-allocate heap memory for an Arc so I don't have to do lots of smaller little allocations all the time, but I might just write that myself.
Exactly. Whenever I read or hear this "you just use a bunch of .clone()", I do feel people need to dig a bit deeper into Rust before making comparisons based on those arguments...
3:55 So effing true. Coding Rust is like enjoying the breeze and sun in the beach, until you add lifetimes and boom you have a tsunami coming at you. Your entire codebase needs to change to accommodate that one lifetime 'a that you added in some obscure function, somewhere deep in the hierarchy, to squeeze out that extra few milliseconds. At that point I get frustrated and wish there was some way to not use lifetimes.
I agree, lifetimes are cringe in rust imo. I understand how and why they exist, i just dont like them. 1 they look ugly and 2 I feel like it makes the job unnecessarily more difficult just for the sake of "performance".
@@bolt7 I do just clone and move on, but using other libs forces me to use them, not the end of the world its just a real turn off for just trying to, for example add a custom serialized type for serde.
@@scosminv Isn't lifetime management is necessary for the borrow checker to know how long references last? Or is there another way it could be implemented.
Feels like the difficulty level of being very proficient at Rust is so high I think something else like zig may overtake especially if the Rust Foundation keeps being hostile to it's own community.
@LemonKush-be9sg not sure if you’ve ever used zig but it quite a bit safer by default. Zig solves C’s conflation of arrays/pointers, nullable pointers, etc. It is pretty easy to circumvent (if you need a null-terminated string for FFI or something) but by default, removes a lot of the little unsafeties with C.
@@arcanernzwow this is the first time I see someone saying this line unironically: "just dont do anything wrong and it will be ok". like.. like thats not the problem all the languages after c has been trying to solve?
@elvor8512 c++ does that too, still being a superset of c. that does not mean its memory safe. safe rust is %100 memory safe with 0 undefined behaviour, period. and all the possible violation of the language invariants are encapsulated in unsafe blocks which can be audited. those can leak into safe code too which is a known shortcoming of rust, but at least you know where to look.. this is of course unlike zig, c or c++
I think Prime is exaggerating the point about lifetime propagation. Most of the time Rust can infer lifetimes without annotations. When you add an explicit one, there's only a specific set of cases where it's going to propagate everywhere, and that's usually avoidable if you design your APIs more carefully. Granted, it's possible that you work yourself into a corner without realizing it.
If you want to see some nasty code with boss level Rust feature combos: generics with multiple generic parameters + multiple lifetimes + smart pointers... Have a look at Nom library source code!
I kind of agree… but isn’t the issue of working yourself into a corner without realizing it exactly the issue that the rust ethos tries to solve? It fixes things like double frees and null pointers but seems like it introduces its own footguns along the way
@@elvor8512 Yea it's a valid criticism. I'm just saying that you learn to avoid these issues with experience. It's not like it's an issue that plagues everyone, just people who haven't learned how to manage it yet. My advice to new Rust programmers is to try your hardest to avoid explicit lifetime annotations on functions. There are only a very specific set of circumstances where you need to do it and there is no good alternative. You'll learn what these are with experience.
Go is also a good language to learn other parts of programming, like in those books on writing an interpreter or compiler in Go. Imagine doing the same in C++ or Rust! The language would hide the forest for the trees.
I'm going thru the 'writing an interpreter in go' book now writing the stuff in both go and rust at the same time to learn both. Seems like a really bad idea to do both at once though hahah
I can just agree with go being a great tool. I write code for a small iot platform in go right now, which i do for the first time. Never used Go before, didn't even watch or read a tutorial or syntax intro, just their docs, and it just works right away! That's go for me in a nutshell: simple and does what you intend. The only things i dont like until now are the forced if else formatting and switching up the order of name and type and return types, which feels odd.
Rust is different mental model and we should accent it more. Sad to say but many people try to bend Rust and implement old ways in new enviroment. And kind of safety it provides in underrated, i realized this watching videos about Swift and C++ safety and/or succesor languages, presenting many kind of fu..k ups witch are impossible to write or impossible to compile in Rust also explaing how rust mental model enables healthy local reasoning and compiler optimizations Some can be achived in other languages but mostly partialy or more costly.
If you have the right kind of glue code in Rust - pretty similar to Haskells monads glueing together pure functions - then you can get rid of most of the lifetimes in things that shouldn't have to know about them.
I would like to have example of lifetimes breaking your program structure. I am new to rust (although read the book) and don't see when it could cause such issues. Would be really helpful video
I would also love a video! I’ve been learning rust for a year or two (so I’m also pretty new lol) and I think he’s getting at the ‘infectiousness’ of lifetimes. Writing without lifetimes goes great for a while, but when you run into a situation where you need a manually typed lifetime, you often have to add generic lifetimes through many layers of parent structs, functions, etc. (or maybe I’m just bad at lifetimes! idk)
imho the solution to the coloring problem is not to remove all color, but to give a type system to the color, and allow the developer to mix and match colors as they see fit
In general, it doesn't really matter whether you choose C#, Go, Rust, Java, python, javascript, typescript or whatever for your startup. At that point you're basically re-arranging the deck chairs on the titanic. There are some choices where the choice is obvious. If you're building a messaging backend then why the heck aren't you using a BEAM language, it was literally built for this. If you're writing a Unity game, duh, use C#. If you're building an interactive webapp you don't want to use Java servlets to write javascript to write html. But if you avoid pathologically dumb choices like this, it practically doesn't matter and you should just choose the language you know best rather than waste time bikeshedding.
I'd love to see Go add `or_else` and `or_return` like Odin has. `or_else` is roughly equivalent (in end result) to `.unwrap_or_else` and `or_return` is basically the `?` operator in Rust.
Can we have a comparison between Dart and Go as a backend? Since i like dart the most but i dont get why nobody use it also for backend since isolate management and sound null safety are so amazing.
I am not too surprised by this take purely from the goals the language designers of these two language originally set out to do and how they evolved their languages. Go's original goal was to create a SIMPLE and SMALL language which does one thing, creating webservices, well and easy enough for even beginner programmers. This later on changed from "creating webservices" to "creating high-level programs". Rust's original goal was to create a language for browser engines which is capable of replacing C++. This later on changed from "browser engines" over "system programs" to "general purpose software". Go went from a relatively simple problem (webservices) to more complex ones (although not too drastically more complex ones). Furthermore Go tried to actively keep the language small and simple. Rust went from a complex problem (a browser engine) to an even more complex program (system programming) to probably the hardest one you can have when designing a language (general purpose). Furthermore Rust has kind of the kitchen sink approach when it comes to language design (just look at how fast the add stuff to the language). That Go is long term going to beat Rust in a lot of problem domains, is logical, at least imo. If you want to change something while not breaking backwards compatibility, you can't make something drastically less complex, because the old ways will persist and you will keep stumbling upon them, not matter what. Rust kind fell (and still falls) for the same trap C++ fell for, constantly adding a lot new stuff relatively often. Sure, after learning a language adding a few features is that big of a deal for somebody, but do that for an extended period of time regularly. Instead of just needing to learn b like the ones who are there from the beginning, a newcomer needs to learn b + x * t to become effective (After all, you did start to use the new features, didn't you? And most currently actively maintained libraries require knowledge about these things too to even use them, don't they?). Now, if b + x * t is already small, that's not really a problem. But if b already was not all too small but just manageable (like in case of Rust or C++ (if we take C++98 as b)), it depends on how big x * t is. In case of C++, x * t is at this point multiple times bigger than b, making getting into it extremely brutal. And Rust is very much trying to repeat this (at least currently).
Can Go ever achieve zero-cost abstraction and GC-free program? In any case, if I want to hire a lot of cheap developers really fast who aren't going to write code that I have to look at, I would choose Go. For the rest, I choose Rust.
I find Go very simple to get productive. The language is small and very intuitive. However, on a large scale system, there are some quirks to learn and deal with which is true for most languages. The first time I saw pooling slices, I was shocked.. haha.. but I now I understand why..
Most of the time, when hearing people complaining about languages, I keep thinking "not a problem in C#, just use C# !" :D They've done incredible work on this language.
Which would be better for creating audio processing apps? Like a DAW with multi threaded parallel support and WAV generating functions? Mobile apps and VSTs. DSPs basically. I also want it to do AD/DA conversions. Which has a better library and support for this? I'm a total noob so I'm leaning towards Go, because of the ease of entry, but Rust seems like it would have less latency with the less memory usage and safety. How does Golang compare in that regard? I need minimal audio processing latency with control over 32-bit float. Maybe even 64-bit for desktop. Tl;dr: which is better for high quality, low latency audio processing apps, and has VST3 library support?
I was waiting for the day when Rust fanboys would start to say ''hey maybe it's going to be an absolute nightmare to write everything in rust''. If your application is so littered with concurrency that you NEED the constant 'advice' from the BC, I think there's something inherently wrong with the design. If you're doing concurrency correctly, the interface between threads should be minimal to nearly-non-existent - so why build an entire language around the idea EVERYTHING is being borrowed? Building a clean concurrent system requires ACTUAL thought about the design, which would be required irregardless of how much static analysis is provided by the language of choice... Using rust feels like 2-3x the amount of work for something I could write instead in c++ and spend a little time building my own safeguards in for the areas that need it.
My biggest concern about Rust is a slow compilation time, although I am not sure if this is really an issue in practice. Anyways, for most servers I would agree to prefer Go. It just seems easier to get a working Go-server instead of having to setup things like Tokio and whatever else is needed to get a server in Rust.
I'm a Java developer with more then 20y of XP. I tried Rust for 2 week, trying create a parser for big binary files. I just can't put things to work. Than I tried with Go, in 3 days, voala, was working as expected. I really became so frustrated with rust, yes, I promised to myself never touch Rust again... but of course, I will try Rust again soon. 😅
About web performance: Since Rust can run without a runtime, you can even put it on a scratch docker container. It is a AWS Lambda winner. In fact it is almost like the de-facto language for WASM. And while a newbie can make things bad regarding performance. So what, let them learn better. Either way, a lot of times (if not most of the time), writting something in Rust can be an optimiziation by itself, even with poor developer decisions. Bottom line: You like Go/Know Go? Then Go for it. This has nothing to do with Rust. If you know Rust and how to use it then this is only an advantage P.S. I don't dy my hair.
Glad Prime is on the same page as me, I started losing faith in writing Rust as a solo dev for async/complex projects. Honestly if I need concurrency I'm gonna go with Go or Erlang/Elixir maybe even OCaml (I was learning that before Prime and I've used Jane Street's Async for half a year now). If I have a systems level project or CLI too I'll still reach for Rust since Zig is still a bit of a mess.
Pick Elixir every time, it beats absolutely everyone in terms of ecosystem, and it almost feels too easy to use once you learn it, and it is actually modern and does a lot of ground work for you, unlike Go or OCaml. By "a lot" I mean... a lot.
Maybe a bit different view from my team experience. We are longtime scala users and when there was internal poll/decision about different language to use for internal tooling or dedicated really safe and performant small services(finances) in parallel to scala backends, there was no one preferring using Go over Rust even when others (ignoring my AI ppl with their Python proposals🤣 ), originally enterprise java teams in my company like Go. Maybe it is a fact that when you come from more complex language ecosystem Rust seems mentally like acceptable effort for good results.
I ended up making my own Optional type in Go to handle optional parameters, but the function signatures got too uncontrollably large, so I then bundled parameters into structs of Optionals. It was a bit tedious and strange, but it worked first try and took just a few minutes to figure out. Go could be improved, but it is pretty damn good already.
I'm learning Go, and I feel like this is something important I need to investigate further down the line when I have better comprehension. (Total newbie besides a little mql4/mql5, minimal html/css..) someone please reply to me so I can reference this later! 🙏
I've been thinking about making a simple database for learning purposes. While I'm currently using go I thought ill try to learn Rust and why not develop the db in Rust as a learning project but after this video I guess Ill just do it with Go. Trying to learn a lot of concepts about databases plus the rust language may take me a year or so to do it.
var err error var something Something if something, err = function(); err != nil { return err } fmt.Println(something) There, that's how you do it properly in Go
I always use the most suitable tool for the problem I'm solving. Yet, I cannot think of a single problem that I may ever face that would have warranted using Go. Of course I'm very biased - I don't have many use cases for languages with a GC, as most of the things I do are real-time. I can think of a couple of cases where I'd use Rust instead of C++ though, so for me Rust beats Go. Another issue I have with Go is that it's a very low level language, much lower level than Rust and C++. Why? Because Rust have proper AST macros. C++ have Turing-complete templates. Go got nothing. Not a single tool for building higher levels of abstraction. And any meta-language (even tiniest of Forths) is infinitely more powerful than any fixed language.
I cannot believe people are fine living in a codebase without macros, the only language for which I have come to accept this is JavaScript, but if you are picking another language and you don't want meta-programming... like what? it tells me that the user is solving some rather simple problems, or they like to waste their time using Copy/Paste. ...at least JS makes it easy to write dynamic code in other ways. Can NOT say the same for Go, at ALL.
@@josevargas686 indeed, languages with built-in eval at least allow runtime metaprogramming. There are even some hygienic macro implementations for JS.
I really disagree on the lifetime point. Lifetimes are a leaky abstraction, but they are inherently necessary if you want to guarantee memory safe programs without a garbage collector. Saying you dont want lifetimes as a part of the type system is saying that you just want garbage collection. Thats fine, dont say that go is better than rust because you want gc. Its a fundamental performance tradeoff. Use the right tool for the job.
Yes, I don't think he said they weren't important, but they make Rust less sexy in the way that _everything_ needs to change if you didn't think about use-cases up front. It's one of those things where Rust expects you to do premature optimizations because you're going to get bitten. The problem is that inference wouldn't help, can likely just create another problem entirely (not knowing if something has a specific lifetime or not). Lifetime elisions helps in some cases, but rarely do I use those.
Practical? In what world is Go more practical than Rust? I am not particularly fond of either I think both are wasted opportunities but why would you think Go is more practical?
Go is like a faster python imo, its good for prototyping when youre not sure what you need. As soon as you have the basic system down though it would be a good idea to write in rust if the traffic is big enough or you can justify the rewrite. Even then though with Go you wouldnt have to. My problem is it needs the Option and Result type and I would hope instantly. Till then ill be using rust
Meet Swift: Compiled, No garbage collection, async, strict interfaces, fast, Generics, simple syntax, open source... Having built a REST api in Swift, I prefer it to Rust & Go. Hope the market wakes up to this and that Swift server thrives !
Aren't a lot of rest API's just mapping data to slightly different data? Seems like it should be a perfect fit for Rust? What are some of the things that make it hard? Are auth and contexts causing you to do a lot of annoying lifetimes and moves? I have never built something large, so I'm curious.
Yep. Elixir web frameworks treat every request as a pure function, basically. He talks a lot of talk, but doesn't show us the code. Afraid to be roasted perhaps?
@@josevargas686 I don't know perhaps he has a usecase where he needs a lot of mutable state 🤷♂ I have never had such a use case. That's the neat thing about building Rest or Graphql servers, no state, no head ache.
@7xr1e20ln8 is the dotnet CLI not enough "first class linux support" for you? My workflow for C# stays the same regardless of the platform. Not sure the last time you have used C# but .Net 6 forward feels very good cross platform-wise
He rather go to the grave than to assume C# is great. I watch his steam alot, so many different languages features that he claims makes a language good are in C# but M$ badddddddd. Like grow up 😂
Honestly, I tried writing Rust. It is no fun. With Go I feel more like C#, general purpose language, clear abstraction, I don't fight against it, I go with the flow.
I kinda want to see Rust really work its system more user friendly in terms of Rust itself handling more about the safety and not pushing it on the user, but still be the boss who breathes on your neck pointing out all the mistakes and watching you trying to figure out what the hell you're supposed to do to make the system respect its rules. At this point so many people want to write Rust and so many people like the lanfuage but everyone hates writing Rust.
i fully agree with this take. i've spent 5 years writing go backends and 3 years writing rust backends. i was a huge proponent of rust for everything up til last year. even tho i am up to speed on how it works, it's so slow to write and a way heavier mental model than go.
another thing you didn't mention is it takes literal seconds to "compile" and run a golang script on any target. rust projects can take multiple minutes to compile and more often than golang, cross compiling will be an issue
go is great for its spot and same with rust and i think you get that. its hard to get until you have done enough of each
Why did it take you at least 2 years to figure this out.
@LemonKush-be9sgHoly damn get a life lmao, all over this video butthurt about Rust dislike.
"Rust is my enTirE iDenTity!" 🤓
@@master0fnone it takes a lot of time to write features in go or rust.. /s
Write it in x86 assembly. It's going to take literal nanoseconds to "compile"
You convinced me to get into go and learn a compiled language with your comparison videos a year or few years back i felt like i was on the wrong boat after the hype built around rust.
I decided to stick with Go anyway because there are way more jobs in my field and i just felt it fit with me more philosophically in that, it seems to be for people who want to do things the simplest way whereas rust felt like it wants to do everything the 'smartest' way.
I'm glad to see you've been moving back and doing more in go as i definitely agree with your points here, I've been enjoying the go htmx videos and hope to see more.
Lol I’m in the same situation rn. I started with go then that was the gateway drug to rust. Now i am stuck between the two for building mainly web servers.
Leaning towards going all into go.
Surprisingly this was by far the best Go vs Rust video I have ever watched and this is just a clip from a steam wow.
You are spot on.
Rust is great for one offs, something with clear requirements that do not change often, preferrably coded by 1 to 2 developers.
Go is in the class of C# and Java, for business logic and rapid development.
High performance, clear requirements. The amount of engineers don't matter
I have a question as someone who used to do backend in C# 10 years ago: what exactly is the benefit of using Go over C# and Java? Does it really make that big a difference if you compile to native instead of using .NET's JIT? And is the backend ecosystem in Go mature enough to handle everything that you'd need for backend like HTTP, URL rewrite, load balancing, database connectivity etc. ?
@@ruanpingshanC# will be better. In most cases the performance will be same similar or even better if you are ok with Microsoft.
Microsoft's first party ecosystem will always be better than stringing packages together.
Well Said. Even for those one offs, code tends to grow legs. Even if it has clear requirements that 'shouldn't change' (Yeah I've heard that before!) I've had one line bash scripts we thought would just be a one time, run and done instance turn into several thousand lines of Go code with options, subcommands. Not that I hate rust, but I tend to take the path of least resistance and right now for me it's writing it in Go.
@@RichM1967 this is me right now haaha
Two days ago: "I dont have a favourite language. I am too old for that shit"
Two months ago: "My favourite language is rust! Rust is the best language!"
Hes got old since then
Currently working on a framework connecting Go and Flutter. The Dart team (also Google-managed) nailed null safety by 2020. Makes me wonder why Go hasn't followed suit. It would make things even slicker.
Been working on a Flutter project this year and maybe the best thing about it coming from Native Java for Android is the null-safety.
I do wish they had sum and/or union types 😢
I my company we are using go as backend and flutter as Frontend and it’s amazing 🎉
@@landerdumoulin8725you can use options in java 9-11 I don’t remember well.
So yeah now is null safety, but java developers don’t read update notes and companies are stuck in java 6-8 when currently we have java 17 maybe java 20
Is your framework project open source? I would love to check it out.
@@landerdumoulin8725 sum types are such an antipattern and break static type analysis
I feel like prime wants a high level language that was built in Rust.
Don't we all?
The Polars library for Python? It can be seriously fast. On one project I had with 44m rows of data, it got the time to analyse it down from about 6 hours to about 2 minutes.
Yeah, Rust is good to build more code as a product, not to build products.
@@katrinabryce I don't know anything about Polars (maybe I'll give it a try after reading more about it) but back in the day we used PySpark to work with geospatial data (telco business, pandemic times) and were reading/transforming/modelling/outputting dataset (about 3 billion unique rows big) a day in less than 60 minutes before any optimizations. With some clever hadoop opt it was less than 40 minutes. The resulting dataset was 5k big. Developing and testing the whole pipeline (pulling data from all other place with hadoop->logging->pyspark->numpy->some graphs and clustering->logging->back to hadoop / flat files for reporting to government via ftp->visualization & reporting to higher-ups) took me about 2 weeks, I've written it in June 2020 and it's still running in production (on a cluster, and I wish concurrency in python was as easy as it's in go) without any hiccups to this day (even though I left that company over 2 years ago, good code for tracking people and their behavioural patterns (eg which fastfood do you like) still has its business value). Even though it's mostly python and not "the safest" rust.
Most of the time people assume the language is slow and therefore bad when, more often than not it's not the case - they can't write good performance code / identify bottlenecks - either because of lack of knowledge of algos, or because of lack of understanding of what's going on under the hood (eg looping over whole pandas dataframe or apply lambda instead of pure vectorization/numba jit).
Expand your horizons, try as many approaches as possible for semi-serious stuff (world doesn't need another todo app), pick the tool you're the most comfortable with and learn it well. Only then you will be truly blazingly fast 😂
@LemonKush-be9sgi think he meant something along the lines of
"Rust is great for building tools with which we build stuff normal people use"
(People who code in any language lower than javascript aren't normal 👍)
Wow, I generally agree with most of the thing you say, but in this case I don't fully get your points.
Any single time I was forced in Rust to think harder than any other language about a concept, it was almost always the compiler saving me from a runtime error. And very much explicitly so, it points you exactly at the problem and how to think about it.
Immutability by default (but at the same time the possibility to explicitly opt in to mutability), Option, Result, pattern matching, iterators, error handling, are concept that once ingrained in the everyday work are deeply missed when you return to a language that doesn't support them.
About the web server part, I don't get it. I would understand if you had to design it from scratch, but there are phenomenal libraries in cargo that make creating a web server a child's play. At that point is it really that much more complicated than doing so in other languages?
ok, i can "see" your side, but at my current experience i just don't think its quite right
Couldn’t help but immediately think of the “informed captain” thing at Netflix when I read the OP and Primes response.
The decider would get to decide, owning the outcome but both would be on board since there was recognition that the other person isn’t an idiot even if they disagree.
(Go vs Rust by Michael Mullin) ruclips.net/video/E-47VLwMY_U/видео.html
This video might shed some light on Prime's statement "Most semi-experienced Rust devs will write less performant code than a Golang dev". Alot of your points are about Rusts safety features via the type system. But that safety, means that Rust will not make any assumptions on how certain pieces of data will be used. An example given in the video i linked was about strings. The naive way to iterate through a string in Rust is much less performant than the way golang handles strings by default. So unless you know how certain pieces of data are represented at a rlly low level, languages with a smart runtime may be faster than the Rust counterpart. Ofc if you're very into how computers work, down to details that most people don't explore, Rust will be faster
I had to write C++ the other day, and I just started making everything const by default. 😆
💯 Go is a big step backwards in terms of promoting good practices like immutability, writing non-defensive code with good error handling and null safety. It's indeed easy to write code in Go, but it's also easy to write BAD code in Go, because the simplicity of the language comes with a cost. I've seen code in Go that performs really well, but was buggy and unmaintainable because it had so much hidden complexity caused by data mutation and no proper error handling.
Built my first project in rust - can confirm really good string support and ability to process data.
The syntax however, and the immutability by default are a bit of a pain. Just building a simple cli tool to export data from an API, transform it, and then put it into an excel spreadsheet was way more work than it should have been
I think what you’re getting at is that Rust is amazing when the problem scope is well defined and understood. An LSP is a great example as are tools and definitely some systems programming stuff.
Where Go shines is where the scope is not defined. When you’re starting up a new company, requirements change substantially. Same with web servers. It’s the language that has almost all of the performance, but the guarantee that you can work out the next batch of requirements without substantially changing your code base.
Both languages can do either situation but given my experience I feel the same way.
I spent eight months learning rust and trying to write my project with it. My project includes json parsing, filesystem interactions, decoding compressed binary data, and making web requests. It was a battle every step of the way.
I finally gave up and tried go, and within two weeks I had the project up to feature parity with the Rust version. The difference in productivity for me is nuts.
I like a lot about Rust, but Go is way easier to use. And I agree that Go desparately needs tagged unions.
This isn't quite a fair comparison because the second time you write something it will always be much faster to write
Also rust probably does have more of a learning curve but the real question is what are they like after you've used each of them for quite a while
I did all of these things over like 5 months as I learned Rust and I found it to be such a relief. To be fair, I did also write a ton of parsers, encoders and decoders in other languages, so I had an idea. But I did struggle at first too, but I followed my own principles for learning a new language:
- Clone if I need to. I am not learning lifetimes at this point. It is a battle of itself that I would somewhat overcome later.
- Don't think about the Rustcean way to do things at first. Think about how I'd do it with current experience as well as knowledge I gathered from reading docs (e.g. examples). This is the way I learned about iterators, and made things a lot easier after learning just a tiny subset of the API.
- Read the docs and learn the built-in APIs before learning libraries. I ended up writing much more code with std libraries than if I had used libraries, because those provide lower level APIs, but.I also learned their limits in respect to time spent.
4) Switch the implementation with a library. I initially went with logos before I discovered nom for text parsing, and bytes before I discovered deku for bit-level binary decoding/encoding.
5) Read some open source code of things in similar vein. Search for things that are similar to what I am trying to solve and see how others are doing it. I learned a ton of libraries and other APIs from this, too. Like for storing some static state I found lazy_static immensely useful, before moving over to once_cell.
Also I recommend watching Crust of Rust by Jon Gjengset and his other videos. He's extremely knowledgable in Rust, working for AWS building the Rust infra there, and is a really good explainer of things.
@@georgehelyar That's a fair point, the lessons learned the first time around undoubtedly skewed the results. However, I would estimate that 90% of the time taken in the rust version was rust-related, as the business logic of the app is fairly straightforward.
And I think you didn't need any external packages on Go right?
My first Rust program was a tool that required a lot of Json parsing and file system interaction and it honestly went great. Of course I still had to refactor a lot because I didn't have a good idea on how to structure my code, but that would have been the case in any new language for me. Serializing and Deserializing using Serde was really easy, only thing I was missing is internally/adjacently tagged enums.
Tbh, there's just something about typing out "if err != nil" that makes me sip my coffee and be like "yeah. I'm a Go developer."
I enjoy writing Go, but my biggest "wish-list" item, even more than enums or ternary operators, is that they would sprinkle in some syntatic sugar for error handling. A basic "try" keyword that would executing a command, and automatically return an error if the last argument was a non-nil error type and the function returned an error as its last return value. That alone would cover a ton of scenarios.
Wow, prime threw rust under the bus. Modern times folks. Whats next neovim is worse than emacs?
I'd hold his opinion higher than someone who's touched rust for 5 minutes and says its the greatest. Isn't it possible that he just got to know Rust well enough to see its weaknesses?
@LemonKush-be9sg piss off clown, you're a junkie not a programmer.
@LemonKush-be9sgYeah but do you work at Netflix and have a mustache? No, so ill value his opinion higher than your experience
@LemonKush-be9sg Damn, boy, you really salty about this throughout all these comment threads lol.
@LemonKush-be9sgDid you just make a new account to shill for Rust?
I was looking into Go and Rust for an API overhaul we're doing at work. Go (with Fiber) seemed like a way better option than Rust (with tokio/actix etc).
I've had a pleasant experience so far with Go and learning its quirks. I'm a little disappointed because i wanted to have an excuse to use Rust, but ultimately I think its the best decision... and its way better than our current PHP solution.
If its at work, Im sure future maintainers will thank you that its written in Go.
"You need to hire that guy that slightly levitates when he walks" LMAO
I'm not a professional programmer and lots of what he says goes over my head. I've never used rust.
But I have dabbled with Excel VBA macros, awk etc for text file manipulation involving dictionaries / maps.
When a requirement came up where executable made more sense, better logging and DB access was involved, I tried out go. With zero time spent on language basics or concepts, I could write utility programs that are in regular daily use for couple of years now with no issues. It works. They deal with loading text files dumped in a certain folder to database with some manipulation and error checking etc. Or format conversion with mapping based on maps.
I wanted to install rust but realised in windows, it requires much bigger download. I still want to learn it as it seems to be replacing C in Linux. Now that's not easy so it sure has something going for it!
With Rust, ive come to the point where if i need to summon the dreaded 'a on a type, I just make it a raw pointer instead. Easy to work with, let RAII handle it. (if needed, most the time you use a pointer in place of reference you wouldnt need RAII anyway, just a light wrapper around unsafe {})
Imo GO is better than rust because if I get a new team member, I need to upskill they can figure out GO where as if its rust, it will be my responsibility forever
So your solution is to hire someone moar stupid than you so that they can't challenge your seat on a bullsh*t jerb??? Sounds about right--you've just described most techies under-performing at luke warm gigs..
I thought this video was really good. I struggle with Go vs. Rust. I like Rust very much, but I agree it's a bit intimidating. I like the simplicity of Go, but miss some of the features of Rust. So I'm torn between the two. I thought this video was a good, truthful, realistic opinion about the choice between these 2 great languages.
I know it seems like a weird reason, but I don't like Go because of its syntax. The whole lowercase vars are private, uppercase ones are public, the way the projects are structured... just feels so weird. I think Go with Rust syntax and option type and Cargo like tools would be the perfect language for me.
go effectively has cargo like tools
go get ...
go run ..
go test ..
like most of that is straight forward, but i do want option / result types super much!
@@ThePrimeTimeagen not for generating documentation at least last time i used it?
@@maniacZesci have u tried go doc and pkgsite ?
I really thought this was a high effort AI generated meme at first. Times have changed. We're gophers now boys.
I learned that I need two programming languages. One for prototyping in like 10 minutes. The other language is for converting prototypes into mature programs that can be distributed to customers, employees, and contractors. Go is easily a top 5 prototyping language.
Anyway, I suggest that all career programmers keep a list of features that you need from each language. One day you'll get skilled enough, where you can make your own compiler. That "features list" will come in handy. You'll also use that list to diagnose and plan which languages to use for certain problem.
Good Video. Go is easily top 5 programming compilers and languages.
"One day you will make your own compiler" is such a bs statement, like saying "One day you will build a particle accelerator" to a physicist engineer. I am pretty sure that probably that is not going to happen. At least not to the level of recommending it to everyone and keep a list of features lol. People can decide which language to use without any type of list if you didn't know, it won't really help.
@@twothreeoneoneseventwoonefour5Making your own compiler used to be a 1 semester class in Computer Science Degree. It takes about a week to create the basics for a compiler. You're really just converting one language to another language. Its easy today in modern era. You never have to write machine code. JS was made in a weekend and now every idiot on the web is trying to use it for serious stuff. Now every front-end dev thinks they are a computer programmer; its a weird time to be alive.
I'm guessing the Institutions stopped forcing programmers to do the compiler class. Its not hard at all especially if you know either Regular Expressions and/or Backus Normal Formal. I hope that helps someone that never knew of this stuff.
I use language compilers every day. I use LLVM to export to another language. LLVM is probably the best right now.
@@complexity5545 Nono, I am not talking about the possibility of creating it, but the practicality of it. Yeah, people can make a children-like drawing of a tree, or write a 3 page story. But that is not actual art and is not an actual novel. What purpose is there? Most people, even if they can, won't create their own compiler, because it will not be anything useful for any task. Maybe only 1 in 10k developers would go as far as to create a usable language alternative to hundreds of others. That's what I am talking about. It just isn't worth the time and most people know it. That's why people usually just stop at libraries for what they want.
@@twothreeoneoneseventwoonefour5Yeah. At least you know what bracket you fall into.
I know I'm in that 7-10% of programmers that uses their own compiler, DSL, database querying language, embedded system. There are actually job titles for that type of programmers called Compiler Engineers. All big time companies look for it. Your salary usually ranges between $150_000 and $270_000. They require us to make test and DSL. Usually its for testing and debugging the kinks out of compilers and proprietary languages that are used in some app. You make your own programming languages or DSL to accomplish it. Its literally a job search category. To get to that, you have to make your own programming language. I 've written several. They're basically LLVM specific syntax to reduce writing code. Nvidia, Lucas Film, Disney, SAS, IBM, Microsoft, AMD, AdaFruit, Yamaha, Boeing, Lockheed, Oracle, game industries, and the list goes on and on. Every main principal programming engineer in corporations has done it. Even Prime. Just to let certain people know. You'll use it in most high corporate principal engineering jobs. They really love contractors that can matriculate and gain trust to work on patented and intellectual property stuff. Its a career path for somebody that has a knack for it.
There is something to be said for a language designed so well that it funnels users to making the correct decisions simply by its syntax, and not requiring them to be a guru or understand the inner complexities of the compiler in order to game the system and get the best performance. Obviously Rust has much better potential in the "raw performance" category, but it all came at the cost of a clunky syntax and some very aggravating paradigms.
I have been doing some Zig lately, and while it is not without its quarks, its approach feels to have struck a better balance between safety and usability. It has the guide rails, and forces the developer to be explicit when disregarding them, but not so obsessed about it that the language on a whole begins to suffer from it.
I rarely comment on RUclips videos but this is really really pragmatic take. I mean, I'm too old for that language choice so go is too good, too minimal to avoid over engineering.
Rust when inputs and outputs can be chained together.
Thanks for the clarity.
As a former go, now rust dev I get the point for learning curve. My biggest complaint with go is the ecosystem, I really don't like the way go modules are handled and they were always a huge pain to debug, cargo / crates in comparison felt like magic even if compile times are bad.
I tried to "deeply" merge two structs in Go once, big PITA... I can't believe the language.
I am staying on Go's side. I enjoy writing it at work, simple and easy and has the performance. I don't break my head while writing it.
You also don't break your head while writing Rust, you have the compiler as a guide to reduce your mental overhead and you don't have to care much about memory safety either, which also reduces overhead. In Go you have no protection for data races, so guess what, you need to break your head to avoid them. In C you have all of the Undefined Behaviour, so guess what, you need to break your head to avoid UB. Every language has some mental overhead and Rust is a language which reduces a lot of the overheads you would have in other languages
lmao at guy that said go syntax is bad, like what?
the way i got into golang was when i saw one of my clients backend code and i fully understood what was happening.
I've had never written a production backend or seen golang code before that.
Go would be the goated language if it had the enum system that Rust has
Enums and error propagation via some special syntax. That would be great.
Yeah iota is pretty nasty. I love Go generally though
So True. And don't forget fixing nil maps (no one needs them)
Rust is currently in a weird spot. The ecosystem is and community is shaking around a lot, generating uncertainty. Rust is simultaneously missing some required features, and also introducing feature creep in other places. There's too much boilerplate you gotta write sometimes, and no good ways to avoid it. It would actually be good if a lot of unstable features get stabilised, but don't know if that will ever happen.
Is more a substitute of C++, is not build for building apps or servers
Rust is aiming at replacing C++, so feature creep is basically unavoidable.
Now wait for the next language implementing a mind blowing feature to replace Rust.
@@hypnoz7871 Agreed to some extent. But if we'd wanted another C++ as a replacement for C++, we'd have just stick with C++. Rust isn't trying to make feature parity with C++, it's trying to cover the same domains as C++.
Seriously though, I feel like a lot of things will improve if ppl just have a change in mentality towards Rust and a change in the technical management.
Macros solve the boilerplate plenty.
Golang also needs proper Enums.
Prime, please make distinction between Rust Project and Rust Foundation. They're two different organizations. All drama we saw came from Rust Project, NOT the Rust Foundation. In fact, it seems that Rust Foundation has been a positive force in all of this
5:15 - This! All day, this!
That one simple change would eliminate 90% of stupid mistakes that can crash your program. Even if you’re catching it well before you ever make a commit, it’d still just be a massive win to eliminate that issue(and the needed boiler plate by extension) entirely.
Go error management with errors.Is() and errors.Join() feels much better than it used to. Better than old go and Ts/Js
Thank you Dr DisRespect
Personally for my new projects I use Kotlin. Lovely syntax, Multiplatform compatibility, null safety, ... I have everything I love from my past experience
I’m actually on board with this, but the tools for Go in some cases are just better. I love Kotlin for a lot of things, but the libraries for go cli’s are unbeatable.
After listening to this talk, I began to think that Zig might eventually surpass Rust as a system-level, low-level, real-time language if Rust so complicated to get right.
And yeah RF sucks 😅
Performance is mostly about knowing using the right patterns and using those at the architecture level. The impact of doing that well or poorly dwarfs language differences (within a set of not horrible languages). Using rust to implement a poorly designed architecture is basically doing micro optimizations relative to say using Go but with a good design.
@LemonKush-be9sg not OP, but because 99.9999% of the use-cases DGAF
@@OpletalRobin And then we end up with so much bloated software on our PCs and phones. A big part of it is just shitty garbage-collected languages that generate 100 CPU opcodes for what can be done in 1.
A big part of it is indeed the language. And why even choose an inferior language when Rust is better even without considering performance? If it compiles, it probably works. What other language can claim such a thing?
What is more valuable than having correct code that a team of software engineers can confidently modify without fear of breaking things? It will directly lead to faster development times as well.
@@hagaiak what's more valuable?
I don't know, like delivering value to customers? :)
@@OpletalRobin Rust equals faster development time and less bugs, which means more value to customers.
@@hagaiak wow, so rust is fastest to develop in and never breaks? Why do companies even choose to write code in anything else?
Honestly been having a good time with Rust after training myself for about 6 months. That initial struggle was real, though.
Whatever language you pick, I never want to use Java again. Been using it professionally for about 5 years now and I need out of this space...
I have worked on sooooo many overly complicated Spring Boot projects.
Every feature MUST be behind a Controller, a Service interface and implementation, a Dao interface and implementation.... The apps all took 10 seconds to start due to component scanning....
I don't have Go experience, but Rust + axum has already treated me better in every possible way. I'm skilled enough at this point that most borrow checker problems have become a non-issue.
Even if the compilation is slower, the startup time is so much better that I'm still iterating faster... Good god...
I'm sure I'd love Go if I gave it a shot, but I'm sure we can all agree that basically everything is nicer to use than Java at this point...
you are just not skilled enough to use java bruh
@@apexashwin yeah, I should just work at Walmart...
@@NapkinKing not skilled enough
@@apexashwin5 years in Java.. Doubt somebody deserves any more torture than that
Hating Java is something that all developers can agree on.
FWIW, in Rust you can pack any chonkier struct into an Rc / Arc if you're *forced* to use a lot of clones. Incrementing the reference counter and *then* moving the Rc / Arc is often faster than cloning a large struct.
I do have to say that my time with Rust has gotten a lot easier thanks to Arc. It makes dealing with async stuff much better.
@@disguysn Arc is probably one of my favourite types because of that. People always bicker about its runtime overhead but it really is absolutely miniscule. The only thing that I kind of want is be able to pre-allocate heap memory for an Arc so I don't have to do lots of smaller little allocations all the time, but I might just write that myself.
Exactly. Whenever I read or hear this "you just use a bunch of .clone()", I do feel people need to dig a bit deeper into Rust before making comparisons based on those arguments...
Wait til you get to multithreading and async, this loses it's coolness.
@@rallokkcaz Use async almost every day at work. Still waiting.
I love how they say «prewatched» when you aren't even watching a video, - just you, explaining some thoughts.
3:55 So effing true. Coding Rust is like enjoying the breeze and sun in the beach, until you add lifetimes and boom you have a tsunami coming at you. Your entire codebase needs to change to accommodate that one lifetime 'a that you added in some obscure function, somewhere deep in the hierarchy, to squeeze out that extra few milliseconds. At that point I get frustrated and wish there was some way to not use lifetimes.
I agree, lifetimes are cringe in rust imo. I understand how and why they exist, i just dont like them. 1 they look ugly and 2 I feel like it makes the job unnecessarily more difficult just for the sake of "performance".
@@wolfeygamedev1688 If you don't care about optimizing performance why not used owned types?
@@bolt7 I do just clone and move on, but using other libs forces me to use them, not the end of the world its just a real turn off for just trying to, for example add a custom serialized type for serde.
Exactly, that's the Achile's heel of Rust: Lifetimes and exposing this complexity to the developer, not the Borrow Checker...
@@scosminv Isn't lifetime management is necessary for the borrow checker to know how long references last? Or is there another way it could be implemented.
Feels like the difficulty level of being very proficient at Rust is so high I think something else like zig may overtake especially if the Rust Foundation keeps being hostile to it's own community.
@LemonKush-be9sg C is pretty safe just as long as you don’t do anything wrong.
@LemonKush-be9sg not sure if you’ve ever used zig but it quite a bit safer by default. Zig solves C’s conflation of arrays/pointers, nullable pointers, etc. It is pretty easy to circumvent (if you need a null-terminated string for FFI or something) but by default, removes a lot of the little unsafeties with C.
@@arcanernzwow this is the first time I see someone saying this line unironically:
"just dont do anything wrong and it will be ok". like.. like thats not the problem all the languages after c has been trying to solve?
@elvor8512 c++ does that too, still being a superset of c. that does not mean its memory safe.
safe rust is %100 memory safe with 0 undefined behaviour, period. and all the possible violation of the language invariants are encapsulated in unsafe blocks which can be audited. those can leak into safe code too which is a known shortcoming of rust, but at least you know where to look.. this is of course unlike zig, c or c++
@@----__--- it’s a joke man I know C/C++ got some foot bazookas
I think Prime is exaggerating the point about lifetime propagation. Most of the time Rust can infer lifetimes without annotations. When you add an explicit one, there's only a specific set of cases where it's going to propagate everywhere, and that's usually avoidable if you design your APIs more carefully. Granted, it's possible that you work yourself into a corner without realizing it.
If you want to see some nasty code with boss level Rust feature combos: generics with multiple generic parameters + multiple lifetimes + smart pointers...
Have a look at Nom library source code!
I kind of agree… but isn’t the issue of working yourself into a corner without realizing it exactly the issue that the rust ethos tries to solve? It fixes things like double frees and null pointers but seems like it introduces its own footguns along the way
@@elvor8512 Yea it's a valid criticism. I'm just saying that you learn to avoid these issues with experience. It's not like it's an issue that plagues everyone, just people who haven't learned how to manage it yet. My advice to new Rust programmers is to try your hardest to avoid explicit lifetime annotations on functions. There are only a very specific set of circumstances where you need to do it and there is no good alternative. You'll learn what these are with experience.
Time to rewrite Go in Rust
Go is also a good language to learn other parts of programming, like in those books on writing an interpreter or compiler in Go. Imagine doing the same in C++ or Rust! The language would hide the forest for the trees.
I'm going thru the 'writing an interpreter in go' book now writing the stuff in both go and rust at the same time to learn both. Seems like a really bad idea to do both at once though hahah
It's surprising how quickly that book |Go|es haha. Im 2 evenings in and halfway through the book
There's an article on css-tricks "in defense of the ternary statement" that as much as I like ternary expressions I find clinically insane
Just when I was thinking of quietly switching to Go, such videos come out and add thousands of competitors to me🍵🗿
I can just agree with go being a great tool.
I write code for a small iot platform in go right now, which i do for the first time.
Never used Go before, didn't even watch or read a tutorial or syntax intro, just their docs, and it just works right away!
That's go for me in a nutshell: simple and does what you intend.
The only things i dont like until now are the forced if else formatting and switching up the order of name and type and return types, which feels odd.
Rust is different mental model and we should accent it more.
Sad to say but many people try to bend Rust and implement old ways in new enviroment.
And kind of safety it provides in underrated, i realized this watching videos about Swift and C++ safety and/or succesor languages, presenting many kind of fu..k ups witch are impossible to write or impossible to compile in Rust also explaing how rust mental model enables healthy local reasoning and compiler optimizations
Some can be achived in other languages but mostly partialy or more costly.
Absurd take, Rust gang for life 🦀🦀🦀
Go all the way
He said ‘Rust us okay’ wow
That is some great open nature there
If you have the right kind of glue code in Rust - pretty similar to Haskells monads glueing together pure functions - then you can get rid of most of the lifetimes in things that shouldn't have to know about them.
Monads are always the answer.
Unless the answer is Applicatives.
Unless the answer is Monoids.
Unless the answer is Semigroups.
Trivial example of this to help us dummies understand it?
I would like to have example of lifetimes breaking your program structure. I am new to rust (although read the book) and don't see when it could cause such issues. Would be really helpful video
I would also love a video! I’ve been learning rust for a year or two (so I’m also pretty new lol) and I think he’s getting at the ‘infectiousness’ of lifetimes. Writing without lifetimes goes great for a while, but when you run into a situation where you need a manually typed lifetime, you often have to add generic lifetimes through many layers of parent structs, functions, etc.
(or maybe I’m just bad at lifetimes! idk)
Bro i just wanted say you are my hero
imho the solution to the coloring problem is not to remove all color, but to give a type system to the color, and allow the developer to mix and match colors as they see fit
The colour is typed already, it is still an issue
10:15 my hair has started getting gray since I started writing rust... I guess I could dye it blue too.
I think you've just summarized my view of both languages. Great video!
Let's Go!!!
In general, it doesn't really matter whether you choose C#, Go, Rust, Java, python, javascript, typescript or whatever for your startup. At that point you're basically re-arranging the deck chairs on the titanic.
There are some choices where the choice is obvious. If you're building a messaging backend then why the heck aren't you using a BEAM language, it was literally built for this. If you're writing a Unity game, duh, use C#. If you're building an interactive webapp you don't want to use Java servlets to write javascript to write html.
But if you avoid pathologically dumb choices like this, it practically doesn't matter and you should just choose the language you know best rather than waste time bikeshedding.
@ThePrimeTime I would be super curious what you think about Swift.
I'd love to see Go add `or_else` and `or_return` like Odin has. `or_else` is roughly equivalent (in end result) to `.unwrap_or_else` and `or_return` is basically the `?` operator in Rust.
I love Rust... but they really dropped the ball on learnability/usability.
Can we have a comparison between Dart and Go as a backend? Since i like dart the most but i dont get why nobody use it also for backend since isolate management and sound null safety are so amazing.
I am not too surprised by this take purely from the goals the language designers of these two language originally set out to do and how they evolved their languages.
Go's original goal was to create a SIMPLE and SMALL language which does one thing, creating webservices, well and easy enough for even beginner programmers. This later on changed from "creating webservices" to "creating high-level programs".
Rust's original goal was to create a language for browser engines which is capable of replacing C++. This later on changed from "browser engines" over "system programs" to "general purpose software".
Go went from a relatively simple problem (webservices) to more complex ones (although not too drastically more complex ones). Furthermore Go tried to actively keep the language small and simple.
Rust went from a complex problem (a browser engine) to an even more complex program (system programming) to probably the hardest one you can have when designing a language (general purpose). Furthermore Rust has kind of the kitchen sink approach when it comes to language design (just look at how fast the add stuff to the language).
That Go is long term going to beat Rust in a lot of problem domains, is logical, at least imo.
If you want to change something while not breaking backwards compatibility, you can't make something drastically less complex, because the old ways will persist and you will keep stumbling upon them, not matter what.
Rust kind fell (and still falls) for the same trap C++ fell for, constantly adding a lot new stuff relatively often. Sure, after learning a language adding a few features is that big of a deal for somebody, but do that for an extended period of time regularly. Instead of just needing to learn b like the ones who are there from the beginning, a newcomer needs to learn b + x * t to become effective (After all, you did start to use the new features, didn't you? And most currently actively maintained libraries require knowledge about these things too to even use them, don't they?). Now, if b + x * t is already small, that's not really a problem. But if b already was not all too small but just manageable (like in case of Rust or C++ (if we take C++98 as b)), it depends on how big x * t is. In case of C++, x * t is at this point multiple times bigger than b, making getting into it extremely brutal. And Rust is very much trying to repeat this (at least currently).
Can Go ever achieve zero-cost abstraction and GC-free program?
In any case, if I want to hire a lot of cheap developers really fast who aren't going to write code that I have to look at, I would choose Go.
For the rest, I choose Rust.
@kuhlukOG Go was not created for the sake of web services. Go was created to replace C/C++ for big projects.
@@Ascentyon no it was created for webservices, otherwise if wouldnt have a GC lol.
@@actualwafflesenjoyer Cant replace c/++ and have a GC... I agree it isnt meaningful. But it will never replace c/c++ with one.
I find Go very simple to get productive. The language is small and very intuitive. However, on a large scale system, there are some quirks to learn and deal with which is true for most languages. The first time I saw pooling slices, I was shocked.. haha.. but I now I understand why..
C# adding nullable reference type checking was a big win.
Most of the time, when hearing people complaining about languages, I keep thinking "not a problem in C#, just use C# !" :D They've done incredible work on this language.
Agree completely. I am also a huge fan of Go but I love how you really get into the pros and cons.
Which would be better for creating audio processing apps? Like a DAW with multi threaded parallel support and WAV generating functions? Mobile apps and VSTs. DSPs basically. I also want it to do AD/DA conversions. Which has a better library and support for this? I'm a total noob so I'm leaning towards Go, because of the ease of entry, but Rust seems like it would have less latency with the less memory usage and safety. How does Golang compare in that regard? I need minimal audio processing latency with control over 32-bit float. Maybe even 64-bit for desktop.
Tl;dr: which is better for high quality, low latency audio processing apps, and has VST3 library support?
I was waiting for the day when Rust fanboys would start to say ''hey maybe it's going to be an absolute nightmare to write everything in rust''. If your application is so littered with concurrency that you NEED the constant 'advice' from the BC, I think there's something inherently wrong with the design. If you're doing concurrency correctly, the interface between threads should be minimal to nearly-non-existent - so why build an entire language around the idea EVERYTHING is being borrowed?
Building a clean concurrent system requires ACTUAL thought about the design, which would be required irregardless of how much static analysis is provided by the language of choice... Using rust feels like 2-3x the amount of work for something I could write instead in c++ and spend a little time building my own safeguards in for the areas that need it.
My biggest concern about Rust is a slow compilation time, although I am not sure if this is really an issue in practice. Anyways, for most servers I would agree to prefer Go. It just seems easier to get a working Go-server instead of having to setup things like Tokio and whatever else is needed to get a server in Rust.
I'm a Java developer with more then 20y of XP. I tried Rust for 2 week, trying create a parser for big binary files. I just can't put things to work. Than I tried with Go, in 3 days, voala, was working as expected. I really became so frustrated with rust, yes, I promised to myself never touch Rust again... but of course, I will try Rust again soon. 😅
Have you tried Kotlin?
Elixir Phoenix live Is pure gold
About web performance: Since Rust can run without a runtime, you can even put it on a scratch docker container. It is a AWS Lambda winner. In fact it is almost like the de-facto language for WASM. And while a newbie can make things bad regarding performance. So what, let them learn better. Either way, a lot of times (if not most of the time), writting something in Rust can be an optimiziation by itself, even with poor developer decisions.
Bottom line: You like Go/Know Go? Then Go for it. This has nothing to do with Rust. If you know Rust and how to use it then this is only an advantage
P.S. I don't dy my hair.
Let’s Gooooooooo!
Glad Prime is on the same page as me, I started losing faith in writing Rust as a solo dev for async/complex projects. Honestly if I need concurrency I'm gonna go with Go or Erlang/Elixir maybe even OCaml (I was learning that before Prime and I've used Jane Street's Async for half a year now). If I have a systems level project or CLI too I'll still reach for Rust since Zig is still a bit of a mess.
Pick Elixir every time, it beats absolutely everyone in terms of ecosystem, and it almost feels too easy to use once you learn it, and it is actually modern and does a lot of ground work for you, unlike Go or OCaml. By "a lot" I mean... a lot.
Maybe a bit different view from my team experience. We are longtime scala users and when there was internal poll/decision about different language to use for internal tooling or dedicated really safe and performant small services(finances) in parallel to scala backends, there was no one preferring using Go over Rust even when others (ignoring my AI ppl with their Python proposals🤣 ), originally enterprise java teams in my company like Go. Maybe it is a fact that when you come from more complex language ecosystem Rust seems mentally like acceptable effort for good results.
Why is c# not in the conversation? In Australia from my experience most of the jobs are with c#
If you know c#, I'd not even look at Go. You're doing fine.
I ended up making my own Optional type in Go to handle optional parameters, but the function signatures got too uncontrollably large, so I then bundled parameters into structs of Optionals. It was a bit tedious and strange, but it worked first try and took just a few minutes to figure out. Go could be improved, but it is pretty damn good already.
I'm learning Go, and I feel like this is something important I need to investigate further down the line when I have better comprehension. (Total newbie besides a little mql4/mql5, minimal html/css..) someone please reply to me so I can reference this later! 🙏
@@c0zn1cok
I've been thinking about making a simple database for learning purposes. While I'm currently using go I thought ill try to learn Rust and why not develop the db in Rust as a learning project but after this video I guess Ill just do it with Go. Trying to learn a lot of concepts about databases plus the rust language may take me a year or so to do it.
I would imagine a db is a place where rusts memory management would be very favorable over Gos
you missed embedded baremetal, rust is becoming exquisite there
Modern C# has excellent compiler level type collection. It can be done.
var err error
var something Something
if something, err = function(); err != nil {
return err
}
fmt.Println(something)
There, that's how you do it properly in Go
just toss on a little 'a .. what happens... ooohhh boy. I feel this in my bones, in my soul.
I always use the most suitable tool for the problem I'm solving. Yet, I cannot think of a single problem that I may ever face that would have warranted using Go. Of course I'm very biased - I don't have many use cases for languages with a GC, as most of the things I do are real-time. I can think of a couple of cases where I'd use Rust instead of C++ though, so for me Rust beats Go. Another issue I have with Go is that it's a very low level language, much lower level than Rust and C++. Why? Because Rust have proper AST macros. C++ have Turing-complete templates. Go got nothing. Not a single tool for building higher levels of abstraction. And any meta-language (even tiniest of Forths) is infinitely more powerful than any fixed language.
I cannot believe people are fine living in a codebase without macros, the only language for which I have come to accept this is JavaScript, but if you are picking another language and you don't want meta-programming... like what? it tells me that the user is solving some rather simple problems, or they like to waste their time using Copy/Paste.
...at least JS makes it easy to write dynamic code in other ways. Can NOT say the same for Go, at ALL.
@@josevargas686 indeed, languages with built-in eval at least allow runtime metaprogramming. There are even some hygienic macro implementations for JS.
I really disagree on the lifetime point. Lifetimes are a leaky abstraction, but they are inherently necessary if you want to guarantee memory safe programs without a garbage collector. Saying you dont want lifetimes as a part of the type system is saying that you just want garbage collection. Thats fine, dont say that go is better than rust because you want gc. Its a fundamental performance tradeoff. Use the right tool for the job.
Yes, I don't think he said they weren't important, but they make Rust less sexy in the way that _everything_ needs to change if you didn't think about use-cases up front. It's one of those things where Rust expects you to do premature optimizations because you're going to get bitten.
The problem is that inference wouldn't help, can likely just create another problem entirely (not knowing if something has a specific lifetime or not). Lifetime elisions helps in some cases, but rarely do I use those.
There is one language that has best parts of both Go and OCaml. That is F#.
I'm using typescript in the backend and I find sharing code between the client and server valuable. I wish I can do the same in Go.
Go can save you so much money on deployment
Both are interesting, but Go seems to be more practical.
Practical? In what world is Go more practical than Rust? I am not particularly fond of either I think both are wasted opportunities but why would you think Go is more practical?
Go is like a faster python imo, its good for prototyping when youre not sure what you need. As soon as you have the basic system down though it would be a good idea to write in rust if the traffic is big enough or you can justify the rewrite. Even then though with Go you wouldnt have to. My problem is it needs the Option and Result type and I would hope instantly. Till then ill be using rust
Go is performant and safe enough to be the final product. No need to re write to rust unless you really really need that additional performance
Meet Swift: Compiled, No garbage collection, async, strict interfaces, fast, Generics, simple syntax, open source... Having built a REST api in Swift, I prefer it to Rust & Go. Hope the market wakes up to this and that Swift server thrives !
Aren't a lot of rest API's just mapping data to slightly different data? Seems like it should be a perfect fit for Rust?
What are some of the things that make it hard? Are auth and contexts causing you to do a lot of annoying lifetimes and moves?
I have never built something large, so I'm curious.
Yep. Elixir web frameworks treat every request as a pure function, basically. He talks a lot of talk, but doesn't show us the code. Afraid to be roasted perhaps?
@@josevargas686 I don't know perhaps he has a usecase where he needs a lot of mutable state 🤷♂
I have never had such a use case. That's the neat thing about building Rest or Graphql servers, no state, no head ache.
I Like GO syntax, it's a nice language to work with
I want to hear his take on C# now with all the language changes
Yup, i would go for C# after the Javascript saturates and Reactjs collapses.
Unless c# has first class developer support on Linux. It's a hard pass for me. Would rather fight for Rust at work
@7xr1e20ln8 is the dotnet CLI not enough "first class linux support" for you? My workflow for C# stays the same regardless of the platform. Not sure the last time you have used C# but .Net 6 forward feels very good cross platform-wise
He already said he doesn’t like it lol
He’s not a fan of strictly OOP languages
He rather go to the grave than to assume C# is great. I watch his steam alot, so many different languages features that he claims makes a language good are in C# but M$ badddddddd. Like grow up 😂
Honestly, I tried writing Rust. It is no fun.
With Go I feel more like C#, general purpose language, clear abstraction, I don't fight against it, I go with the flow.
Isn't Vlang suppose to be Go with the Option/Result types? I.e. no nil?
Hi, what is the good go package for web server today? chin or just use go mux?
I kinda want to see Rust really work its system more user friendly in terms of Rust itself handling more about the safety and not pushing it on the user, but still be the boss who breathes on your neck pointing out all the mistakes and watching you trying to figure out what the hell you're supposed to do to make the system respect its rules.
At this point so many people want to write Rust and so many people like the lanfuage but everyone hates writing Rust.
I'm a Rust developer and my hair is naturally grey. Why? Because I've seen it all - C, C++, Java, Python, Go and now Rust. Oh, BTW I'm 53 years old.
The reason he likes go is because he uses htmx which requires state on the server. If he separated his concerns better, then wouldn't be an issue.