After all of ThePrimeagen content I've watched, turns out this is my favorite format. I always want to make more time to read content like this anyway. Getting it in this format with your commentary is gold
He has the ability to speak to you on the same level as the author or article without apologies. If some of the concepts elude you (sometimes I'm not at the complete level of understanding on the particular topic) he says "hang on we're going full throttle anyways". At no time do I feel it is rude or obnoxious. I don't feel like it steals from the author. It's like hanging out in the next cubicle with him and that's a great feeling.
I think Golang is the next best language for your team if you're moving from a dynamic language, if you use py, ruby, js or any other dynamic language in the backend. try golang, we started using it to run our backend daemons with redis and MySQL, trust me. since we moved from long running processes in PHP, and legacy Java to go... the rest of the team has been calm and anyone is able to troubleshoot problems, over the past year. I feel like we've been so productive with go, even with our new developers, straight from Uni are able to understand production code and be able to contribute significantly to the team. i love go, and am the project manager. so get on with it team
Go has a special place in my heart. I spent some time to get on the Rust train but in the end, when I need to get something done quickly, with a fairly decent performance... Go is the language I pick everytime, it's so easy and fun to write.
This type of video is your peak-youtube-content to me. I am too adhd to get through full articles on my own and *actually* consider their implications, I need some way to actively engage with them and I dont have people around who are into this stuff. When you read the articles and think about them out loud my brain starts to engage as well and I actually pull up passages to re-read and think about them myself. Thanks buddy, you make learning fun for me!
Typescript is basically like trying to polish a turd, failing miserably, and then covering up the turd with a convincing image of a clean floor for someone to step in later.
Exactly. Generics were necessary for built in collections but for a long time off limits to everyone else. Golang is ridiculously verbose for these use cases.
Prime, I often have this kind of stuff on a second screen, people that read and react to news/articles are just screen readers for all of us, but you my dude, you ad so much to the already juicy article that I find myself pausing the game and just listening to you my fella. Thank you for this amazing work, cheers.
After a LONG time trying to learn go I was moved into a position at worked where I NEED to learn Go and I'm so excited. This video arrived just in time for me
The argument against generics is a strange one. My love of generics in other languages has little (nothing?) to do with inheritance or subclassing. I want my data structures to be strongly typed; that's all. I want to be able to create a ConcurrentRingBuffer or whatever. Go didn't let me do that. I also just don't understand this arrogance. (Yes, it's arrogance.) The language creators kept the power of generics for themselves. Go has generic arrays, maps, and channels. If generics are so terrible, why not return to the Java 1.0 days where arrays and maps just use Object for everything? OBVIOUSLY, strong typing is a good thing.
I'd rather a language creator is arrogant and sticks to a vision and design philosophy, than for a language to throw in every feature ever. You wanted strongly typed generics? C++ is right there for you.
> The argument against generics is a strange one. It's because it isn't one. I didn't notice a single thing to do with generics in that section of the article. It was 100% an argument against inheritance, which was not what was asked about. The word 'strawman' springs to mind-or, more charitably, 'misunderstanding'. Of course, if I go with the charitable interpretation I conclude that Go is designed by people who don't know the difference between inheritance and generics.
Just as an aside, the original pager on Unix was pg. But then someone wrote "more" - named because of its UI where it prints "More" at the bottom of the screen. But you couldn't go backwards on pipes. So someone wrote "less" that could do that - named because less is more.
I don't agree, adding atomics to C++ (and the memory model in general) is the best decision ever made by C++ committee. This solved so much broken code and allowed us to write code that is portable on x86_64 and arm platforms.
Quick question - what was the big problem with porting before atomics? Asking because the Linux kernel is written in C and is by far the most ported project ever.
@@EmiNNsoNifyConcurrency primitives in the Linux kernel are not portable by definition. If you try to use them in some other project it won't work because they rely on specific compiler flags and/or make assumptions about the kernel environment which may not be the same for other projects. Also before introduction of the memory model a lot of gcc optimization passes broke and miscompiled the concurrent code. Because without a memory model it's not possible to answer if a specific optimization (which could be perfectly fine for a single threaded code) is not valid when executed concurrently from another thread.
@vadzimdambrouski5211 @bbourbaki Okay, fair points! My point was more on the "Linux kernel is massive project which is in C and you don't see them yearning for atomics." Should have been more explicit.
yep, there's a reason why Rust took it practically as-is. I also disagree with that take on atomics (although they are certainly not the easiest part to grok)
My dad was a developer when C++ first came out. It was a transpiler at the time, it converted C++ to C then you compiled that. He remembers thinking it was a good idea at the time. But, it never evolved into what it could have been. It lacked standards such as an object model, libraries, etc. Java would come along and fix issues like these but at the cost of having to use a JVM with an interpreted language. C++ has too many traps and pitfalls and makes you have to program defensively.
You need to test modern C++. The language has really changed. Most error prone stuff have disappear. It still requires some discipline with beginner, but when you are used to it, memory issue become very rare. With the invention of RAII, managing ressources (not juste memory, but connection, file, etc...) is easier than Java/Python. With the notion of rvalue, you have the notion of move instead of copy which avoid putting pointer/reference everywhere like Java and Python do by default. Now every life cycle is related to the stack and thus automatically freed by compiler at correct time. Lambda makes easier to write functor and functional code. Constexpr enables adding logics and interface at compile time instead of doing virtual polymorphism. And all the nice addition like std::variant (a easy to use sum type), std::tuple, std::optional to better represent data instead of horrible void* or Java everything is an Object. Still Rust refined those ideas and does even better. For example, due to backward compatibility, C++ is copy by default. While Rust is move by default, which enables to hide the l-value/r-value concept most of the time. Rust is const by default, C++ needs to have const everywhere. And Rust has lifecycle check which is very useful to avoid multi-thread issue and dangling reference. Even if modern C++ has less and less memory issue, it can still happen when beginner code like Java in C++. Rust completely avoid that by throwing a compilation error. And the memory model of Rust is far better than C++ unchecked exception or Java checked exception because it is directly using the return value. It becomes very easy to combine with functional code.
@@isodoubIet No, that's a biased take. The point of any language should be to increase productivity - not to raise artificial competitive barriers to entry that increase YOUR relative pay grade because it shuts out other humans from being productive due to a high learning curve. THAT is the truth.
@@lashlarue7924 Who said anything about "artificial competitive barriers"? C++ is a language that lets you be extraordinarily productive. Complaining about "pitfalls" that are mostly very easy to learn and avoid is a skill issue, sorry to say.
go for me as a javascript /python programer is like my savior i dont give a damn about memory management (we deal with backend services here not developping an operating system )as long as i can ship my code faster with less bugs and more readable for my team i'm happy in short go for us GETS THE JOB DONE .
Memory management is pretty important when talking about performance And just because a language has a GC doesn't mean that you can completely forget about memory management
Ah so you throw hardware at the problem ;) You absolutely need to handle memory in GC languages, I.e. through object pooling, especially in something like a web server with concurrency, I.e. one of go’s primary applications.
@@hamm8934 if i want to go through that may well just code with Rust and frankly in the end of the day the gain is insignificant besides i want a finished working web app not a school project that may or may not be finished the next year
19:56 My more generic feeling about this is: *No classification changes what things are.* And my politics would be: *Qualify rather than classify.* If it quacks like a duck, walks like a duck, and flies like a duck, maybe it's *still not* a duck, but maybe *we don't care* because all we need to know is *it can do it.* All we actually need is to assert that the thing *comply* with a bunch of criteria. Now, before you invent more types than in _Rust_ , remember the number $n$ of types you can make with $c$ independent criteria is $n=2^c$. This is already *too much* to pre-define in a programming language syntax. And also, keep in mind that, inside the binary machine, the only actual type is *positive integer* . *Any other type is simulated* by tagging some positive integer with purely *arbitrary* meaning.
Everytime i hear about something the primeagen is doing at his job, i get a little envious at how interesting it sounds lol. I haven't done anything nearly that fun at my job...
i said node, and claiming another thing all togethre doesn't some how make node in one tool you require a reordering of the javascript ecosystem to be deno.
@@_____caseNodeJS will never correct the fundamental issue of JavaScript’s type system. That’s a language design problem and language design problems can only be solved my making a better language design not by micro-optimizations with intermediary tools.
chat never fails to be in either completely sync with prime or completely out of sync with prime. He's tryna read something seriously and chat just makes fun and vice versa. Such a good channel btw.
Would love a course and deep dive on Javascript workers/threads/async etc... When and how to use worker threads, use cases with efficient practical algos that we'd use in the wild to make javascript performant in certain situations. There's definitely a market for a course like this.
i want to change to that direction. like Rust is very interesting with all the features, it's like finding yourself in a baggage claim conveyors in airport but all sorts of japanese vending machines come from the belt instead of luggage. it's all interesting and nice to learn but also confusing and complicated. especially with my lack of expertise. perhaps it's more effective to learn it after more programming experience. i went back to C to smell the machine a bit more and solidify the basics. honestly go sounds more and more compelling, especially if it's that easy to learn. it's probably better to work on the languages i know for now but maybe like next year i'll slowly learn Go
I really loved that talk. Thanks, Prime, for reading that. I'm learning Go, and that helped put a few things in context. Go is so so soooo much better than TS (current work code base).
I would love to hear a detailed rant on the over expressiveness of Typescript. I'm a JS/GO dev and I know the benefits of a type system but I absolutely HATE typescript and have a hard time explaining why. I thought it was originally because I hated typed languages but I love GO. It is specifically TS.
TS is nice if you use it right, but that's the problem, you can use it bad in too many ways :). Also if you think TS from a C++/Go/Rust perspective, you miss the point of the language.
@@beastofthenumber6764 not is not, is nothing like Java, maybe if you only use interfaces?. If you use interfaces for TS, you're using it wrong again. And you go back to my previous comment, too many ways of using it wrong.
@@oscarljimenez5717 i agree they can be used better, but the "wrong" way is the intended or at least the more promoted way. Even in java you can construct classes in ways that are better but almost nobody does.
is his argument really against haskell/rust? he seems to talk mostly about type hierarchies, in the sense of classes/superclasses/subclasses… maybe it could be said that of typeclasses and traits, but, not really… types, at least in haskell, don’t have any “hierarchy” in the sense that he seems to talk about.
if anything, go is more similar (in spirit) to haskell and rust, since he talks about what makes it different is the compositional nature of interface methods
Three computer science articles, ever, stand on top for me: Ken's "Reflections on Trusting Trust", Hoare's "Emperor's Old Clothes" and this "Less is exponentially more".
Understanding something is not always breaking down into smaller and smaller parts. While you are reducing the subject you are increasing losing context. To really understand the world more you would find patterns and similarities and not fracture your understanding of the world
I worked at a company that used Go while I was getting my undergrad. Having graduated and spent almost as much time in industry as I did getting my degree I think I need to revisit Go. Java was my undergrad, and it's much of what I do at my current job, but I'm starting to see it's many issues (not sure how many of the issues in my current project stem from the fact that I'm the most experienced dev on my team though)
I don't know that procedural programming is strictly more natural than functional, though some things are naturally sequential in nature and therefore procedural fits better for those. I think it really is an exposure thing, the classic example being to ask students how to make a peanut butter and jelly sandwich.
this is a great thing to watch, but its not a great argument. recursive thinking is definitely not a natural format, procedural is something we do with a _LOT_ of brain filling in the gaps
@@ThePrimeTimeagenThis is an apples-to-oranges comparison. Strict FP may require recursion, but most functional code out there doesn't explicitly use it (preferring higher level abstractions like map/fold/reduce/etc instead). To make it a fair comparison, you'd have to compare strict functional code with strict procedural code, which would look more like assembly and preclude much of the common usage of functions found even in a language like C. And obviously, even the strictest functional code still has elements of procedural style in the way function calls are arranged and executed sequentially (though Haskell does complicate that a bit more with it's laziness). Point being: the whole Functional vs Procedural thing is just a poor dichotomy all around. You can't really produce good code with just one or the other, because they never existed in mutually exclusive vacuums to begin with. Good code is eventually going to rely on both styles where appropriate. However, functional style building blocks do become more useful the higher up you go on the abstraction ladder. And I don't mean pointless java-style "abstractions", but rather layers in a properly segmented cake-like architecture, more like the abstraction that occurs when going from ASM -> C -> Python (ie. stratified design). Procedural methods become more limiting the further up you go in abstraction because they were designed to work with lower-level primitive values. Thus when you try to make higher level abstractions work procedurally, you're forced to expose a lot more internal implementation details to enable working with them, which means leaky abstractions, more cognitive overhead for the developer, and prevents the formation of properly stratified layers. You might think to yourself "That's absurd. I code procedurally all the time and can still separate everything well with good API boundaries". But if you look at the situation closer, you'll notice that the entire concept of an API boundary is actually more functional than procedural, because you're asking the API to do something for you as opposed to telling it how to do it (ie. a function call as opposed to a GOTO). Which goes back to my original point about there not being any actual hard-and-fast separation between the two.
There's always the argument of whether the goal justifies the means, but so far Go seems to tackle both with its great performance. Rust can do the same, if you grind enough to get used to it
My problem with GoLang has always been the insular design of it. After it got some traction there were a lot of (poor) comparisons of GoLang and Erlang from, IMO, people rather ignorant of one or the other language. After a while I recall some of the Erlang communities' criticisms of Go's designs got back to core architects. The issue, from the Erlang folks, was ... why goroutines? Over the past 40 years there had been a lot of research into concurrency models and a fancier coroutine mechanism built into the language was better than nothing but Erlang and other languages / libraries had really powerful concurrency models that seemed to be entirely ignored in GoLang's design. And as I recall the response was kinda like: "we didn't look into the topic. :shrug:" I don't like that at all. In an age when concurrency is more important to make easier than any time in history and you spent time to design a language with concurrency built in... kinda important to do your homework. no? Erlang isn't perfect but when it comes to concurrency and general simplicity I absolutely adore it. You can understand the whole language without much effort. Worrying about contention rather than how to create the concurrency in the first place is truly game changing and I've never built distributed services more easily. Add in a fast built in serialization/marshaling library and simple technique for handling out of VM IPC... it is just a pleasure working with. I wish other languages took more of the Erlang communities' ideas. And I wish GoLang would have had actors instead of coroutines. You have languages like Pony that tried to go in an actor like direction but didn't get much traction.
Just saw @17:20 "Go's concurrency model might be the best ever." Can't agree even a little. It's not bad but actor systems, and proper scaffolding (like Erlang's supervisor module), are so much better for wide scale concurrency.
@@spell105 "No one cares..." Checks major apps used across the OSS world written in Erlang as are critical apps in multiple fields ... Yes, no one cares. Elixir is not all that much more than a syntax change. The fundamentals of Elixir are the same as Erlang. They run on the same VM. They have the same actor model because the VM is purpose built for concurrency. For Erlang. Elixir never would have existed had it not been for BEAM VM and the fundamental designs built into necessary to accomplish what it sets out to accomplish. It is why other platforms can't do the kind of concurrency models Erlang has. Why the Java Erlang implementation failed. If you want to be able to create fundamentally different patterns you have to often do fundamentally different things. And even when they fail to catch on they can provide a lot of value to others. So feel free to ignore alternative technologies but you aren't gaining anything from the ignorance.
and on the technical debt of types? Yes. The closer a type system gets to turing completeness, the more expressive it is necessarily. But if your type system is subject to the halting problem, there are now some perflectly valid types you can express that no compiler can compute.
It’s not a surprise to me that Go isn’t a replacement for C and C++. A language with GC is not a systems programming language. We still need a good replacement for C. I’m rooting for Zig to become that.
Bro you must be a complete genius. Most people who speak English would only understand about 20% of what this guy says. I'm an Ivy League graduate who has never scored blow 99% on any single standardized "verbal" English test (truth!), and I only understand maybe 75% of the engineering context despite being a relatively intelligent nerd with all the capacity to be this man's peer; I often understand English words that Primeagen does not, and I do enjoy watching him struggle, because I am a bad person (and because he is an infinitely better engineer than I am). So, if you're able to learn English by watching this guy, you're a Gigachad. Bigups to you.
@@KadenCartwright Welp boys, we have our first JavaScript programmer. I'm sorry that your programming career is limited to the lack of brain matter in your head. I learned Python at the age of 11 and JavaScript at the age of 13. The language has it's uses, but people who make a career out of just JavaScript (other than frontend people, they don't have a choice) clearly have the intelligence of a 13 year old.
@@Manja500 You know you really don't need to validate your existence by putting down others for choices they most likely didn't make? I know and have used many languages both in side projects and production code, you learn to take something valuable from all of them. Would you say someone like Rich Harris has the intelligence of a 13 year old? Or a myriad of devs working on hundreds, if not thousands, of apps that service millions of people using JS are also comparable to 13 year old? Do you think software like Slack, Discord, Chrome to some degree, the app where you're reading this very comment are products of a bunch of dumdums? A senior level, or even mid level, JS programmer would be perfectly capable of coding in most languages given some time - problem solving skills are not tied to the language after all.
The article and the Take basically nailed it. If you're a Python dev and you just want to increase your speed a bit without having to completely worry about too many leg cannons, why would you bother to learn C++? It's the same reason some other large platforms (which shall remain nameless) don't get adopted - you have to devote your entire existence to learning that tool. I don't even need a better tool than Python at this point for what I do; the need simply doesn't exist in my world and it never will. But if you devoted your entire existence to learning how to write clever code that manages memory directly, why would you ever want to give that up? Of course you wouldn't! Time will tell.
The taxonomy bit always sticks in my head, but it's only *almost* correct. MANUALLY CONSTRUCTED type hierarchies are taxonomy, but an implicit immutable type hierarchy could be useful
I've been looking for a back end language to learn now that I'm sure I don't want to do full stack development. I'm starting with JS because there's more resources out there but I'm planning to jump to Go once I got an idea of what I'm doing
some golang "features": * no immutability qualifiers (const/final/readonly) * verbose and error prone error handling * terrible time package * no stack traces in errors * zero types are error prone * no default interface function implementation * generics are very weak * structural typing is a hack, and an annoyance in large code bases and many more
Can someone possibly refer me to a Prime video where he explains his disdain for Uncle Bob in detail? I have my own qualms with the man, but I'm interested to understand Prime's take on the issue.
Functional != recursion Recursion is a valuable tool for procedural programs. I learned it very early on and I think more people should as I think it’s easier to learn initially before your mental model starts to harden…
Yeah. My understanding is that it was developed to replace Google's use of C++, which, due to the scale they operate at, is more like what other people tend to use Python and JS for.
I've been using Python to build proofs-of-concept for several years now. I learned Go this month and have been able to do some incredible things in it already; I can safely say that it is my new go-to language for anything that doesn't require GUIs, and I plan to build some GUI applications with Qt to see if it can become my go-to language for GUI apps as well. Also, curse C++, we hates it. Nasty C-pluses ruins the code.
@@ssokolow I don't understand why JS and Python would be the correct language for Google use of C++. C++ is for long term software when you know exactly the concepts and want to write them in the code. Thus the compiler can do the check for you and catch most errors. the goal is to be correct by construction. Changing becomes slower when writing code but faster in validating it. Because most issues are found with the type system. it also brings performance and memory predictability, good when you want to industrialize your software by consuming less ressources. JS/Python enables writing incorrect code without any warning but a crash in production. And their VM makes it unpredictable and not efficient in term of performance and memory. Thus it is better to do POC and try stuff when everything is blurry. Or to write quickly disposable script to manage existing library/software. But if you build huge program with it, you will just con your clients with many support case for runtime errors.
Yeah. Ruby was the rust of my generation. back when people in the indie-lang space thought there was a right way to do OOP. I imagine we will eventually arrive at a similar situation for rust things where we are like "Yeah that was an embarassingly long and windy dead end."
I never looked closely before into go and it's syntax. and after watching video I wondered how it is possible that it has no generics but is strongly typed lang. I checked and found that it has in fact "map[keyType]valueType" that is look to me as built-in generic. and makes me think it has no way to define custom generics but has built-in ones
Welter weight languages are underrated and overpowered. Free variables are all you need for calculus; not limits or epsilon delta. The simpler the syntax, the simpler the re writes.
"Go has this python esque feeling to it" lmao, you could literally only be referring to the no-semicolons. Go absolutely doesn't feel like python at all.
Go really just needs a couple of tiny tweaks to become THE language to use for anything in between the frontend shenanigans and OS&kernel. Already started pivoting slowly into it as a dotnet/node fullstack microservices merchant
@@devnexen I doubt it will ever get into that area fully, thats why I said it's starting to look like a great language for everything not frontend or super low level stuff like OS. That being said and to answer your question it would require GO to have no garbage collection at all in order to be used for it. Thats why C and C++ were kings for the past 40 years of OS development, and languages like Rust and Zig are the candidates to go in there
Came from a Java and C# enterprise world, used some Python for side stuff. Now I really feel like Go can give me the performance and type safety I miss from Java and C# but with some of the simplicity Python made me appreciate
English speakers typically say /DEH-zih-de-RAH-tah/; it's from Latin, meaning "wanted things". Based on HN responses to comments about C++'s complexity, C++ devotees typically respond with "C++ isn't too complex; you're just not good enough to handle C++", so I'm not surprised C++ programmers wouldn't switch to Go.
I wish go had opinionated feature-rich web framework. Instead here I am, working on a project where I have to freaking write auth system wtf. Coming from aspnet core this is pain....
@@d_6963 Haskell. And it‘s not like we were a bad year. We had a 86% average on the math classes the same year. We just had little to no experience programming and understanding how one can manipulate data and control flow.
@@lucky_luke4785 Interesting perspective. Lots of Haskell evangelists claim Haskell _seems_ hard because we're all just ossified boomers whose brains have been so deformed by years of coding procedurally that we can't imagine how to do things another way, and that if only we'd learned Haskell first it would be procedural code that would seem hard instead. I always thought this was obvious BS but it's nice to have some evidence that newbs will find Haskell confusing too.
While watching the video (2:30 to be precise), something about IP addresses just hit me like a truck full of bricks: CS Research Center at Bell hat the internal number 127. What are the first three digits of localhost? Yep.
13:29 why would that be surprising? what did you expect to happen and why? I bet you can't figure out better semantics without introducing a separate int type
As somebody said... *Go is built for grug brained programmers* (like me). Or saying differently: *Go is for old, grumpy man* who grew up in 80-90 on their old Atari, Commodore or ZX spectrum.
Go is extremely unsafe. You can access nil pointer everywhere, nobody is going to warn you, you can partially initializw your structs and forget some fields. Just horrible.
Implicit casting 32 to 64 is all fun and games, until you're working with an in house serializer and suddenly can't figure out why the client is getting errors trying to deserialize
14:26 "Methods are just function": how *ironic* . 'cause in fact, it's the very exact opposite: all so-badly-called "functions" people continue to call "functions" in almost all languages *are methods* , not pure functions in the mathematical sense.
Whait, I know it's an old comment, but how are functions in programming languages not functions in the mathematical sense? A Mathematical function just maps each element of the domain to a exactly one element of the codomain. How is that not what programming functions do? Do you mean the possibility of errors makes them not functions?
Very odd that there was just about 0 pushback on the statement "Go's claim is that minimizing programmer effort is a more important consideration," considering the fact that Prime regularly says DX isn't a thing. That's literally DX in more words.
i say that modern dx is the definition of "i am familiar with this approach" that on the other hand is the summation of the post claiming to pair down features into the minimum amount to make it the most effective. i can agree with that statement / little argue because of the totality of the article and my knowledge of go
Just so you guys know a little piece of ultra nerdy trivia: desiderata (from the italian, meaning "those who are desired") appears in another article that Rob Pike wrote about how UTF-8 was created by him and Ken Thompson.
Wait, you understand Rust borrowing system, but you don't understand rvalue references? The borrow checker is exactly the same as rvalue reference but with the compiler making sure you are doing it right
@@elcugo rvalue references make perfect sense apart from the fact that value categories are distinct from types and you can have an lvalue of type rvalue reference and vice versa. That is the single most confusing aspect of the whole thing. Conceptually though, it's actually pretty simple, it's an rvalue because it's the sort of thing that goes on the right hand side of an assignment, which is 'just' a way to detect when references point to temporaries.
@@isodoubIet I know what rvalue references are, but the explanation just gave sounds like technobable to anyone that isn't already entrenched into C++. Thinking about a better name I came out with "ownership transferring references" which isn't a great name especially since it isn't accurate because moves may or may not happen.
@@elcugo The problem with other more descriptive names is they lose accuracy. Maybe that particular ship sailed with std::move but an rvalue, to me, doesn't imply ownership will be transferred. It just means I shouldn't rely on the object living past the semicolon. I will never understand the lvalue - glvalue vs prvalue - rvalue dichotomy though. Seems pretty silly and inconsistent.
I think the answer is simpler than that. While trying to sell a new language to C++ programmers, the moment you pronounce the words "garbage collector" or "no RAII", you've pretty much lost 90% of them already.
Am I crazy or cant there just be a lang that does it all? interpreted, compiled, types, no types, etc and just have the programmers that use it choose how to use it
Never used Go, but I really don't like the implicit interfaces. That's almost like dynamic typing where you don't know what a certain type implements and when the interface changes how would tools help you with the refactor? Also generics are a must in any language that is higher level than C (which I see as high-level assembly).
C++ and Java programmers have long moved on from type hierarchies, stop inventing straw men. C++ has embraced composition over inheritance 12 years ago before it was the cool thing, and even Java programmers know inheritance causes headaches, with Spring moving to remove most forms of inheritance from its code, preferring interfaces where possible.
I know templates are terrible designed in C++, but the idea behind metaprogramming is good per se for me. Maybe generic as Java and Rust are just enough.
This. The point of a type system with generics is that static type systems may not give you more expressiveness than a dynamically typed language, but if you don't include generics they can definitely reduce expressiveness a lot. It isn't so much about taxonomy as just making many functions impossible to write.
If we were to understand the fundamental nature of things better, more things would be obvious and less things would need to be actively researched, hence less departments
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
After all of ThePrimeagen content I've watched, turns out this is my favorite format. I always want to make more time to read content like this anyway. Getting it in this format with your commentary is gold
He has (and voices) the obvious thoughts so I don't have to
He has the ability to speak to you on the same level as the author or article without apologies. If some of the concepts elude you (sometimes I'm not at the complete level of understanding on the particular topic) he says "hang on we're going full throttle anyways".
At no time do I feel it is rude or obnoxious. I don't feel like it steals from the author. It's like hanging out in the next cubicle with him and that's a great feeling.
Brilliant!
Same here 💯
"Perfection isn't achieved when there's nothing left to add, but when there's nothing left to remove."
Your content is getting better and better. I loved this particular video and the Rich Harris ones so far.
I think Golang is the next best language for your team if you're moving from a dynamic language, if you use py, ruby, js or any other dynamic language in the backend. try golang, we started using it to run our backend daemons with redis and MySQL, trust me. since we moved from long running processes in PHP, and legacy Java to go... the rest of the team has been calm and anyone is able to troubleshoot problems, over the past year. I feel like we've been so productive with go, even with our new developers, straight from Uni are able to understand production code and be able to contribute significantly to the team.
i love go, and am the project manager. so get on with it team
Go has a special place in my heart. I spent some time to get on the Rust train but in the end, when I need to get something done quickly, with a fairly decent performance... Go is the language I pick everytime, it's so easy and fun to write.
I agree with this, same for me
Every time I read/listen to stuff about Go I gain more respect for it. It's very quickly becoming my favorite language to write in.
I only understand around 20% of the articles Primeagen reads, but I still find it fascinating
:)
Remembering what you don't know will make you learn it better down the road
@@alexandersemionov5790 I honestly believe this.
This type of video is your peak-youtube-content to me. I am too adhd to get through full articles on my own and *actually* consider their implications, I need some way to actively engage with them and I dont have people around who are into this stuff. When you read the articles and think about them out loud my brain starts to engage as well and I actually pull up passages to re-read and think about them myself. Thanks buddy, you make learning fun for me!
Snap, well put
That "Ken" is Ken Thompson. The guy who wrote UNIX, B (which is the predecessor to C) and grep.
Go is like 30 amazing ideas to create the perfect language, and then like 2 bad ideas that make me absolutely hate using it, lol.
Which features? I hate capital letters for exports
@@hamm8934mplicit interfaces just rub me wrong, also codegen required to fill in gaps
@@minciNashu Implicit interfaces are awesome.
@@hamm8934error handling
What features are those?
Typescript is basically like trying to polish a turd, failing miserably, and then covering up the turd with a convincing image of a clean floor for someone to step in later.
polish a turd lmaoooo
I think that the python software foundation is in the "more feature" train right now.
Rob "who would ever use map() and filter() instead of _for_ loops" Pike retired a few months before Go got generics. Coincidence?
Exactly. Generics were necessary for built in collections but for a long time off limits to everyone else. Golang is ridiculously verbose for these use cases.
That last paragraph is truly baffling. What does he think abstractions are for if not to reduce programmer effort?
Everyday i love more Go lang, there is a lot of good stuffs. I want know MORE MORE MORE
Prime, I often have this kind of stuff on a second screen, people that read and react to news/articles are just screen readers for all of us, but you my dude, you ad so much to the already juicy article that I find myself pausing the game and just listening to you my fella. Thank you for this amazing work, cheers.
After a LONG time trying to learn go I was moved into a position at worked where I NEED to learn Go and I'm so excited. This video arrived just in time for me
"Features will continue until productivity improves."
Go was touted as a "systems" language back then. Very few agreed because... gc.
The argument against generics is a strange one. My love of generics in other languages has little (nothing?) to do with inheritance or subclassing. I want my data structures to be strongly typed; that's all. I want to be able to create a ConcurrentRingBuffer or whatever. Go didn't let me do that.
I also just don't understand this arrogance. (Yes, it's arrogance.) The language creators kept the power of generics for themselves. Go has generic arrays, maps, and channels. If generics are so terrible, why not return to the Java 1.0 days where arrays and maps just use Object for everything? OBVIOUSLY, strong typing is a good thing.
I'd rather a language creator is arrogant and sticks to a vision and design philosophy, than for a language to throw in every feature ever. You wanted strongly typed generics? C++ is right there for you.
> The argument against generics is a strange one.
It's because it isn't one. I didn't notice a single thing to do with generics in that section of the article. It was 100% an argument against inheritance, which was not what was asked about.
The word 'strawman' springs to mind-or, more charitably, 'misunderstanding'.
Of course, if I go with the charitable interpretation I conclude that Go is designed by people who don't know the difference between inheritance and generics.
Just as an aside, the original pager on Unix was pg. But then someone wrote "more" - named because of its UI where it prints "More" at the bottom of the screen. But you couldn't go backwards on pipes. So someone wrote "less" that could do that - named because less is more.
Theprimeagen is slowly converting to a gopher
I don't agree, adding atomics to C++ (and the memory model in general) is the best decision ever made by C++ committee. This solved so much broken code and allowed us to write code that is portable on x86_64 and arm platforms.
Quick question - what was the big problem with porting before atomics? Asking because the Linux kernel is written in C and is by far the most ported project ever.
@@EmiNNsoNifyConcurrency primitives in the Linux kernel are not portable by definition. If you try to use them in some other project it won't work because they rely on specific compiler flags and/or make assumptions about the kernel environment which may not be the same for other projects.
Also before introduction of the memory model a lot of gcc optimization passes broke and miscompiled the concurrent code. Because without a memory model it's not possible to answer if a specific optimization (which could be perfectly fine for a single threaded code) is not valid when executed concurrently from another thread.
@vadzimdambrouski5211 @bbourbaki Okay, fair points! My point was more on the "Linux kernel is massive project which is in C and you don't see them yearning for atomics." Should have been more explicit.
yep, there's a reason why Rust took it practically as-is. I also disagree with that take on atomics (although they are certainly not the easiest part to grok)
My dad was a developer when C++ first came out. It was a transpiler at the time, it converted C++ to C then you compiled that. He remembers thinking it was a good idea at the time. But, it never evolved into what it could have been. It lacked standards such as an object model, libraries, etc. Java would come along and fix issues like these but at the cost of having to use a JVM with an interpreted language. C++ has too many traps and pitfalls and makes you have to program defensively.
skill issue honestly
You need to test modern C++. The language has really changed. Most error prone stuff have disappear. It still requires some discipline with beginner, but when you are used to it, memory issue become very rare.
With the invention of RAII, managing ressources (not juste memory, but connection, file, etc...) is easier than Java/Python.
With the notion of rvalue, you have the notion of move instead of copy which avoid putting pointer/reference everywhere like Java and Python do by default.
Now every life cycle is related to the stack and thus automatically freed by compiler at correct time.
Lambda makes easier to write functor and functional code.
Constexpr enables adding logics and interface at compile time instead of doing virtual polymorphism.
And all the nice addition like std::variant (a easy to use sum type), std::tuple, std::optional to better represent data instead of horrible void* or Java everything is an Object.
Still Rust refined those ideas and does even better.
For example, due to backward compatibility, C++ is copy by default. While Rust is move by default, which enables to hide the l-value/r-value concept most of the time.
Rust is const by default, C++ needs to have const everywhere.
And Rust has lifecycle check which is very useful to avoid multi-thread issue and dangling reference. Even if modern C++ has less and less memory issue, it can still happen when beginner code like Java in C++. Rust completely avoid that by throwing a compilation error.
And the memory model of Rust is far better than C++ unchecked exception or Java checked exception because it is directly using the return value. It becomes very easy to combine with functional code.
With smart pointers and STL a lot of these problems don't exist
@@isodoubIet No, that's a biased take. The point of any language should be to increase productivity - not to raise artificial competitive barriers to entry that increase YOUR relative pay grade because it shuts out other humans from being productive due to a high learning curve. THAT is the truth.
@@lashlarue7924 Who said anything about "artificial competitive barriers"? C++ is a language that lets you be extraordinarily productive. Complaining about "pitfalls" that are mostly very easy to learn and avoid is a skill issue, sorry to say.
go for me as a javascript /python programer is like my savior i dont give a damn about memory management (we deal with backend services here not developping an operating system )as long as i can ship my code faster with less bugs and more readable for my team i'm happy in short go for us GETS THE JOB DONE .
Go is the balance we needed between performance and simplicity
Memory management is pretty important when talking about performance
And just because a language has a GC doesn't mean that you can completely forget about memory management
I agree with you but I already came from garbage collected languages (js and python) performance is not my focus but faster code and ship time is
Ah so you throw hardware at the problem ;)
You absolutely need to handle memory in GC languages, I.e. through object pooling, especially in something like a web server with concurrency, I.e. one of go’s primary applications.
@@hamm8934 if i want to go through that may well just code with Rust and frankly in the end of the day the gain is insignificant besides i want a finished working web app not a school project that may or may not be finished the next year
19:56 My more generic feeling about this is: *No classification changes what things are.*
And my politics would be: *Qualify rather than classify.*
If it quacks like a duck, walks like a duck, and flies like a duck, maybe it's *still not* a duck, but maybe *we don't care* because all we need to know is *it can do it.*
All we actually need is to assert that the thing *comply* with a bunch of criteria.
Now, before you invent more types than in _Rust_ , remember the number $n$ of types you can make with $c$ independent criteria is $n=2^c$. This is already *too much* to pre-define in a programming language syntax.
And also, keep in mind that, inside the binary machine, the only actual type is *positive integer* .
*Any other type is simulated* by tagging some positive integer with purely *arbitrary* meaning.
Everytime i hear about something the primeagen is doing at his job, i get a little envious at how interesting it sounds lol. I haven't done anything nearly that fun at my job...
"Even if Node came with a singlular tool. Compilation, build, everything."
That is what Deno is.
i said node, and claiming another thing all togethre doesn't some how make node in one tool
you require a reordering of the javascript ecosystem to be deno.
@@ThePrimeTimeagen Their Node compatibility is getting better each release, so maybe that won't be true forever.
@@_____caseNodeJS will never correct the fundamental issue of JavaScript’s type system. That’s a language design problem and language design problems can only be solved my making a better language design not by micro-optimizations with intermediary tools.
That shit that you feel in Go; like something is missing, it’s on purpose thats the withdrawal effect. By the way OCAML is the new shiny object!
Great editing on this, almost no downtime and all content.
I love that the text he reads at 0:40 perfectly fits what he's signaling with his hands. "out. go."
Reminds me of the "Worse is Better" lore in the Lisp world. You should really consider reading some of Richard Gabriel's essays if you liked this one.
chat never fails to be in either completely sync with prime or completely out of sync with prime. He's tryna read something seriously and chat just makes fun and vice versa. Such a good channel btw.
Would love a course and deep dive on Javascript workers/threads/async etc... When and how to use worker threads, use cases with efficient practical algos that we'd use in the wild to make javascript performant in certain situations. There's definitely a market for a course like this.
man ive been looking for something like this since forever
@@biskitpagla Same!
i want to change to that direction. like Rust is very interesting with all the features, it's like finding yourself in a baggage claim conveyors in airport but all sorts of japanese vending machines come from the belt instead of luggage. it's all interesting and nice to learn but also confusing and complicated.
especially with my lack of expertise. perhaps it's more effective to learn it after more programming experience.
i went back to C to smell the machine a bit more and solidify the basics. honestly go sounds more and more compelling, especially if it's that easy to learn. it's probably better to work on the languages i know for now but maybe like next year i'll slowly learn Go
I really loved that talk. Thanks, Prime, for reading that. I'm learning Go, and that helped put a few things in context. Go is so so soooo much better than TS (current work code base).
I would love to hear a detailed rant on the over expressiveness of Typescript. I'm a JS/GO dev and I know the benefits of a type system but I absolutely HATE typescript and have a hard time explaining why. I thought it was originally because I hated typed languages but I love GO. It is specifically TS.
Well TS is clunky, because it has to abide by the rules of Javascript. So that really holds it back.
TS is nice if you use it right, but that's the problem, you can use it bad in too many ways :). Also if you think TS from a C++/Go/Rust perspective, you miss the point of the language.
ts type system is more like java thats why
@@beastofthenumber6764 not is not, is nothing like Java, maybe if you only use interfaces?. If you use interfaces for TS, you're using it wrong again. And you go back to my previous comment, too many ways of using it wrong.
@@oscarljimenez5717 i agree they can be used better, but the "wrong" way is the intended or at least the more promoted way. Even in java you can construct classes in ways that are better but almost nobody does.
Desiderata: Original Text
This is the original text from the book where Desiderata was first published.
Go placidly amid the noise and the haste, and remember what peace there may be in silence. As far as possible, without surrender, be on good terms with all persons.
Speak your truth quietly and clearly; and listen to others, even to the dull and the ignorant; they too have their story.
Avoid loud and aggressive persons; they are vexatious to the spirit. If you compare yourself with others, you may become vain or bitter, for always there will be greater and lesser persons than yourself.
Enjoy your achievements as well as your plans. Keep interested in your own career, however humble; it is a real possession in the changing fortunes of time.
Exercise caution in your business affairs, for the world is full of trickery. But let this not blind you to what virtue there is; many persons strive for high ideals, and everywhere life is full of heroism.
Be yourself. Especially do not feign affection. Neither be cynical about love; for in the face of all aridity and disenchantment, it is as perennial as the grass.
Take kindly the counsel of the years, gracefully surrendering the things of youth.
Nurture strength of spirit to shield you in sudden misfortune. But do not distress yourself with dark imaginings. Many fears are born of fatigue and loneliness.
Beyond a wholesome discipline, be gentle with yourself. You are a child of the universe no less than the trees and the stars; you have a right to be here.
And whether or not it is clear to you, no doubt the universe is unfolding as it should. Therefore be at peace with God, whatever you conceive Him to be. And whatever your labors and aspirations, in the noisy confusion of life, keep peace in your soul. With all its sham, drudgery and broken dreams, it is still a beautiful world. Be cheerful. Strive to be happy.
by Max Ehrmann ©1927
“Wisdom remains unchanged but ideas can change quite a lot”
"Less is more" is the slogan for a Swedish toilet paper/paper holder company. Used in companies and public places. It is stamped on their equipment :)
is his argument really against haskell/rust? he seems to talk mostly about type hierarchies, in the sense of classes/superclasses/subclasses… maybe it could be said that of typeclasses and traits, but, not really… types, at least in haskell, don’t have any “hierarchy” in the sense that he seems to talk about.
if anything, go is more similar (in spirit) to haskell and rust, since he talks about what makes it different is the compositional nature of interface methods
Three computer science articles, ever, stand on top for me: Ken's "Reflections on Trusting Trust", Hoare's "Emperor's Old Clothes" and this "Less is exponentially more".
Can someone explain the joke at 3:18
Understanding something is not always breaking down into smaller and smaller parts. While you are reducing the subject you are increasing losing context. To really understand the world more you would find patterns and similarities and not fracture your understanding of the world
I worked at a company that used Go while I was getting my undergrad. Having graduated and spent almost as much time in industry as I did getting my degree I think I need to revisit Go. Java was my undergrad, and it's much of what I do at my current job, but I'm starting to see it's many issues (not sure how many of the issues in my current project stem from the fact that I'm the most experienced dev on my team though)
I don't know that procedural programming is strictly more natural than functional, though some things are naturally sequential in nature and therefore procedural fits better for those. I think it really is an exposure thing, the classic example being to ask students how to make a peanut butter and jelly sandwich.
this is a great thing to watch, but its not a great argument.
recursive thinking is definitely not a natural format, procedural is something we do with a _LOT_ of brain filling in the gaps
@@ThePrimeTimeagenThis is an apples-to-oranges comparison. Strict FP may require recursion, but most functional code out there doesn't explicitly use it (preferring higher level abstractions like map/fold/reduce/etc instead). To make it a fair comparison, you'd have to compare strict functional code with strict procedural code, which would look more like assembly and preclude much of the common usage of functions found even in a language like C. And obviously, even the strictest functional code still has elements of procedural style in the way function calls are arranged and executed sequentially (though Haskell does complicate that a bit more with it's laziness).
Point being: the whole Functional vs Procedural thing is just a poor dichotomy all around. You can't really produce good code with just one or the other, because they never existed in mutually exclusive vacuums to begin with. Good code is eventually going to rely on both styles where appropriate.
However, functional style building blocks do become more useful the higher up you go on the abstraction ladder. And I don't mean pointless java-style "abstractions", but rather layers in a properly segmented cake-like architecture, more like the abstraction that occurs when going from ASM -> C -> Python (ie. stratified design). Procedural methods become more limiting the further up you go in abstraction because they were designed to work with lower-level primitive values. Thus when you try to make higher level abstractions work procedurally, you're forced to expose a lot more internal implementation details to enable working with them, which means leaky abstractions, more cognitive overhead for the developer, and prevents the formation of properly stratified layers.
You might think to yourself "That's absurd. I code procedurally all the time and can still separate everything well with good API boundaries". But if you look at the situation closer, you'll notice that the entire concept of an API boundary is actually more functional than procedural, because you're asking the API to do something for you as opposed to telling it how to do it (ie. a function call as opposed to a GOTO). Which goes back to my original point about there not being any actual hard-and-fast separation between the two.
There's always the argument of whether the goal justifies the means, but so far Go seems to tackle both with its great performance. Rust can do the same, if you grind enough to get used to it
My problem with GoLang has always been the insular design of it. After it got some traction there were a lot of (poor) comparisons of GoLang and Erlang from, IMO, people rather ignorant of one or the other language. After a while I recall some of the Erlang communities' criticisms of Go's designs got back to core architects. The issue, from the Erlang folks, was ... why goroutines? Over the past 40 years there had been a lot of research into concurrency models and a fancier coroutine mechanism built into the language was better than nothing but Erlang and other languages / libraries had really powerful concurrency models that seemed to be entirely ignored in GoLang's design. And as I recall the response was kinda like: "we didn't look into the topic. :shrug:" I don't like that at all. In an age when concurrency is more important to make easier than any time in history and you spent time to design a language with concurrency built in... kinda important to do your homework. no?
Erlang isn't perfect but when it comes to concurrency and general simplicity I absolutely adore it. You can understand the whole language without much effort. Worrying about contention rather than how to create the concurrency in the first place is truly game changing and I've never built distributed services more easily. Add in a fast built in serialization/marshaling library and simple technique for handling out of VM IPC... it is just a pleasure working with. I wish other languages took more of the Erlang communities' ideas. And I wish GoLang would have had actors instead of coroutines. You have languages like Pony that tried to go in an actor like direction but didn't get much traction.
Just saw @17:20 "Go's concurrency model might be the best ever."
Can't agree even a little. It's not bad but actor systems, and proper scaffolding (like Erlang's supervisor module), are so much better for wide scale concurrency.
@@trapexit OK but no one cares about Erlang, sorry. It took a whole different language (Elixir) for people to care.
@@spell105 "No one cares..." Checks major apps used across the OSS world written in Erlang as are critical apps in multiple fields ... Yes, no one cares.
Elixir is not all that much more than a syntax change. The fundamentals of Elixir are the same as Erlang. They run on the same VM. They have the same actor model because the VM is purpose built for concurrency. For Erlang. Elixir never would have existed had it not been for BEAM VM and the fundamental designs built into necessary to accomplish what it sets out to accomplish. It is why other platforms can't do the kind of concurrency models Erlang has. Why the Java Erlang implementation failed.
If you want to be able to create fundamentally different patterns you have to often do fundamentally different things. And even when they fail to catch on they can provide a lot of value to others. So feel free to ignore alternative technologies but you aren't gaining anything from the ignorance.
I can see ThePrimeagen loving go a bit more down the road
and on the technical debt of types? Yes. The closer a type system gets to turing completeness, the more expressive it is necessarily. But if your type system is subject to the halting problem, there are now some perflectly valid types you can express that no compiler can compute.
It’s not a surprise to me that Go isn’t a replacement for C and C++. A language with GC is not a systems programming language.
We still need a good replacement for C. I’m rooting for Zig to become that.
I love your videos. I learn a lot of English with them. Greetings from Colombia.
Bro you must be a complete genius. Most people who speak English would only understand about 20% of what this guy says. I'm an Ivy League graduate who has never scored blow 99% on any single standardized "verbal" English test (truth!), and I only understand maybe 75% of the engineering context despite being a relatively intelligent nerd with all the capacity to be this man's peer; I often understand English words that Primeagen does not, and I do enjoy watching him struggle, because I am a bad person (and because he is an infinitely better engineer than I am).
So, if you're able to learn English by watching this guy, you're a Gigachad. Bigups to you.
Good luck Michael on convincing JS programmers to use such a complictaed language like Rust in their work :)
True, most JavaScript programmers don't have the intelligence to learn anything harder.
@@Manja500I hope this comment made you feel better about yourself
@@KadenCartwright Welp boys, we have our first JavaScript programmer. I'm sorry that your programming career is limited to the lack of brain matter in your head. I learned Python at the age of 11 and JavaScript at the age of 13. The language has it's uses, but people who make a career out of just JavaScript (other than frontend people, they don't have a choice) clearly have the intelligence of a 13 year old.
@@Manja500 You know you really don't need to validate your existence by putting down others for choices they most likely didn't make? I know and have used many languages both in side projects and production code, you learn to take something valuable from all of them. Would you say someone like Rich Harris has the intelligence of a 13 year old? Or a myriad of devs working on hundreds, if not thousands, of apps that service millions of people using JS are also comparable to 13 year old? Do you think software like Slack, Discord, Chrome to some degree, the app where you're reading this very comment are products of a bunch of dumdums? A senior level, or even mid level, JS programmer would be perfectly capable of coding in most languages given some time - problem solving skills are not tied to the language after all.
@@Manja500Who are you writing this to? Do you think this toxic vibe is what is cool?
The article and the Take basically nailed it. If you're a Python dev and you just want to increase your speed a bit without having to completely worry about too many leg cannons, why would you bother to learn C++? It's the same reason some other large platforms (which shall remain nameless) don't get adopted - you have to devote your entire existence to learning that tool. I don't even need a better tool than Python at this point for what I do; the need simply doesn't exist in my world and it never will.
But if you devoted your entire existence to learning how to write clever code that manages memory directly, why would you ever want to give that up? Of course you wouldn't!
Time will tell.
The taxonomy bit always sticks in my head, but it's only *almost* correct. MANUALLY CONSTRUCTED type hierarchies are taxonomy, but an implicit immutable type hierarchy could be useful
I've been looking for a back end language to learn now that I'm sure I don't want to do full stack development. I'm starting with JS because there's more resources out there but I'm planning to jump to Go once I got an idea of what I'm doing
some golang "features":
* no immutability qualifiers (const/final/readonly)
* verbose and error prone error handling
* terrible time package
* no stack traces in errors
* zero types are error prone
* no default interface function implementation
* generics are very weak
* structural typing is a hack, and an annoyance in large code bases
and many more
Can someone possibly refer me to a Prime video where he explains his disdain for Uncle Bob in detail? I have my own qualms with the man, but I'm interested to understand Prime's take on the issue.
Functional != recursion
Recursion is a valuable tool for procedural programs. I learned it very early on and I think more people should as I think it’s easier to learn initially before your mental model starts to harden…
I think I've read somewhere that it was mainly designed for C++ devs but what happened instead was that Python and JS devs started to adopt it
Yeah. My understanding is that it was developed to replace Google's use of C++, which, due to the scale they operate at, is more like what other people tend to use Python and JS for.
I've been using Python to build proofs-of-concept for several years now. I learned Go this month and have been able to do some incredible things in it already; I can safely say that it is my new go-to language for anything that doesn't require GUIs, and I plan to build some GUI applications with Qt to see if it can become my go-to language for GUI apps as well.
Also, curse C++, we hates it. Nasty C-pluses ruins the code.
@@k98killer I build GUI apps in Go too. Which operating system do you use?
@@a4e69636b Linux and Windows. I have a friend who has to use Mac for his work, so it would be an additional bonus if I can get things working for it.
@@ssokolow I don't understand why JS and Python would be the correct language for Google use of C++.
C++ is for long term software when you know exactly the concepts and want to write them in the code. Thus the compiler can do the check for you and catch most errors. the goal is to be correct by construction. Changing becomes slower when writing code but faster in validating it. Because most issues are found with the type system. it also brings performance and memory predictability, good when you want to industrialize your software by consuming less ressources.
JS/Python enables writing incorrect code without any warning but a crash in production. And their VM makes it unpredictable and not efficient in term of performance and memory.
Thus it is better to do POC and try stuff when everything is blurry. Or to write quickly disposable script to manage existing library/software. But if you build huge program with it, you will just con your clients with many support case for runtime errors.
Yeah. Ruby was the rust of my generation. back when people in the indie-lang space thought there was a right way to do OOP. I imagine we will eventually arrive at a similar situation for rust things where we are like "Yeah that was an embarassingly long and windy dead end."
Desiderata...that's a piece by Max Erhmann. Words to live by.
I never looked closely before into go and it's syntax. and after watching video I wondered how it is possible that it has no generics but is strongly typed lang. I checked and found that it has in fact "map[keyType]valueType" that is look to me as built-in generic. and makes me think it has no way to define custom generics but has built-in ones
Welter weight languages are underrated and overpowered. Free variables are all you need for calculus; not limits or epsilon delta. The simpler the syntax, the simpler the re writes.
I almost got into Go but got turned off by the stupidity of the date formating.
"Go has this python esque feeling to it" lmao, you could literally only be referring to the no-semicolons.
Go absolutely doesn't feel like python at all.
I was about to say, Go feels and writes nothing like Python. Mostly for the better.
C pioneered returning error values. 0 means success, anything else means error.
Go really just needs a couple of tiny tweaks to become THE language to use for anything in between the frontend shenanigans and OS&kernel.
Already started pivoting slowly into it as a dotnet/node fullstack microservices merchant
what do you think they need to tweak to make it usable for os programming?
@@devnexen I doubt it will ever get into that area fully, thats why I said it's starting to look like a great language for everything not frontend or super low level stuff like OS.
That being said and to answer your question it would require GO to have no garbage collection at all in order to be used for it. Thats why C and C++ were kings for the past 40 years of OS development, and languages like Rust and Zig are the candidates to go in there
@@matez8355 for starter it would need to remove the garbage collection part (or at least making optional like nim). A lot easier said than done tough.
@@devnexen I would say impossible unless they sacrifice a lot of the good things about concurrency they already have
@@matez8355 fair point, but trust me you do not want a driver written in go with huge latency because of the GC 😀
Came from a Java and C# enterprise world, used some Python for side stuff. Now I really feel like Go can give me the performance and type safety I miss from Java and C# but with some of the simplicity Python made me appreciate
It's too bad Nim hasn't gotten more adoption by Python refugees.
how is implicit interface in Go a good thing? AFAIK it's the only language that does this and it's confusing for me.
Actually typescript does thing like this. They call it structural typing.
English speakers typically say /DEH-zih-de-RAH-tah/; it's from Latin, meaning "wanted things". Based on HN responses to comments about C++'s complexity, C++ devotees typically respond with "C++ isn't too complex; you're just not good enough to handle C++", so I'm not surprised C++ programmers wouldn't switch to Go.
@ThePrimeTime What's with the selecting all but the first and last character in (almost) every text?
I wish go had opinionated feature-rich web framework. Instead here I am, working on a project where I have to freaking write auth system wtf. Coming from aspnet core this is pain....
Bruh, don't be that guy.
You are not forced to write your own, there's a billion choices out there, and most are generally composed from standard interfaces so..
@@QckSGaming suggest some
@@IvanRandomDudeif you can't even Google idk what to tell you.
Pocketbass
Haha i had functional programming in my first year as a cs student and 75% of the class failed. Your opinions resonate with me very well.
@@d_6963 Haskell. And it‘s not like we were a bad year. We had a 86% average on the math classes the same year. We just had little to no experience programming and understanding how one can manipulate data and control flow.
@@lucky_luke4785 Interesting perspective. Lots of Haskell evangelists claim Haskell _seems_ hard because we're all just ossified boomers whose brains have been so deformed by years of coding procedurally that we can't imagine how to do things another way, and that if only we'd learned Haskell first it would be procedural code that would seem hard instead. I always thought this was obvious BS but it's nice to have some evidence that newbs will find Haskell confusing too.
Functional with a bit of classes here and there will win in the end.
You mean something along the lines of Scala ?
While watching the video (2:30 to be precise), something about IP addresses just hit me like a truck full of bricks: CS Research Center at Bell hat the internal number 127. What are the first three digits of localhost? Yep.
13:29 why would that be surprising? what did you expect to happen and why? I bet you can't figure out better semantics without introducing a separate int type
As somebody said... *Go is built for grug brained programmers* (like me). Or saying differently: *Go is for old, grumpy man* who grew up in 80-90 on their old Atari, Commodore or ZX spectrum.
Go is extremely unsafe. You can access nil pointer everywhere, nobody is going to warn you, you can partially initializw your structs and forget some fields. Just horrible.
Lololololol
Implicit casting 32 to 64 is all fun and games, until you're working with an in house serializer and suddenly can't figure out why the client is getting errors trying to deserialize
14:26 "Methods are just function": how *ironic* . 'cause in fact, it's the very exact opposite: all so-badly-called "functions" people continue to call "functions" in almost all languages *are methods* , not pure functions in the mathematical sense.
correct
nobody cares about smelly mathematics and what they call it. programming isn't math.
Whait, I know it's an old comment, but how are functions in programming languages not functions in the mathematical sense?
A Mathematical function just maps each element of the domain to a exactly one element of the codomain.
How is that not what programming functions do?
Do you mean the possibility of errors makes them not functions?
Very odd that there was just about 0 pushback on the statement "Go's claim is that minimizing programmer effort is a more important consideration," considering the fact that Prime regularly says DX isn't a thing. That's literally DX in more words.
i say that modern dx is the definition of "i am familiar with this approach"
that on the other hand is the summation of the post claiming to pair down features into the minimum amount to make it the most effective. i can agree with that statement / little argue because of the totality of the article and my knowledge of go
Was Go amed so because it is the first word in the Desiderata text?
Just so you guys know a little piece of ultra nerdy trivia: desiderata (from the italian, meaning "those who are desired") appears in another article that Rob Pike wrote about how UTF-8 was created by him and Ken Thompson.
Ty
Directly from Latin actually, desideratum
@@isodoubIet yes
I'm yet to meet anyone in real life, who likes "letter case sets visibility"☺
Hi!
@@omeryehezkely3096 Hi!
Hi!
@@WayneRadinsky Hi! ☺
I love how this guy lists that as a positive. Like, holy smokes what a misfeature
Another way of stating the conclusion here is that Go is intercepting those that would have otherwise found their way to C++ when the need arose
Isn't Go's concurrency model similar to Erlang's?
CSP vs Actor’ish
can you make a video about qwik? thanks in advance
This article describes me. Python as native language and switches to Go for concurrency fun.
This has me interested in c++
Wait, you understand Rust borrowing system, but you don't understand rvalue references? The borrow checker is exactly the same as rvalue reference but with the compiler making sure you are doing it right
I think the problem is the name, borrow checker just checks borrow, but a rvalue reference? What the heck is a rvalue and why are you referencing it?
@@elcugo"rtfm lol"
@@elcugo rvalue references make perfect sense apart from the fact that value categories are distinct from types and you can have an lvalue of type rvalue reference and vice versa. That is the single most confusing aspect of the whole thing. Conceptually though, it's actually pretty simple, it's an rvalue because it's the sort of thing that goes on the right hand side of an assignment, which is 'just' a way to detect when references point to temporaries.
@@isodoubIet I know what rvalue references are, but the explanation just gave sounds like technobable to anyone that isn't already entrenched into C++. Thinking about a better name I came out with "ownership transferring references" which isn't a great name especially since it isn't accurate because moves may or may not happen.
@@elcugo The problem with other more descriptive names is they lose accuracy. Maybe that particular ship sailed with std::move but an rvalue, to me, doesn't imply ownership will be transferred. It just means I shouldn't rely on the object living past the semicolon.
I will never understand the lvalue - glvalue vs prvalue - rvalue dichotomy though. Seems pretty silly and inconsistent.
I think the answer is simpler than that. While trying to sell a new language to C++ programmers, the moment you pronounce the words "garbage collector" or "no RAII", you've pretty much lost 90% of them already.
Desiderata is from Italian and it means desired 👍Cheers!
Am I crazy or cant there just be a lang that does it all? interpreted, compiled, types, no types, etc and just have the programmers that use it choose how to use it
Never used Go, but I really don't like the implicit interfaces. That's almost like dynamic typing where you don't know what a certain type implements and when the interface changes how would tools help you with the refactor? Also generics are a must in any language that is higher level than C (which I see as high-level assembly).
Go has generics since version 1.18, which came out last year.
@@infastin3795 I know. I might have a look at it when there remains no code that casts through interface {}.
Go is C for the web.
Neither Rust nor Haskell have inheritance, the complaint about type hierarchies are about C++ and (especially) Java.
C++ and Java programmers have long moved on from type hierarchies, stop inventing straw men. C++ has embraced composition over inheritance 12 years ago before it was the cool thing, and even Java programmers know inheritance causes headaches, with Spring moving to remove most forms of inheritance from its code, preferring interfaces where possible.
Eventually they will just reinvent Lisp.
who is the author of this article?
I know templates are terrible designed in C++, but the idea behind metaprogramming is good per se for me. Maybe generic as Java and Rust are just enough.
This. The point of a type system with generics is that static type systems may not give you more expressiveness than a dynamically typed language, but if you don't include generics they can definitely reduce expressiveness a lot. It isn't so much about taxonomy as just making many functions impossible to write.
Can someone explain the 27 joke to this feeblemind.
If we were to understand the fundamental nature of things better, more things would be obvious and less things would need to be actively researched, hence less departments