I actually really liked that as well. I’ve locked it away because it’s a good mental shift to have that is how you should think about it, in the same way you shouldn’t think about “calling functions” but rather “sending messages” or ask the question, what messages does this thing respond to, not what methods does it have
Going on a complete tangent, I am very grateful for Primeagen for always critically analysing videos and articles he reads, and never having a knee-jerk reaction. He always has reasonable takes and points out flaws in his own logic and other's, and has the ability to disagree and agree with a person at the same time which a lot of people lack. Gotta say, that mature way of looking at things has left an impression on me that I will not forget.
Yeah, definitely one of the better looking to try to see what the point they have is. And being able to say "here they mention something interesting which has value, but this part I feel they went the wrong way and just lost the plot"
I agree. Primeagen is a rare gem. Software engineering is an art acquired through experience and hard work. His opinions are thought provoking and his talent and experience shines. He does not follow the hype train which others do in youtube and provides critical, resonable and deep analysis. His life lessons are also quite entertaining. One of the most intelligent and entertaining RUclipsr in this field.
What sparks the most joy for me, is when I can tightly hug my slow rust compiler from behind and whisper into her ear: "It's okay baby, I really thought about it, today we are going to do it unsafe"
As a one person sample as a new dev, Go is easier to code compared to TS. Tooling around TS is a MESS compared to Go. You need to know what packages to use, how all the apis work and what you actually need to go forward. It's a completly dark rain forest to navigate as someone new. Go? You got everything you need the moment you installed the language. The packages out there for Go isnt as saturated. There is 1 - 3 to do one thing. In JS/TS you have hundreds of options just for dom manipulation.
Having observed the endemic desire to "feel smart" among programmers throughout my learning process, I've come to value the opposite feeling for the simple reason that anyone who felt smart for doing it a more complicated way will now feel stupid when they see how simple it could have been.
I have the issue with colleagues complaining about complicated parts being complicated, but as soon as I get them to begrudgingly explain their solution it's apparent they don't understand the problem fully. The problem is more complex than they realise and therefore the solution is more complex. Can it be better? Sure. Simplified? With some changes in stack for sure, without there are still things to improve, yes. Is it worth our time? Maybe. Are their complaints valid? Absolutely not and I no longer have patience for people feeling smug about this idea that things can be so much simpler, but often if you were to work out their idea you would still need the complex part anyways and their simple solution is just added to it, making it more complex in practice. Had this colleague ask why we were spending so much time on an interface and whether we couldn't do without it (imagine a month of bureaucracy to change this interface after the fact). Had to stop myself asking what he was even doing here as a software engineer. Maybe I shouldn't have. Rant over.
@nextlifeonearth That is a totally valid other side of the coin! Not everything can be simple. I've just trained myself to feel good whenever I discover that it can be, so I'm more incentivized to look for the simple solution if it exists close at hand. If not, by all means brain away, brave engineer.
My experience with Go has been really positive. I think so much less of the language and so much more of my problem, I'd never really considered how much overhead languages bring, even my beloved Python. It also fits me because years ago, as a new dev, I discovered pretty quickly that I loved to do things the simple, clear, way even if it's repetitive. It's one of the reasons I loved Python, it's the main reason I love Go.
I do systems level programming using C and C++ for high performance back-end networking, but if was doing application development, using a garbage collected memory management language, Golang would be my preference. (I've done Java for many years too). Thing about Go is that it can tread the line into dealing with quasi systems programming things better than a language, say, such as Java. With Java, I'd go break out JNI instead, but JNI is rather much a pain in the rear to deal with.
I dont like Go (at least, compared to Rust), and I have had a hard time articulating why. I was kind of afraid it was because of something dumb like "not feeling smart," but I think the reason is actually because I dont feel like I'm learning. Maybe that's a better way for Theo to think of it too? In Go, when I got stuck, it was because of Go mod and some weird protobuf idiosyncracies; little oddball one-off implementation goof-ups that made me better at Go, but nothing else. When I get stuck in Rust, I end up learning about allocation inneficiencies and efficient programming patterns, and I feel like I'm better even at writing JS (even if it makes me hate it more ..)
@@bardeebooboothat’s not a maybe it is literally what it means lol and also has no bearing on the opinions Theo has shared on Go. Therefore, he deserves any allegations that he’s pandering because he is.
Theo is only interested in viewer engagement and his career as an influencer. He's a mid level dev that talks with the confidence of senior dev specialist on every topic. I know a thing or two about Vue. His recent Vue video is EMBARASSING. He is talking with the confidence of Chat GPT with the accuracy of Chat GPT. It was so bad, Evan You of Vue had to comment on the video to correct him. new devs: steer clear of theo at all costs.
@@hamm8934 his attitude is what i don't like the most. notice even in this video how he says "you can move faster in typescript. if you disagree with this, you haven't developed in both languages enough" as if it's a matter of fact. in almost every one of his videos he says something like that. then to top of it he says it in the most smug way possible. he's unbearable to watch.
Typescript's developer velocity feels deceptively high, but in reality, I end up losing velocity to random Javascript and Node bullshit than Go or Rust. There's so many moments where I have to stop and ask "why is it doing that?" or "what on earth does this error mean?". Go has a couple of footguns, and Rust has a high learning curve, but both languages are far more PREDICTABLE than Typescript.
I usually teach python to beginners, JS to intermediate devs, and was surprised at how easy go is. Multiple times when I was teaching I realized go is actually much easier to teach than JS because of how many hard edges JS has. Something as trivial as teaching reading a file you need to teach them more concepts and how to handle them, or have them blindly copy more code than you do for Go. Genuinely shocked me
The only things hard about Go were understanding the import system and working with pointers, which was obvious at the time I was learning Go but those things are not hard to get past by if you understand value vs reference variables in other languages (it's just more explicit here) and how to organize code. After that, it's just no-brainer stuff. Go is just clean and refreshing to work with.
@@Patmorgan235Us Yeah, even simple things like Array's are an absolute minefield and commonly produce javascript-only problems where you're no longer teaching to code, just teaching about edge cases in the API's
as someone who is going through Boot.dev (starts with Python, has a project in JS and then moves to teach Go) I've found that understanding how software is supposed to works has been a lot easier. For example I'm currently doing Web server stuff and that has been a lot easier now that I get I'm just shoveling JSON into Structs, checking if they are what I want, do with them what I need to ,and pack it all up into a new JSON object and ship it off. I don't have to worry about Classes, Inheritance and all that extra stuff, when most of the things I've done thus far have been moving data around. With Go there has not been any "How was I supposed to know that" moments yet like with Python and JS. My first introduction to pointers was actually just Python giving you "Object at 0x1234..." for that reason. Also with Go I'm learning when things can cause errors, because I'm forced to handle them, which I've liked thus far. I wish there was a shorthand for returning errors like there is checking for key in map, but that is not a big deal.
Is it weird that Go actually does spark joy for me? I think it's delightfully simple and brilliant, efficient and fast, basic but feature-ful. Python is the same way while writing, although it has other issues I find really annoying.
I’ve been a go developer for over 7 years, and it still sparks joy for me. It’s like carpenter‘s favourite hammer; it isn’t fancy, but it’s predictable and it gets the job done.
I am not an expert Rust programmer. I have only dabbled a little writing some small CLI utilities for my own personal use. A few thousand lines in total. My take on this so far, is that Rust perhaps is somewhat more time consuming for _writing_ code. But for getting things _done_ and production ready. I am not so sure. There's so many features in rust that helps you to write reliable software. The memory safety, error handling, the nitpicky but helpful compiler, the enums, the many great crates with really nice APIs. With Rust I am starting to feel that if it compiles, it works. This is not the case with Go or TS and even less so with dynamic typing. What I wonder is, when Rust is said to have low "Developer velocity", is that time to PR or time to production and does it include time spent on bug fixes? I suspect that "developer velocity" in this case might be too focused on setting Jira ticket to "Done" and not "this has been running in production for a month without any issues".
My experience using rust is the same. time to release is generally longer. But issues coming up later is also less frequent. Rust is good at preventing technical debt
What I love about langs like rust is that u can easily just code for hours on end without even running the thing and if your procedures/types are sound, it will just work... other than the trial and error approaches that stuff like MatLab and Python promote. Sure u can get close with type hints but having that on a language level makes it much easier for me to split complex problems into constituent parts while keeping the interfaces clear. It may lend itself to getting lost in creating abstractions but that is only a matter of self-control imo... at least you can make very powerful abstractions in Rust.
> With Rust I am starting to feel that if it compiles, it works. This is not the case with Go What specifically with Golang do you not feel like that about? It has not been my experience
Yeah I don't really get the whole developer velocity argument against it. It literally is not THAT difficult. Surely not more difficult than C++ or related. I think to treat it as some kind of TS replacement is the mistake that creates this strange perspective that it's somehow slower to get things done in it. Almost entirely positive this is the software dev youtuber syndrome of talking about and comparing programming languages and other tech, in a way nobody in the real world does.
@@complexity5545 Exactly the same. I saw Prime cover his content a few times and thought I'd give Theo's work a shot. After a few videos I realized he has nothing to contribute and is, essentially, grifting.
Im currently mentoring two talented graduates of mechanical engineering who transitioned to IT. They were able to build a CLI game similar to nintendo final fantasy SNES game in a matter of 2 weeks using Go.
Use to hate k8s till I really took time to learn it. Building your own infra cluster is quite handy. Once you get past the massive learning curve you instantly see the benefits. P.s. golang is enjoyable.
Same, as someone who came from the infra world first, I can honestly say that in most cases, k8s is the way to go. I understand it’s an abstraction on an abstraction, but unless your apps are micro serviced to hell, it’s one of the best ways for a small team or individual to scale and deploy seamlessly, in a way that’d have you thinking that they’re 20x the size/budget they really are.
by 'building your own infra cluster', do you mean as a sideproject, ie not a cluster to be used for a production product? how would I best go about doing this? I've used docker for years with my job but never had to build something from scratch so I did some side stuff in it to get comfortable. I wanted to do the same with kubernetes but idk how I should do that without spending a ton of money and without actually needing to scale anything.
The complete Diagram (Ranked by Speed): Rust - GO - TS Runtime Performance GO - TS - Rust Developer Velocity GO - TS - Rust Compile TImes GO - TS - Rust Fast to learn GO - Rust - TS Quick to deploy
So is TS better or Go in that regard? "Personally", it feels a lot easier on TS especially when on Bun. I have a hard time setting up projects in Go because I personally don't know how to structure projects on it. On TS, I have a lot of. Both are kind of vastly different in setting up, which is kind of the friction I get into when developing in Go. (I move slower). Granted, both languages allow you to set up projects almost the way you want because there's no overarching framework for setting them up. Which is why it's probably hard.
@@gadgetboyplaysmche’s not referring to project structure here, which Go and TS both don’t care what structure you make so they’re kind of the same in that regard. He’s referring to the amount of config files your run of the mill Node project has. Just create a next app and see how many config files you have to deal with. Golang doesn’t have this problem. Many times I try something in a library, for it to error and the docs tell me to go add a line to the tsconfig or to alter the version of node to esnext and stuff like that. It’s a nightmare.
As a DevOps Engineer, K8S is great but avoid it as you can. Implement a full-blown container orchestration just for a classic frontend-backend is not worth it
Yeah, avoid K8S like you avoid microservices. It makes sense at a certain point but if you don't have the problems it solves don't invite that complexity
i love a naive(basic) k8s setup for my personal stuff it took away fiddling with stuff, would i use it in professional environment maybe depending on what i would be putting on it
@@Patmorgan235Usno i have a 4 node k8s cluster(1 control plane 3 worker nodes), pretty basic stuff DNS as service discovery, no service mesh im using flannel as networking only complex thing is storage where i have rook but that is mostly becuase i wanted to see ceph in action more then anything
@@Patmorgan235Uspodman is more of a docker replacement than k8s. K8s just orchestrates running containers. It doesn't do the actual running of the containers.
Because Theo has no idea what he's talking about. He's a content creator not a serious developer. He knows little about nearly everything I've had the displeasure of seeing from him.
Theo has a very high "wrong" ratio in his opinions. Either it's intentional for vitality, or trying to be a bit of the case for the opposite taken too extreme (balance is needed) but does often end in a wrong place with bad arguments...even when arguing against something that is also wrong.
Rust compilation speed is mostly because of library ecosystem afaik. They use too many traits/generics etc. They could do more trait boxing and even just duplicating code a little bit so things would compile a lot faster. If you don't use actix/tokio kind of libraries (ik not very likely) compilation is completely fine
Why is everyone here hating on rust suddenly 😂 I know all 3 languages and after getting decent at rust I can never go back to any other language. Just the raw confidence you get from writing Rust is amazing!!
No way is TS faster than Go in dev velocity. The velocity gained with go build alone puts it several standard deviations above TS. Go is what TS andys think TS is.
I have a pretty beefy computer but I've always noticed Go being slower when developing. Is it just me? I also mean in the feedback loop. I use Bun and I don't feel bogged down by waiting for the whole .exe build to finish before I can test the app again. Although TS is "slower" (in runtime and transpilation probably), the feedback loop is actually quite fast probably because it's a lot easier to setup "faster" devtools on Typescript than in Go. You can have HMR, Codegen, CLI scripts in package json, etc super easily wrapped in little libraries. The devtools around TS is a lot more convenient. In Go I have to get 'Make' to replicate the ease of use that package.json scripts have. On Windows, 'Make' isn't there by default, so I install it. Even on Make, it's difficult to make good scripts lol. I couldn't even get Air to setup correctly for live reloading. Even then it's a bit of wait time to wait for the build and try again (On a simple Hello World app backend app btw). On Bun it's quite fast.
@@gadgetboyplaysmcWhy do you need make for go? The built in tooling has pretty much everything you need. If you really _need_ hot reload (you usually don't) you can use one of the many go packages for that use. I usually wrap my web-oriented projects in a dev docker container that has a hot reload package.
Its cool to see prime knowing his shit at least in terms of why I love go. I'm a Jr nobody but Go has been nothing but pure joy. So fun to just build. So much available in just vanilla Go. No crazy dependencies. Just have fun doing whatever with the base package. Not to mention the Gopher is cute.
It's funny how he is comparing a compiler for typescript with the rust compiler. There is no way we are comparing something that just strips the made up types of an interpreted language with something that builds extremely fast binaries with optimization level 3 and also does all the borrow checking and extremely nice errors too. You can‘t make that agrument unless you actually just hate rust in which case it‘s better to just say that then making up bullshit arguments.
I worked with senior TS developper in two different companies, their code was horrendous. TS (on top of possibility to be a pain to configure) can actually be written properly, it's almost never the case.
JS is alright but TS is terror! Completely Unnecessary, its like C# people are so used to writing C# at Microsoft that they want to use C# to compile to JS, thats what Typescript is.
Like you, when I was younger(teenage, early 20s) I looked at languages like cool toys and I needed to have fun writing in a language. Now in my 30s I code to solve problems and solving problems is what I enjoy and Go is a great language for that. I'm extremely productive with it, performance is good, I have nearly everything I need in the standard library and it's super easy to build and deploy.
1:09 I don't see any reason why someone running a home lab would use kubernetes. I set it up and it just was more hassle than it was worth to keep it maintained. Instead I just run two instances of any service I need to be high availability and keep good backups of everything that isn't.
here goes the reasoning for the error handling in go: you can do a try catch, calling multiple functions in the try block and having a generic catch, when you dont care about which specific type of error occurs or multiple catch blocks. you still dont know which exact function in the try block threw it and that could have negative implications. you may argue that if you need to revert some state or do some custom error handling logic, that you can isolate that one function call, pull it up and do a custom try catch around only that. this then turns into the equivalent of the verbose error handling in golang. you will then argue that this is not quite so, because you can still, if you wish to, opt to use the try catch with multiple functions in the try block, so you have the choice of doing it both ways. and herein lies the problem. you, as a developer, may find it perfectly feasible to do it that way, to call 5 functions in your try block and do a generic catch, because it just fits in the current status quo. the problem is, when the software is extended over the next 5 years and there is feature bloat, maintaining that try catch block becomes complex. the process of isolating a call may be non-trivial. thus more error prone. the golang way addresses exactly that issue. it is not possible to make a sweeping try catch across multiple functions which could fail. thus, you have to invest writing verbose and "painful" code now... this secures a less painful future. the opposite is that you have a painless experience now, but torture awaits you in the future.
The developer velocity of TypeScript drops of very quick as you add devs and lins of code. Go stays steady over time. Both depend on the quality of developers
"React makes Go hard" I think JS makes React hard. I used to be a big React.JS hater, then I used React.Lua and I felt like I'd been enlightened. I've said this before but if there was a version of React ported to Go, it could be an incredible development experience.
If you're going to include dev velocity, you have to consider the following short comings of TS: - Starting a new project/service requires a good amount of configuration and build tools. - Everything is a dependency, making dependency management more difficult - There is no uniform tooling, so you have to make sure you set up your formatter, linter, etc - Even testing is a third party lib I can set up a go project with formatting, linting, unit tests, benchmarks, etc all using the go CLI in about 10-15 minutes. It would take me hours to set up the same thing for a typescript project, and now I have 5+ config files to maintain as well just to have standard tooling.
i wonder if he ever will learn about pypy, as he is speaking about "python" while he has in mind "cpython". as someone going from js world he should know that in many cases there are multiple implementations for a particular language. btw. most implementations (ms, mono) c# (or more in general - languages for CLR runtime) - are using AoT compilation.
Go before generics was terrible. I have seen a few Go projects where devs "designed around" not having generics. The code turn out to be worse (codegen, unsafe casts). Now that it has generics, it is a solid language in the Cathedral camp.
Listening to the discussion on go channels makes me feel that neither party has used channels heavily. In theory this should be bad, but in pratice, it works quite well.
37:37 the solution to this verbosity is the ? operator for Result and otherwise something like F#'s pipe, pattern matching and computation expressions. C# has the Try pattern with attributes available to assist the compiler - eg the "out var is not null when return value true" (though it doesn't work in conjunction with async) But of course you can't get away from binding or mapping the monad, that's just how they work. But you can't get away from it anyway, even with Go style err, or exceptions
This video convinced me I should learn Go. As a relative new-comer (3+ yrs).. I hate the amount of pointless NERD nonsense I have to learn and unlearn that gets in the way of getting something done. What sparks joy for me is something that works, not feeling like Megamind at the end of each day.
@@voidwalker7774how? rust is a complicated language, in large part by necessity due to being memory safe without GC, but that dosen't account for all of it. There's also all the functional programming stuff, which is certainly extra complexity and not something you want if you dislike "NERD stuff".
@@somenameidk5278 Imo it's the argument to use something like Gleam or Elm. You get basically all the safety that Rust gives you, but without a big complex language (at the expense of sometimes feeling slightly limited)
12:00 Developer velocity vs runtime & compilation performance is not even in the same universe of hard to measure. Write something twice in different languages and follow the same algorithm/structure, the numbers often *do* extrapolate to larger projects very well becuase that general performance metric is all you care about. You can even do a series of favored tests where you let one language lead with a natural implementation and the other language mimics, leading you to weaker but still signficant results. Becuase if you care about latency you care about latency. If you care about throughput you care about throughput. And for whatever algorithm you've chosen it'll eventually be similar machine instructions being executed between the languages. Even TS, all those string manipulations just to get to a value? They'll eventually land you in a position where you can issue ADD on the values of a.['a'] and a.['b']. What those operations are are _extra_ work. Which by its very nature is slower. Sure, getting the average slowness of one language relative to another considering all possible problems and solutions (even weighted by popularity) is impossible. But getting a good estimate for expected performance is different. With developer velocity you're practically into the social sciences. Every measure you can take that's objective is very indirect. Number of issues, commits, time taken on project to date vs checkmarks on the technical specificaiton. They suck becuase DV must account for the future with maintainence and an expanded scope. Various code/application quality measures like performance must also be accounted for. This lands it in the observational space, which has very little value objectively. Especially with the sample size of software projects. The moment you attempt to make any trial that's supposed to mimic the quality of your performance metrics you're into the millions in costs to run this experiment and you'll still have issues. So it's essentially just observational studies.
I don't understand how he came to his "uncanny valley" take. I've always thought that Go, even if it has its flaws/issues, had more of the "best of both worlds" when it came to performance and development speed. Its syntax and ease-of-use is akin to Python, but compiled Go often runs almost as fast as Rust, and usually faster than Java.
In University I took a total of 2 classes that involved the front end. A graphics class using js and an information systems class that happened to have a section on html/css web design. I did however take classes on operating systems, android programming, computer architecture, compilers, and others. I did however learn about multiprocessing, network protocols, how packets travel over http, vms, servers and other concepts that have been a huge benefit now that I've taught myself fullstack dev. It took a while after graduating but I did get there. Doing both university and bootcamp is probably best but is very expensive
11:10 This is the real truth. Writing most of the code is easy. Just keeping the build working, tests running, dependencies working and ci/cd all happy in JS/TS land is like 90% of the work
about the non-UTF-8 filesystem thing, that is actually a real issue that Go does deal with, it uses WTF-8 internally to map those fake characters and deal with them properly. It's not fixed better by not doing it the Go way. UTF-8 as a default is still the better option.
Writing Typescript feels great at first but it gets worse every day you use it. Go feels pretty bad to begin with but it feels better every day you use it. Theos chart also seem very misleading while correct, TS should be way off to the right on runtime and go should be rigth next to TS in Dev. Vel.
The behaviour of nil channels (send or recv always blocking) is great for writing select loops where sometimes you need to turn off one of the select cases based on the current state. So for example if you don't currently have anything to send, you can set your dest channel to nil but still use the same loop, then when you have something to write you set that dest back to the real destination. If they worked differently the code to do the same thing is much more awkward.
Plus the recv from a closed channel always returning zero is extremely useful for signalling multiple listeners with one outgoing signal - it's how cancelling contexts (or stop channels) work.
As an IT guy, here's how projects manifest. Can you just. Then out of nowhere, you look into it, you create the simple thing, and the customer learns "What is possible" and now you're into Project Land. Welcome to project land, where the simple scales both up and out, and the business waters the project like a plant with money. One of the whackiest things that happened to me, was a "Simple request" which was 2 hours of work, pinned entire systems together and suddenly, I was the GO TO GUY for pinning systems together.
I really like programming in go. To me, I feel smart when I solve a complex problem in a simple way, not when I get to pull out some some obscure language feature
V may stand for Vaporware, but they're handling the nil/option thing pretty well: there is no null/nil, you can easily propagate the error instead of having a guard, and functions that can return an error just have a ! on their return type (so they need to be handled). Honestly my favorite error handling so far.
So if I wanted to do mobile dev, would you prefer learning two native languages or react-native? For me, react-native has been really powerful and let's me "move fast" because all the logic and UI lives in one language and I don't have to set up bindings. This also lets other team members already experienced in js adopt the project much faster as long as they understand react
It’s an interesting topic for sure each each with the pros and cons. And all comes down to what you’re trying to achieve. The main trade offs to frameworks like React Native is that you can lose out on the truly native look and feel. Flexbox is great, but it’s far less powerful than the constraint based layouts on Apple platforms. Platform differences in animations, gestures, navigation, and design language can also vary greatly and be difficult to write in a generic fashion. This all leads to apps that look and feel the same on all the platform, with slight differences for simple stuff, rather than feeling truly native to their platform. Your mileage may vary, but personally I prefer to reduce the number of leaky abstractions I use and just prefer to learn the underlying tech stack, which gives me much more control and runs less risk of platform changes breaking my app.
@7:55 Theo is a F.I. - Rust is being used to build compilers for your sloppy languages because it's Fast - DUH! I can't even watch the rest of this video with this fool...
8 месяцев назад+1
Yeah, I know a few people that also dislike Go exactly because it makes them feel dumb or not smart enough because they can't create extreme abstractions and feel smart because they produce cryptic code instead of easily readable code and they can't stand the ideia of their code looking exactly like the code of 1000 other people while solving the same problem.
I am just laughing when the discussion pivots to build times as I am on a project where the discussion right now is about the build (and testing etc) taking 20 minutes. Every rebase takes 20 minutes. We now have to do a lot of work to change the build tool. Also, I have no respect for Theo as I saw his video where he said testing is useless. I know controversial takes get more views, but come on? That's such a bad opinion.
I think he said that how testing is often done is useless (ie, testing every small detail), which i would agree. Just test the hard stuff, and where you could have point of failures.
Python is not faster than JS. You can get C bindings in JS as well like in the case of the sharp library, it just isn't as common because V8 is pretty fast unlike python
Golang solves an important problem that most languages fail to solve... It solves my dumbness... Little learning I am good for a low level back-end developer 😎😀
I did a 6 months bootcamp (3 of which were an internship). Now, I am working on my degree, and I have to agree that it is helping me fill a lot of knowledge debt (we did not learn anything about memory management in bootcamp) that are making me a better dev in what I learned in the bootcamp.
I've seen like 5 Theo videos and can tell he is a mega grifter. I don't think he has the ability to form a useful opinion beyond "I don't like this because I am not familiar".
That image at the beginning "Ranked by Speed" Top: Yep Mid: I can't speak to Go, but I've used Rust and Typescript for a decade each and I'd say I'm way faster in Rust. For example, I managed 10,000 lines of Rust last week. I've never managed 10,000 lines of TS in a week. And for context I worked for a company that had a 600,000 line TS codebase. Bottom: Yep
If I remember correctly the main issue with rust compilation time, is that all of the packages also get compiled. So there’s no restoration of any precompiled packages like most languages do. Where they just toss the package binaries in output folder and that’s it. Rust has to recompile all of it, this results in a smaller output overall though as the parts of the libraries that aren’t being used can be trimmed. I feel like most anyone who’s started programming in a traditional typed language and does some JS or TS for their front end when they need is going to be way slower is JS or TS whereas the reverse is not necessarily true.
27:45 yeah, C# is either ahead-of-time compiled to machine code, or compiled to bytecode and JIT'ed to machine code on first launch. It's gotten a lot better than the last time you used it. That said, it's still behind Go in both performance and simplicity.
I don’t see any measurable difference between c# and golang in terms of performance. Go is faster at startup because it is compiled to machine code, where c# is JIT compiled, but the JIT compiler optimizes execution based on usage which can result in faster execution. Golang is much simpler than c# but whether that’s better or not is subjective. I like that c# is more feature rich, and it eliminates a lot of boiler plate that is common with go.
@@asherrfacee I'll defer because I've not ran my own tests, but all the conventional wisdom I'm aware of is that Go tends to be slightly ahead. But C# is very good (I'm a C# dev and prefer it over most other langs). I will say, though, that I do believe Golang is faster to onboard a new dev with than C#. But C# has the benefit of teaching you the .Net library which lets you pivot to F# or (and may the machine gods forgive me) Visual Basic (may it rest in peace /jk) later on.
I really dislike this diagram as it implies that rust as much faster than go as go is faster than ts. The x-axis isn’t to scale but if it were, it’d be clearer how much differences there are.
I think Go has faster dev speed than Python too. You might hit a typing bottleneck with python maybe at 2-3 thousand lines of code, and implementing mypy, and pyright is painful. Formatting with python isn't ideal with black, blue and others
The reason for uncanny valley is there can only be one top priority, and everything else is nice-to-have. Either performance is sacrificed for dev velocity or dev velocity is sacrificed for performance.
Doing some pet projects in Go rn. Even with proper error checking my velocity is surprisingly good. I've been using and loving Python since version 2.2.2 but now Go is becoming my favorite language.
I'd be interested in seeing new devs without previous exposure to programming try out different languages like Go, Python, C#, Gleem and JS. I think we often see the familiarity of the c-like syntax in Go as something that would make it good for beginners, since most of us probably started with something that looks like C, but that could easily just be our impression.
Personally, feeling smart when programming has a high correlation with messing up. Because it means I'm in unknown territory. Have you ever talked to a very senior eng who's an expert at something? They sure sound smart but they don't _feel_ smart themselves. They've been doing the stuff forever, it's just boring routine.
I would agree with Prime that familiarity is the key factor for velocity but that also means GO wins by default since it takes exponentially longer to be good with TS and GO considering you CANNOT get good with TS without having a solid understanding of JS and the the frameworks and underlying HTML it works with.
I like to see wanting to feel smart in coding as your brain asking you to work on improving “the resolution” of your thinking. It boils down to slowing down and to explore the problem. If you are smart you are naturally drawn to that. The activity is just something someone else would not benefit from.
I'm writing a little go webapp and found that I generally use pointers like a `Ref` type (for mutation & performance) but don't want them as `Option`s. In Rust, `Box` and `Option` are separate, but nullable pointers force them into a single type, so I can't easily enforce "never null` fields.
I'm sorry, but x.(interface {}).(*Something) is the horribleness that arises from go's type system. And calling footguns skill issues (34:00) means that JS is not a bad language and just hard to learn...
ignoring that 'velocity' is literally the worst concept to ever be applied to software engineering, typescript only wins in the sense that its the fastest to get something "working" with the heaviest of emphasis on the quotes. Source: I write 98% server side typescript at work :(.
Go enables multithreading without requiring developers to intentionally write multithreaded code or use async/await mechanisms. It addresses scaling effortlessly, unlike any other language that does this so naturally.
11:26 This is so true. Been working on big TS projects the pattern is always the same. You have bunch of services. Then the CI pipelines fails hard. No need to actually write your own tools in order to ship the whole app in reasonable time. The TS build system suck ballz
@@gadgetboyplaysmc I am not forcing myself to use it. I am pretty proficient in C, C++, C#, Python, ADA, and I just find myself using it in certain circumstances. Honestly it just seems intuitive to me. I do not have a computer science degree (chemistry actually) but I find it insanely simple to work in.
- statically typed compiled language - check; - no oop nonsense - check; - weird error handling, but hey at least it's not exceptions - check. These 3 things put Go in top 1% of programming languages.
On the boot camp talk I think you’re exactly right. I self-boot camped, got a job, and then didn’t really do continuing education outside of the job. I’ve recently jumped back on the education train to learning all the underlying stuff (and enjoying boot.dev…not cheap but it’s definitely worth its cost. Particularly with a discount code.) And I feel myself getting so much better at my job just because I know the base reason behind things.
The thing I put up as the indicator for ease of use in a language: How hard is it to write an HTTP request exclusively using built-ins? Rust makes it a little tricky because you need to resolve the name for an address before opening a connection and such, while Go makes it in a single call. But TypeScript, you might be able to use fetch, but in Node.js the standard way to build a request is to use 6 callback functions as event listeners and if you want to return the response back to the top-level and await it, now you also need to implement a Promise constructor, and pass the resolver into the response's "end" event, while binding the rejecter to the request's "error" event. Oh, and don't forget that a request body needs to be converted to a byte array or a string, and passed to the Request.prototype.write method as inherited from stream.Writable. I use Node.js on a daily basis, but the standard library can be frustrating to deal with. I long for a language like Go that is more feature rich in the standard library
I like to have a tool that works for my particular experience and skills. Like a nice grand piano. It might be the case that my piano is different from somebody with 7 years of playing. I hope that would not be construed as “wanting to feeling smart.”
21:15 I love writing C++ probably cause I like pain...err challenges I mean. But I understand the love for C it's a much simpler and straight forward language compared to C++. But C++ got all those bells and whistles you know more things to slap you in the face with when things go horribly wrong.
this video and the points in it sums up my reluctance to use rust. so much of rust is about rust and not what is being built. i’m having to use it for LibAFL right now and I think it’s a really, really bad use case/misapplication of rust. for applications like a fuzzer, i want to often directly manipulate memory in an unsafe way… why use a language designed to guard against that?
"You don't ship features, you ship maintenance to your future self" is an amazing quote.
I actually really liked that as well. I’ve locked it away because it’s a good mental shift to have that is how you should think about it, in the same way you shouldn’t think about “calling functions” but rather “sending messages” or ask the question, what messages does this thing respond to, not what methods does it have
100% definitely going to steal this quote
Note to future self: Auditing will be Required.
I can see myself having horrifyingly frustrating arguments back at work slinging around that quote
Going on a complete tangent, I am very grateful for Primeagen for always critically analysing videos and articles he reads, and never having a knee-jerk reaction. He always has reasonable takes and points out flaws in his own logic and other's, and has the ability to disagree and agree with a person at the same time which a lot of people lack. Gotta say, that mature way of looking at things has left an impression on me that I will not forget.
Yeah, definitely one of the better looking to try to see what the point they have is. And being able to say "here they mention something interesting which has value, but this part I feel they went the wrong way and just lost the plot"
I agree. Primeagen is a rare gem. Software engineering is an art acquired through experience and hard work. His opinions are thought provoking and his talent and experience shines. He does not follow the hype train which others do in youtube and provides critical, resonable and deep analysis. His life lessons are also quite entertaining. One of the most intelligent and entertaining RUclipsr in this field.
wdym, he always glazes and has the coldest critiques
What sparks the most joy for me, is when I can tightly hug my slow rust compiler from behind and whisper into her ear: "It's okay baby, I really thought about it, today we are going to do it unsafe"
As a one person sample as a new dev, Go is easier to code compared to TS. Tooling around TS is a MESS compared to Go. You need to know what packages to use, how all the apis work and what you actually need to go forward. It's a completly dark rain forest to navigate as someone new. Go? You got everything you need the moment you installed the language. The packages out there for Go isnt as saturated. There is 1 - 3 to do one thing. In JS/TS you have hundreds of options just for dom manipulation.
True, setting up all that TS build pipeline is extremely cumbersome
Having observed the endemic desire to "feel smart" among programmers throughout my learning process, I've come to value the opposite feeling for the simple reason that anyone who felt smart for doing it a more complicated way will now feel stupid when they see how simple it could have been.
I have the issue with colleagues complaining about complicated parts being complicated, but as soon as I get them to begrudgingly explain their solution it's apparent they don't understand the problem fully. The problem is more complex than they realise and therefore the solution is more complex. Can it be better? Sure. Simplified? With some changes in stack for sure, without there are still things to improve, yes. Is it worth our time? Maybe. Are their complaints valid? Absolutely not and I no longer have patience for people feeling smug about this idea that things can be so much simpler, but often if you were to work out their idea you would still need the complex part anyways and their simple solution is just added to it, making it more complex in practice. Had this colleague ask why we were spending so much time on an interface and whether we couldn't do without it (imagine a month of bureaucracy to change this interface after the fact). Had to stop myself asking what he was even doing here as a software engineer. Maybe I shouldn't have.
Rant over.
@nextlifeonearth That is a totally valid other side of the coin! Not everything can be simple. I've just trained myself to feel good whenever I discover that it can be, so I'm more incentivized to look for the simple solution if it exists close at hand. If not, by all means brain away, brave engineer.
My experience with Go has been really positive. I think so much less of the language and so much more of my problem, I'd never really considered how much overhead languages bring, even my beloved Python. It also fits me because years ago, as a new dev, I discovered pretty quickly that I loved to do things the simple, clear, way even if it's repetitive. It's one of the reasons I loved Python, it's the main reason I love Go.
"even python"?....but python is like the most insane overhead...
@@thekwoka4707 is it? Python is a pretty simple language
I always end up writing the most insane shit when I use python lol
I do systems level programming using C and C++ for high performance back-end networking, but if was doing application development, using a garbage collected memory management language, Golang would be my preference. (I've done Java for many years too). Thing about Go is that it can tread the line into dealing with quasi systems programming things better than a language, say, such as Java. With Java, I'd go break out JNI instead, but JNI is rather much a pain in the rear to deal with.
I dont like Go (at least, compared to Rust), and I have had a hard time articulating why. I was kind of afraid it was because of something dumb like "not feeling smart," but I think the reason is actually because I dont feel like I'm learning. Maybe that's a better way for Theo to think of it too?
In Go, when I got stuck, it was because of Go mod and some weird protobuf idiosyncracies; little oddball one-off implementation goof-ups that made me better at Go, but nothing else. When I get stuck in Rust, I end up learning about allocation inneficiencies and efficient programming patterns, and I feel like I'm better even at writing JS (even if it makes me hate it more ..)
W take
As soon as it starts to get "popular" he starts to like it, classic theo.....
Maybe 'popular' just means that the majority of people like it, make sense🤔
@@bardeebooboothat’s not a maybe it is literally what it means lol and also has no bearing on the opinions Theo has shared on Go.
Therefore, he deserves any allegations that he’s pandering because he is.
It is true tho. He glazes on every trendy topic.
Theo is only interested in viewer engagement and his career as an influencer. He's a mid level dev that talks with the confidence of senior dev specialist on every topic. I know a thing or two about Vue. His recent Vue video is EMBARASSING. He is talking with the confidence of Chat GPT with the accuracy of Chat GPT. It was so bad, Evan You of Vue had to comment on the video to correct him.
new devs: steer clear of theo at all costs.
@@hamm8934 his attitude is what i don't like the most. notice even in this video how he says "you can move faster in typescript. if you disagree with this, you haven't developed in both languages enough" as if it's a matter of fact. in almost every one of his videos he says something like that. then to top of it he says it in the most smug way possible. he's unbearable to watch.
Typescript's developer velocity feels deceptively high, but in reality, I end up losing velocity to random Javascript and Node bullshit than Go or Rust. There's so many moments where I have to stop and ask "why is it doing that?" or "what on earth does this error mean?". Go has a couple of footguns, and Rust has a high learning curve, but both languages are far more PREDICTABLE than Typescript.
On the flip side, I think Rust's velocity feels slower than it really is. That's mostly compared to other non-GC languages, though.
I usually teach python to beginners, JS to intermediate devs, and was surprised at how easy go is. Multiple times when I was teaching I realized go is actually much easier to teach than JS because of how many hard edges JS has. Something as trivial as teaching reading a file you need to teach them more concepts and how to handle them, or have them blindly copy more code than you do for Go. Genuinely shocked me
The only things hard about Go were understanding the import system and working with pointers, which was obvious at the time I was learning Go but those things are not hard to get past by if you understand value vs reference variables in other languages (it's just more explicit here) and how to organize code. After that, it's just no-brainer stuff. Go is just clean and refreshing to work with.
JS has so many dog water caveats like NaN and triple equals
@@Patmorgan235Us Yeah, even simple things like Array's are an absolute minefield and commonly produce javascript-only problems where you're no longer teaching to code, just teaching about edge cases in the API's
as someone who is going through Boot.dev (starts with Python, has a project in JS and then moves to teach Go) I've found that understanding how software is supposed to works has been a lot easier. For example I'm currently doing Web server stuff and that has been a lot easier now that I get I'm just shoveling JSON into Structs, checking if they are what I want, do with them what I need to ,and pack it all up into a new JSON object and ship it off. I don't have to worry about Classes, Inheritance and all that extra stuff, when most of the things I've done thus far have been moving data around. With Go there has not been any "How was I supposed to know that" moments yet like with Python and JS. My first introduction to pointers was actually just Python giving you "Object at 0x1234..." for that reason. Also with Go I'm learning when things can cause errors, because I'm forced to handle them, which I've liked thus far. I wish there was a shorthand for returning errors like there is checking for key in map, but that is not a big deal.
Go is easy C
Is it weird that Go actually does spark joy for me? I think it's delightfully simple and brilliant, efficient and fast, basic but feature-ful. Python is the same way while writing, although it has other issues I find really annoying.
I love it. It just gets out of the way. Elixir is really awesome too though
I’ve been a go developer for over 7 years, and it still sparks joy for me. It’s like carpenter‘s favourite hammer; it isn’t fancy, but it’s predictable and it gets the job done.
I am not an expert Rust programmer. I have only dabbled a little writing some small CLI utilities for my own personal use. A few thousand lines in total. My take on this so far, is that Rust perhaps is somewhat more time consuming for _writing_ code. But for getting things _done_ and production ready. I am not so sure. There's so many features in rust that helps you to write reliable software. The memory safety, error handling, the nitpicky but helpful compiler, the enums, the many great crates with really nice APIs. With Rust I am starting to feel that if it compiles, it works. This is not the case with Go or TS and even less so with dynamic typing.
What I wonder is, when Rust is said to have low "Developer velocity", is that time to PR or time to production and does it include time spent on bug fixes? I suspect that "developer velocity" in this case might be too focused on setting Jira ticket to "Done" and not "this has been running in production for a month without any issues".
My experience using rust is the same. time to release is generally longer. But issues coming up later is also less frequent. Rust is good at preventing technical debt
What I love about langs like rust is that u can easily just code for hours on end without even running the thing and if your procedures/types are sound, it will just work... other than the trial and error approaches that stuff like MatLab and Python promote.
Sure u can get close with type hints but having that on a language level makes it much easier for me to split complex problems into constituent parts while keeping the interfaces clear.
It may lend itself to getting lost in creating abstractions but that is only a matter of self-control imo... at least you can make very powerful abstractions in Rust.
> With Rust I am starting to feel that if it compiles, it works. This is not the case with Go
What specifically with Golang do you not feel like that about? It has not been my experience
Yeah I don't really get the whole developer velocity argument against it. It literally is not THAT difficult. Surely not more difficult than C++ or related. I think to treat it as some kind of TS replacement is the mistake that creates this strange perspective that it's somehow slower to get things done in it. Almost entirely positive this is the software dev youtuber syndrome of talking about and comparing programming languages and other tech, in a way nobody in the real world does.
Rust and Haskell are the only languages I know where most packages are _complete_ and do not receive updates because there is nothing to fix.
17:56 Agree with Ginger Bill here. Feeling smart usually leads to getting sloppy and assuming your bad code is correct.
the only way for me to watch theos videos to the end is through the lense of primagen
Fucking real. That guy has such garbage takes with such clickbait titles that it's impossible to watch.
What you talking about? Theo’s great
@@Kane0123Theo is so junior it hurts. He talks like a senior but walks like a junior out of a boot camp.
@@ElyonDominusYeah I subscribed for a week and then unsubscribed him because I figured out that he was "almost a junior." He had real bad advice.
@@complexity5545 Exactly the same. I saw Prime cover his content a few times and thought I'd give Theo's work a shot. After a few videos I realized he has nothing to contribute and is, essentially, grifting.
I wrote a text editor in Rust in like 2 weeks using GTK bindings. It was actually one of my more fun projects I have done.
Im currently mentoring two talented graduates of mechanical engineering who transitioned to IT. They were able to build a CLI game similar to nintendo final fantasy SNES game in a matter of 2 weeks using Go.
Thank for posting on youtube. I can never watch you live, but it does bring me joy to watch the stream here
He streams also on youtube normally? I watch on youtube always since I have youtube premium and Twitch ads do absolute damage to my psyche.
Use to hate k8s till I really took time to learn it. Building your own infra cluster is quite handy. Once you get past the massive learning curve you instantly see the benefits.
P.s. golang is enjoyable.
Same, as someone who came from the infra world first, I can honestly say that in most cases, k8s is the way to go. I understand it’s an abstraction on an abstraction, but unless your apps are micro serviced to hell, it’s one of the best ways for a small team or individual to scale and deploy seamlessly, in a way that’d have you thinking that they’re 20x the size/budget they really are.
most seem to think it must be paired with having 1000 microservices when that isn't true at all
Unless you are running onprem k8s is incorrect and a backwards step from the cloud apis.
by 'building your own infra cluster', do you mean as a sideproject, ie not a cluster to be used for a production product? how would I best go about doing this? I've used docker for years with my job but never had to build something from scratch so I did some side stuff in it to get comfortable. I wanted to do the same with kubernetes but idk how I should do that without spending a ton of money and without actually needing to scale anything.
The complete Diagram (Ranked by Speed):
Rust - GO - TS Runtime Performance
GO - TS - Rust Developer Velocity
GO - TS - Rust Compile TImes
GO - TS - Rust Fast to learn
GO - Rust - TS Quick to deploy
because it's only 3 column '__') actually should be quite far, something like this:
GO ----- TS --------- Rust Fast to learn
Wake me up when Theo starts using Zig
... and gets a haircut
... and a new shirt
Trying to start and configure a real node project vs starting up a go project is night and day.
Gives me nightmares
In my experience, configuring a rust project is also pretty damn easy and consistent
Setting up a TS library is near impossible, so that it works across browser and node.
So is TS better or Go in that regard?
"Personally", it feels a lot easier on TS especially when on Bun.
I have a hard time setting up projects in Go because I personally don't know how to structure projects on it. On TS, I have a lot of. Both are kind of vastly different in setting up, which is kind of the friction I get into when developing in Go. (I move slower).
Granted, both languages allow you to set up projects almost the way you want because there's no overarching framework for setting them up. Which is why it's probably hard.
@@gadgetboyplaysmche’s not referring to project structure here, which Go and TS both don’t care what structure you make so they’re kind of the same in that regard. He’s referring to the amount of config files your run of the mill Node project has. Just create a next app and see how many config files you have to deal with. Golang doesn’t have this problem. Many times I try something in a library, for it to error and the docs tell me to go add a line to the tsconfig or to alter the version of node to esnext and stuff like that. It’s a nightmare.
As a DevOps Engineer, K8S is great but avoid it as you can. Implement a full-blown container orchestration just for a classic frontend-backend is not worth it
Yeah, avoid K8S like you avoid microservices. It makes sense at a certain point but if you don't have the problems it solves don't invite that complexity
i love a naive(basic) k8s setup for my personal stuff it took away fiddling with stuff, would i use it in professional environment maybe depending on what i would be putting on it
@@bigpod so podman?
@@Patmorgan235Usno i have a 4 node k8s cluster(1 control plane 3 worker nodes), pretty basic stuff DNS as service discovery, no service mesh im using flannel as networking only complex thing is storage where i have rook but that is mostly becuase i wanted to see ceph in action more then anything
@@Patmorgan235Uspodman is more of a docker replacement than k8s. K8s just orchestrates running containers. It doesn't do the actual running of the containers.
I still don't understand why Theo thinks that performance and ease of use are opposites.
Because Theo has no idea what he's talking about. He's a content creator not a serious developer. He knows little about nearly everything I've had the displeasure of seeing from him.
Theo has a very high "wrong" ratio in his opinions. Either it's intentional for vitality, or trying to be a bit of the case for the opposite taken too extreme (balance is needed) but does often end in a wrong place with bad arguments...even when arguing against something that is also wrong.
@@thekwoka4707 "... even when arguing against something that is also wrong." are you talking about Go or something else.
Facts: Bob Ross was a Instructor at the Military, he started painting, because he didn't want to yell at people anymore.
Rust compilation speed is mostly because of library ecosystem afaik. They use too many traits/generics etc. They could do more trait boxing and even just duplicating code a little bit so things would compile a lot faster. If you don't use actix/tokio kind of libraries (ik not very likely) compilation is completely fine
Why is everyone here hating on rust suddenly 😂
I know all 3 languages and after getting decent at rust I can never go back to any other language. Just the raw confidence you get from writing Rust is amazing!!
No worries. This is YT. I wish Rust on the frontend was a real alternative. So I still need some Typescript. Otherwise it would all be Rust.
No way is TS faster than Go in dev velocity. The velocity gained with go build alone puts it several standard deviations above TS. Go is what TS andys think TS is.
It’s Teo, he is pretty bias
@@agusaris5031 100%
Go builds my ts 😅
I have a pretty beefy computer but I've always noticed Go being slower when developing. Is it just me?
I also mean in the feedback loop. I use Bun and I don't feel bogged down by waiting for the whole .exe build to finish before I can test the app again.
Although TS is "slower" (in runtime and transpilation probably), the feedback loop is actually quite fast probably because it's a lot easier to setup "faster" devtools on Typescript than in Go. You can have HMR, Codegen, CLI scripts in package json, etc super easily wrapped in little libraries. The devtools around TS is a lot more convenient.
In Go I have to get 'Make' to replicate the ease of use that package.json scripts have. On Windows, 'Make' isn't there by default, so I install it. Even on Make, it's difficult to make good scripts lol.
I couldn't even get Air to setup correctly for live reloading. Even then it's a bit of wait time to wait for the build and try again (On a simple Hello World app backend app btw). On Bun it's quite fast.
@@gadgetboyplaysmcWhy do you need make for go? The built in tooling has pretty much everything you need. If you really _need_ hot reload (you usually don't) you can use one of the many go packages for that use. I usually wrap my web-oriented projects in a dev docker container that has a hot reload package.
Its cool to see prime knowing his shit at least in terms of why I love go. I'm a Jr nobody but Go has been nothing but pure joy. So fun to just build. So much available in just vanilla Go. No crazy dependencies. Just have fun doing whatever with the base package. Not to mention the Gopher is cute.
It's funny how he is comparing a compiler for typescript with the rust compiler. There is no way we are comparing something that just strips the made up types of an interpreted language with something that builds extremely fast binaries with optimization level 3 and also does all the borrow checking and extremely nice errors too.
You can‘t make that agrument unless you actually just hate rust in which case it‘s better to just say that then making up bullshit arguments.
The typescript type checker is probably more complex than the rust borrow/type checker
JS/TS doesn't spark joy. It sparks terror!
I worked with senior TS developper in two different companies, their code was horrendous. TS (on top of possibility to be a pain to configure) can actually be written properly, it's almost never the case.
@@thomasp3428same for python in my experience. I can only prevent my code base from rot because I'm the only contributor.
Some guy said TS is a linter 🤣
😂@@jitxhere
JS is alright but TS is terror! Completely Unnecessary, its like C# people are so used to writing C# at Microsoft that they want to use C# to compile to JS, thats what Typescript is.
The table missed the **maintenance** line.
Reading and Editing legacy code is an important aspect of development.
I love Rust, because years later i still can read and understany my code. Like Python.
Same for documentation, go is simply better.
Like you, when I was younger(teenage, early 20s) I looked at languages like cool toys and I needed to have fun writing in a language. Now in my 30s I code to solve problems and solving problems is what I enjoy and Go is a great language for that. I'm extremely productive with it, performance is good, I have nearly everything I need in the standard library and it's super easy to build and deploy.
About Bob Ross - before he went painting, he was really screaming hard in military :)
And if I remember it right, that experience made him want to never scream again. That how he became the chill guy we all know him as.
1:09 I don't see any reason why someone running a home lab would use kubernetes. I set it up and it just was more hassle than it was worth to keep it maintained. Instead I just run two instances of any service I need to be high availability and keep good backups of everything that isn't.
here goes the reasoning for the error handling in go:
you can do a try catch, calling multiple functions in the try block and having a generic catch, when you dont care about which specific type of error occurs or multiple catch blocks. you still dont know which exact function in the try block threw it and that could have negative implications.
you may argue that if you need to revert some state or do some custom error handling logic, that you can isolate that one function call, pull it up and do a custom try catch around only that.
this then turns into the equivalent of the verbose error handling in golang.
you will then argue that this is not quite so, because you can still, if you wish to, opt to use the try catch with multiple functions in the try block, so you have the choice of doing it both ways.
and herein lies the problem. you, as a developer, may find it perfectly feasible to do it that way, to call 5 functions in your try block and do a generic catch, because it just fits in the current status quo.
the problem is, when the software is extended over the next 5 years and there is feature bloat, maintaining that try catch block becomes complex. the process of isolating a call may be non-trivial. thus more error prone.
the golang way addresses exactly that issue. it is not possible to make a sweeping try catch across multiple functions which could fail.
thus, you have to invest writing verbose and "painful" code now... this secures a less painful future.
the opposite is that you have a painless experience now, but torture awaits you in the future.
Prime may want "skill issue" to be his epitaph, but Theo should tattoo it on the forehead...
❤❤❤
The developer velocity of TypeScript drops of very quick as you add devs and lins of code. Go stays steady over time. Both depend on the quality of developers
"React makes Go hard" I think JS makes React hard. I used to be a big React.JS hater, then I used React.Lua and I felt like I'd been enlightened.
I've said this before but if there was a version of React ported to Go, it could be an incredible development experience.
If you're going to include dev velocity, you have to consider the following short comings of TS:
- Starting a new project/service requires a good amount of configuration and build tools.
- Everything is a dependency, making dependency management more difficult
- There is no uniform tooling, so you have to make sure you set up your formatter, linter, etc
- Even testing is a third party lib
I can set up a go project with formatting, linting, unit tests, benchmarks, etc all using the go CLI in about 10-15 minutes. It would take me hours to set up the same thing for a typescript project, and now I have 5+ config files to maintain as well just to have standard tooling.
TS means you hired too many junior devs, or someone was assertive.
Would you rather:
- Switch from JS to TS
- In-house external libraries into utilities/suites
Your take on react is so true. I think the middleground is astro, where you can use react as components, but use any language on the backend
oof.. grunt.. that feel when you remember the stickers you had on your laptop back then
The boar. How about Yeoman!! Lol
i wonder if he ever will learn about pypy, as he is speaking about "python" while he has in mind "cpython".
as someone going from js world he should know that in many cases there are multiple implementations for a particular language.
btw. most implementations (ms, mono) c# (or more in general - languages for CLR runtime) - are using AoT compilation.
Go before generics was terrible. I have seen a few Go projects where devs "designed around" not having generics. The code turn out to be worse (codegen, unsafe casts).
Now that it has generics, it is a solid language in the Cathedral camp.
Listening to the discussion on go channels makes me feel that neither party has used channels heavily. In theory this should be bad, but in pratice, it works quite well.
Isn't it exactly the same in pipes in Unix?
Story of Go. Many of it's problems are primarily in theoretical nature and are likely never in the way of working on a project.
I would write everything in go in the begining and port performance sensitive parts to zig when goes stable :)
37:37 the solution to this verbosity is the ? operator for Result and otherwise something like F#'s pipe, pattern matching and computation expressions. C# has the Try pattern with attributes available to assist the compiler - eg the "out var is not null when return value true" (though it doesn't work in conjunction with async)
But of course you can't get away from binding or mapping the monad, that's just how they work. But you can't get away from it anyway, even with Go style err, or exceptions
Isn't it the best approach, Just use TS for Frontend
and Go for backend and Rust for higky optimized system
why so chaos?
people click
This video convinced me I should learn Go. As a relative new-comer (3+ yrs).. I hate the amount of pointless NERD nonsense I have to learn and unlearn that gets in the way of getting something done. What sparks joy for me is something that works, not feeling like Megamind at the end of each day.
Thats acutally the argument for using Rust.
@@voidwalker7774good one
Could have been an exe…
@@voidwalker7774how? rust is a complicated language, in large part by necessity due to being memory safe without GC, but that dosen't account for all of it. There's also all the functional programming stuff, which is certainly extra complexity and not something you want if you dislike "NERD stuff".
@@somenameidk5278 Imo it's the argument to use something like Gleam or Elm. You get basically all the safety that Rust gives you, but without a big complex language (at the expense of sometimes feeling slightly limited)
For me, Go delivers on Python's promises, and does it better. Less is more, explicit vs implicit, there should only be one way to do things, etc
12:00
Developer velocity vs runtime & compilation performance is not even in the same universe of hard to measure. Write something twice in different languages and follow the same algorithm/structure, the numbers often *do* extrapolate to larger projects very well becuase that general performance metric is all you care about.
You can even do a series of favored tests where you let one language lead with a natural implementation and the other language mimics, leading you to weaker but still signficant results.
Becuase if you care about latency you care about latency. If you care about throughput you care about throughput. And for whatever algorithm you've chosen it'll eventually be similar machine instructions being executed between the languages. Even TS, all those string manipulations just to get to a value? They'll eventually land you in a position where you can issue ADD on the values of a.['a'] and a.['b']. What those operations are are _extra_ work. Which by its very nature is slower. Sure, getting the average slowness of one language relative to another considering all possible problems and solutions (even weighted by popularity) is impossible. But getting a good estimate for expected performance is different.
With developer velocity you're practically into the social sciences. Every measure you can take that's objective is very indirect. Number of issues, commits, time taken on project to date vs checkmarks on the technical specificaiton. They suck becuase DV must account for the future with maintainence and an expanded scope. Various code/application quality measures like performance must also be accounted for. This lands it in the observational space, which has very little value objectively. Especially with the sample size of software projects. The moment you attempt to make any trial that's supposed to mimic the quality of your performance metrics you're into the millions in costs to run this experiment and you'll still have issues. So it's essentially just observational studies.
I don't understand how he came to his "uncanny valley" take. I've always thought that Go, even if it has its flaws/issues, had more of the "best of both worlds" when it came to performance and development speed. Its syntax and ease-of-use is akin to Python, but compiled Go often runs almost as fast as Rust, and usually faster than Java.
In University I took a total of 2 classes that involved the front end. A graphics class using js and an information systems class that happened to have a section on html/css web design. I did however take classes on operating systems, android programming, computer architecture, compilers, and others. I did however learn about multiprocessing, network protocols, how packets travel over http, vms, servers and other concepts that have been a huge benefit now that I've taught myself fullstack dev. It took a while after graduating but I did get there. Doing both university and bootcamp is probably best but is very expensive
I learned python, java, c, a little c++, the one course of javascript, SQL, Matlab, and MASM. Had virtually no programming experience before college
Why does Theo looks like the Go mascot?
😂😂
11:10 This is the real truth. Writing most of the code is easy. Just keeping the build working, tests running, dependencies working and ci/cd all happy in JS/TS land is like 90% of the work
A nil channel is not nil, it's the zero value, that's why it doesn't panic, it conforms to the channel API.
Compiling c++ but and you have dependencies but clang can't find them
about the non-UTF-8 filesystem thing, that is actually a real issue that Go does deal with, it uses WTF-8 internally to map those fake characters and deal with them properly. It's not fixed better by not doing it the Go way. UTF-8 as a default is still the better option.
Writing Typescript feels great at first but it gets worse every day you use it.
Go feels pretty bad to begin with but it feels better every day you use it.
Theos chart also seem very misleading while correct, TS should be way off to the right on runtime and go should be rigth next to TS in Dev. Vel.
Pure python will be massively faster in 3.13 due to the gil now being optional
The behaviour of nil channels (send or recv always blocking) is great for writing select loops where sometimes you need to turn off one of the select cases based on the current state. So for example if you don't currently have anything to send, you can set your dest channel to nil but still use the same loop, then when you have something to write you set that dest back to the real destination. If they worked differently the code to do the same thing is much more awkward.
Plus the recv from a closed channel always returning zero is extremely useful for signalling multiple listeners with one outgoing signal - it's how cancelling contexts (or stop channels) work.
As an IT guy, here's how projects manifest.
Can you just.
Then out of nowhere, you look into it, you create the simple thing, and the customer learns "What is possible" and now you're into Project Land.
Welcome to project land, where the simple scales both up and out, and the business waters the project like a plant with money.
One of the whackiest things that happened to me, was a "Simple request" which was 2 hours of work, pinned entire systems together and suddenly, I was the GO TO GUY for pinning systems together.
I really like programming in go. To me, I feel smart when I solve a complex problem in a simple way, not when I get to pull out some some obscure language feature
V may stand for Vaporware, but they're handling the nil/option thing pretty well: there is no null/nil, you can easily propagate the error instead of having a guard, and functions that can return an error just have a ! on their return type (so they need to be handled). Honestly my favorite error handling so far.
I really want V to be a thing.
Super agree with the boot camp take. I’m self taught and didn’t start to see the gaps in my knowledge until about 5 years in.
So if I wanted to do mobile dev, would you prefer learning two native languages or react-native?
For me, react-native has been really powerful and let's me "move fast" because all the logic and UI lives in one language and I don't have to set up bindings. This also lets other team members already experienced in js adopt the project much faster as long as they understand react
It’s an interesting topic for sure each each with the pros and cons. And all comes down to what you’re trying to achieve.
The main trade offs to frameworks like React Native is that you can lose out on the truly native look and feel. Flexbox is great, but it’s far less powerful than the constraint based layouts on Apple platforms. Platform differences in animations, gestures, navigation, and design language can also vary greatly and be difficult to write in a generic fashion.
This all leads to apps that look and feel the same on all the platform, with slight differences for simple stuff, rather than feeling truly native to their platform.
Your mileage may vary, but personally I prefer to reduce the number of leaky abstractions I use and just prefer to learn the underlying tech stack, which gives me much more control and runs less risk of platform changes breaking my app.
Rust has more dev vel than Type Script. I can program Rust faster than I've programmed in any prior language, even C which is my native lang.
You can still feel smart with Go if you start managing your own memory with sync.Pools and unsafe pointers
@7:55 Theo is a F.I. - Rust is being used to build compilers for your sloppy languages because it's Fast - DUH! I can't even watch the rest of this video with this fool...
Yeah, I know a few people that also dislike Go exactly because it makes them feel dumb or not smart enough because they can't create extreme abstractions and feel smart because they produce cryptic code instead of easily readable code and they can't stand the ideia of their code looking exactly like the code of 1000 other people while solving the same problem.
I am just laughing when the discussion pivots to build times as I am on a project where the discussion right now is about the build (and testing etc) taking 20 minutes. Every rebase takes 20 minutes. We now have to do a lot of work to change the build tool.
Also, I have no respect for Theo as I saw his video where he said testing is useless. I know controversial takes get more views, but come on? That's such a bad opinion.
I think he said that how testing is often done is useless (ie, testing every small detail), which i would agree.
Just test the hard stuff, and where you could have point of failures.
Python is not faster than JS. You can get C bindings in JS as well like in the case of the sharp library, it just isn't as common because V8 is pretty fast unlike python
Golang solves an important problem that most languages fail to solve... It solves my dumbness... Little learning I am good for a low level back-end developer 😎😀
I did a 6 months bootcamp (3 of which were an internship). Now, I am working on my degree, and I have to agree that it is helping me fill a lot of knowledge debt (we did not learn anything about memory management in bootcamp) that are making me a better dev in what I learned in the bootcamp.
I've seen like 5 Theo videos and can tell he is a mega grifter. I don't think he has the ability to form a useful opinion beyond "I don't like this because I am not familiar".
Yeah the dude absolutely sucks
That image at the beginning "Ranked by Speed"
Top: Yep
Mid: I can't speak to Go, but I've used Rust and Typescript for a decade each and I'd say I'm way faster in Rust. For example, I managed 10,000 lines of Rust last week. I've never managed 10,000 lines of TS in a week. And for context I worked for a company that had a 600,000 line TS codebase.
Bottom: Yep
Theo wants to say something good about Go, but he's to biased towards TS/JS, it makes him come off a demeaning. you can feel it in the video IMO.
If I remember correctly the main issue with rust compilation time, is that all of the packages also get compiled. So there’s no restoration of any precompiled packages like most languages do. Where they just toss the package binaries in output folder and that’s it. Rust has to recompile all of it, this results in a smaller output overall though as the parts of the libraries that aren’t being used can be trimmed.
I feel like most anyone who’s started programming in a traditional typed language and does some JS or TS for their front end when they need is going to be way slower is JS or TS whereas the reverse is not necessarily true.
27:45 yeah, C# is either ahead-of-time compiled to machine code, or compiled to bytecode and JIT'ed to machine code on first launch. It's gotten a lot better than the last time you used it. That said, it's still behind Go in both performance and simplicity.
I don’t see any measurable difference between c# and golang in terms of performance. Go is faster at startup because it is compiled to machine code, where c# is JIT compiled, but the JIT compiler optimizes execution based on usage which can result in faster execution.
Golang is much simpler than c# but whether that’s better or not is subjective. I like that c# is more feature rich, and it eliminates a lot of boiler plate that is common with go.
@@asherrfacee I'll defer because I've not ran my own tests, but all the conventional wisdom I'm aware of is that Go tends to be slightly ahead. But C# is very good (I'm a C# dev and prefer it over most other langs). I will say, though, that I do believe Golang is faster to onboard a new dev with than C#. But C# has the benefit of teaching you the .Net library which lets you pivot to F# or (and may the machine gods forgive me) Visual Basic (may it rest in peace /jk) later on.
this guy theo just vomits any uninformed oppinion as a way to create content
He has to vomit something to get views
I really dislike this diagram as it implies that rust as much faster than go as go is faster than ts. The x-axis isn’t to scale but if it were, it’d be clearer how much differences there are.
I think Go has faster dev speed than Python too. You might hit a typing bottleneck with python maybe at 2-3 thousand lines of code, and implementing mypy, and pyright is painful. Formatting with python isn't ideal with black, blue and others
The reason for uncanny valley is there can only be one top priority, and everything else is nice-to-have. Either performance is sacrificed for dev velocity or dev velocity is sacrificed for performance.
Doing some pet projects in Go rn. Even with proper error checking my velocity is surprisingly good. I've been using and loving Python since version 2.2.2 but now Go is becoming my favorite language.
I'd be interested in seeing new devs without previous exposure to programming try out different languages like Go, Python, C#, Gleem and JS. I think we often see the familiarity of the c-like syntax in Go as something that would make it good for beginners, since most of us probably started with something that looks like C, but that could easily just be our impression.
Python, Go and C# look like C
@@PR-cj8pd haskell and lisp then?
There should also be a metric on how many of them end up in in an asylum
I started trying to buck up and start building more things in go.
I'm very frustrsted because the more I use it the less I hate it.
Personally, feeling smart when programming has a high correlation with messing up. Because it means I'm in unknown territory. Have you ever talked to a very senior eng who's an expert at something? They sure sound smart but they don't _feel_ smart themselves. They've been doing the stuff forever, it's just boring routine.
I would agree with Prime that familiarity is the key factor for velocity but that also means GO wins by default since it takes exponentially longer to be good with TS and GO considering you CANNOT get good with TS without having a solid understanding of JS and the the frameworks and underlying HTML it works with.
I like to see wanting to feel smart in coding as your brain asking you to work on improving “the resolution” of your thinking. It boils down to slowing down and to explore the problem. If you are smart you are naturally drawn to that. The activity is just something someone else would not benefit from.
I'm writing a little go webapp and found that I generally use pointers like a `Ref` type (for mutation & performance) but don't want them as `Option`s. In Rust, `Box` and `Option` are separate, but nullable pointers force them into a single type, so I can't easily enforce "never null` fields.
I'm sorry, but x.(interface {}).(*Something) is the horribleness that arises from go's type system. And calling footguns skill issues (34:00) means that JS is not a bad language and just hard to learn...
ignoring that 'velocity' is literally the worst concept to ever be applied to software engineering, typescript only wins in the sense that its the fastest to get something "working" with the heaviest of emphasis on the quotes. Source: I write 98% server side typescript at work :(.
Go enables multithreading without requiring developers to intentionally write multithreaded code or use async/await mechanisms. It addresses scaling effortlessly, unlike any other language that does this so naturally.
11:26 This is so true. Been working on big TS projects the pattern is always the same.
You have bunch of services. Then the CI pipelines fails hard. No need to actually write your own tools in order to ship the whole app in reasonable time.
The TS build system suck ballz
Developer velocity is WAY faster in Go practically in everything.
Really? Why do I suck at it so much. How do you guys learn this language so efficiently. Are you forcing yourself to use it in a job?
@@gadgetboyplaysmc I am not forcing myself to use it. I am pretty proficient in C, C++, C#, Python, ADA, and I just find myself using it in certain circumstances. Honestly it just seems intuitive to me. I do not have a computer science degree (chemistry actually) but I find it insanely simple to work in.
- statically typed compiled language - check;
- no oop nonsense - check;
- weird error handling, but hey at least it's not exceptions - check.
These 3 things put Go in top 1% of programming languages.
@@youtubeenjoyer1743 you forgot to put the standard library; if not, then C would be one of the candidate for the dev velocity hahaha
On the boot camp talk I think you’re exactly right. I self-boot camped, got a job, and then didn’t really do continuing education outside of the job.
I’ve recently jumped back on the education train to learning all the underlying stuff (and enjoying boot.dev…not cheap but it’s definitely worth its cost. Particularly with a discount code.)
And I feel myself getting so much better at my job just because I know the base reason behind things.
The thing I put up as the indicator for ease of use in a language: How hard is it to write an HTTP request exclusively using built-ins? Rust makes it a little tricky because you need to resolve the name for an address before opening a connection and such, while Go makes it in a single call. But TypeScript, you might be able to use fetch, but in Node.js the standard way to build a request is to use 6 callback functions as event listeners and if you want to return the response back to the top-level and await it, now you also need to implement a Promise constructor, and pass the resolver into the response's "end" event, while binding the rejecter to the request's "error" event. Oh, and don't forget that a request body needs to be converted to a byte array or a string, and passed to the Request.prototype.write method as inherited from stream.Writable.
I use Node.js on a daily basis, but the standard library can be frustrating to deal with. I long for a language like Go that is more feature rich in the standard library
not every programming language is for building crud apps brother. Your indicator is flawed from the get go.
I think many compiled garbage collected languages can fit into the middle (c#, java, clojure, elixir, etc)
I like to have a tool that works for my particular experience and skills.
Like a nice grand piano.
It might be the case that my piano is different from somebody with 7 years of playing.
I hope that would not be construed as “wanting to feeling smart.”
21:15 I love writing C++ probably cause I like pain...err challenges I mean. But I understand the love for C it's a much simpler and straight forward language compared to C++. But C++ got all those bells and whistles you know more things to slap you in the face with when things go horribly wrong.
this video and the points in it sums up my reluctance to use rust. so much of rust is about rust and not what is being built. i’m having to use it for LibAFL right now and I think it’s a really, really bad use case/misapplication of rust.
for applications like a fuzzer, i want to often directly manipulate memory in an unsafe way… why use a language designed to guard against that?