I’ve really come around to Go. I used to despise it but now I’m in love with the simplicity. In Go, I find myself asking “what is the most straightforward way to do this?” And more often than not that is clearly the best approach.
Imo, most people who like rust actually just like having native Option types and exhaustive pattern matching; just those two things solve something like 97% of bugs in most projects in mainstream languages just by getting rid of exceptions as control flow and forcing you to handle all cases. Beyond that, most of its features exist to address a specific kind of complexity that just isn't present in most software engineering contexts.
I like D because it has both sides of the coin somewhere in-between of Go and Rust: you can start writing in a simple way very clean and fast with GC and simple structs.. And if you need to make some tricky magic - welcome to metaprogramming world with traits, mixins and templates. If you need even more speed - you can even disable GC and write your hot part with asm and great auto-vec support from GCC/LLVM world.
Go is pretty fun. Cool, that you give it a serious chance. I love it for prototyping and testing new Ideas. You don't have to worry to much about types, to get things working, but once you want to tie things down, you can type things as strict as you want. The only hard thing to wrap my head around was slices. Once I realized that a Slice that is extended over its original capacity becomes a list of clones instead of references, everything was OK though. Until you extend a slice over its original capacity, all elements in it are references to the original entries, allowing for some pretty fun stuff, when building multiple slices from the same base Array.
@@Rakstawr there is an append function, it returns a new slice. Append to a slice, whos capacity has not been reached, and you get the original slice back, just with the new element appended. However, if you append to a slice whos length is equal to its capacity already, then Go creates a new slice, that contains copys of the original slices contents + the appended element and a new capacity. instead.
@@AScribblingTurtleI mean it's pretty obvious. Slice is just a reference to an array. And an array is a continuous block of memory, so if you append and it exceed the memory, you can't just put it in, it will override some memory blindly. So you have to create a new one.
I think this is a pretty great way of going about learning about the mysteries of how humans and teams of humans think about programming. Most languages have unintended consequences as a result of certain design decisions that eventually become crystalized and hard to avoid as it matures. I don't think a lot of people really know if the amazing expressivity and less than amazing complexity of rust affects the human behaviors of programmers working with it without trying something completely different like Go. I'll be following along and will be very curious what some of the unintended consequences of the decisions made during Go & Rust's development get uncovered.
Interesting perspective! Rust's expressivity vs complexity impact on human behaviors is a fascinating topic. Looking forward to your insights on Go's unintended consequences.
Love your take here, as a relatively new dev I'm currently learning Go and loving it, but I'm super excited about learning Rust next year. I love this idea of dedicating time, like a full year or two, to explore and get good at different paradigms and that's what I'm doing
I'm kinda of migrating from PHP and Laravel to node because of a job and I'm really enjoying it. But I'm thinking about giving Go a try to see if I like it. The thing is, there are some details that scares me like pointers, bc I did not had a great time learning that on college lol. I wanna see if Go is all that great like everyone talk about
@@porfiriodev pointers in go is simple, you don't need to think of them too much, because of garbage collector. Just understand what it is and when to use it and that's it
Reminds me of the crazy types I would see in TS when I would mouse over a variable in a React app. I watched some of Matt Pocock's TS videos a long while back because I wanted to get better at types, but I kept wondering "Is this level of complexity really necessary?" I've been building a project in Go and the simplicity feels so worth it. I still catch myself overengineering things and have to dial it back when I refactor.
A lot of the crazy typescript types are necessary to type the things people are used to doing in JavaScript. You can do basic classes and data types and only do that if you want, it's just that people are used to certain (more convenient) patterns from JavaScript.
I feel like lots of Go programmers are ex-java programmers who have never did professional programming outside Java (like yours truly) and once they did the shift to go they were impressed by the simplicity of the language, bear in mind half of java is spring boot with all it's features and complexity so it adds more to the complexity and abstraction you have to deal with.
That’s my case. I’m a Java dev and I feel alright about Java itself, but this obsession with that awful Spring thing is just sick. Spring is a monster gobbling up your development time, totally broken and undebuggable, and Golang is a refreshingly beautiful ecosystem in comparison. One of the best things about Go is that there’s nothing like Spring there
I came from learning CS (with C, Java, C# and all the things) to do mostly PHP, some Ruby and ELM in between and a lot of JavaScript until I started to like TypeScript. Now Go is my main-language whenever I can. My first projects where pure chaos, since I was still stuck with JS-brain and trying to solve stuff that way. The more I looked at how go-devs solve stuff the go-way the more I embraced that, and now stuff feels so extremely elegant in it's simplicity. Combined with HTMX it's just beautiful.
What kind of projects do you do in Go, I am starting learning but I don't have idea what to build because my mind is so immersive in Frontend but I need a change
@@enzocam07 I started with some simple webservers. Replicated a few things I did in JS. Then I focused on a smart alarm. A replacement for an alexa echo dot with a raspberry pi underneath. What I also want to are some GTK-Desktop apps. Mainly to fill in blanks in my workflow I haven't found tools for that I like, and to learn a bit more about desktop-programming. Even tho go might not be the best for that, it still is better then electron.
@@mauricioramirez2855 I just like the language which helps. But if I had to pick... Errors as values, the standard-library, and simplicity. honorable mention to god-tier concurrency, BLAZINGLY(tm) fast compiles and the elegance with which you can solve a lot of things.
Go builds and runs on almost anything-any OS, any architecture. It cross-compiles from anything to anything, statically links during cross-compilation, and doesn't care about glibc, bionic, or GPL drama. It has a built-in concurrent garbage collector and comes with everything you need out of the box, handling 90% of what C, C++, or Rust can do without the headaches.
I have been writing php code for years. I starting to use go whenever I can because of how simple it can be to learn and all of the powerful choices it has made for a language go is really good and I want to find a way to write more Go code.
I think Go will help your Rust since it will help you surface simple designs. I think this is how Tower came about. Before Tower, Rust web libraries were proc macro all the things, over complicated messes. They're powerful but if you get compiler errors, you need to use your galaxy brain to figure out what the heck happened. Well I'm sure someone saw how Go's handlers work and this completely inspired Tower and it's very simple and straight forward and composable.
When you write stuff in GO you are thinking about program you are doing, when you write in RUST you are thinking more about language and less what you want to achieve. This is dealbreaker (at least for me) when it comes to productivity.
I actually find Rust has less of that problem for me than Haskell. It's because the type system is slightly less expressive, at least, without macros. However, in C# I find myself spending too much time wondering what the simplest way to do something is, because it's so low-level that the simplest way to do something often looks complex. So it ends up being a different kind of type masturbation. I'm very happy with Rust so far. (I started using it this year.)
Если среди разработчиков чувак придумавший ( со товарищи) чистый С и Unix, то go по определению не может быть говном! Жаль что чуваки сразу не подумали что модель исполнения (все статическое) + goroutines отлично подходит для baremetal микроконтроллеров софта. Но вроде наконец появился tinygo.
I definitely agree that there is no best language, there is just the best language for the situation. Sometimes it's a language you don't know yet. Insisting that there is only one good language is like saying welding is the only way to join two things, and if you can't weld those things you're using garbage materials. And then, a classical Japanese woodworker casually drops off a joined set of beams and says, "this survives a 6.0 earthquake in a 4 storey house" and walks away. No glue, no nails, no screws. Always be learning. Other languages exist because they solve a problem that existed when they were made. Sometimes they jump the shark and are brought where they shouldn't (looking at you, JavaScript), but there's still the core concept in mind, and you will know that it's the right idea to solve your problem when the time comes.
I did one big project in Golang and had a wonderful time. The suck started when using a graphics/sound library that had terrible performance. I kinda feel like giving it another go (hur-hur) after last year's C# excursion. I should give Rust another attempt but Golang is so much more comfy.
Perhaps that's where you shouldn't use the language. It is a language designed for the web, writing servers, and clis. So using it outside of that bounds I'm not exactly sure where it fails
@@amodo80 It's OK but it gave me a lot of pain actually. That's the library I was referring to. The shader system is kinda bad and dynamic audio synthesis is extremely laggy.
Is there any flavor of rust that disables syntactic sugar and fluffy features? I.e. if I basically want C with borrow checking and Rust compatible syntax?
I've been debating between switching from TS/JS to Rust, Go or Elixir and I decided to go with Elixir and I'm over the moon with it. I didn't think i'd like it as much as I have. Functional programming and the actor concurrency model has completely changed how I go about solving problems. It may not be as performant as Go or Rust but I write better structural code with it. Its understated how much of a quality of life improvement that has had that I was not expecting at all. There are also packages like Rustler that allows you to use Rust directly in Elixir if you need performance critical operations. I don't see myself leaving the language for quite some time.
I love this take. I write C# at work. How many times have I debated with colleagues whether such or such code should be an extension method, an abstract class or whatever else the language provides. By removing these options, Go shuts down all this useless chatter.
I disagree slightly that using languages you really like gets you stuck using only that one or its associated paradigm. Personally, I've been having a TON of fun using Scala as my main language lately because I just like the way it feels (it has a lot of similar features that I love from Rust, but without the memory management), but when I need a more functional language, I tend to immediately reach for F# or Elixir (depending on what is needed for the project). If I want to practice OOP, I tend to use C#, Kotlin, or Ruby. Lower-level stuff gets Rust, C, or Go. I think you get the point... For me, using those different languages was a way *to break into* new paradigms, not get stuck in a single one. In fact, a lot of times I get really bored if I have to use the same language for a lot of projects in a row. I dunno, maybe I'm the outlier, but I just think it's neat to see how different languages handle similar (and also different) scenarios.
I mean, Scala can handle functional programming just fine. My point was just that if what he was saying was entirely true, I would've just stuck with the one language over choosing several. Also, unrelated, thank you for bringing my attention to a typo that I missed!
@@Me-wi6ym I meant that as you use F# you are clever guy. I didn't notice the typo. F# is a very good language. I started using it 2 months ago and migrated immediately a lot of my C# code to F#. C# is a little bit too verbose (Java heritage) and I like a lot the functional approach in coding. Having all the .NET ecosystem available when using F# , its great operability with C#, its great transpilers (Fable) make it a very good choice.
Its really a expression of the individual. Prime's telling on himself and how his brain works. It is very transparent of him to expose himself like that. I've seen these brain types before. They lock on to an idea and go full ape. But prime has learned to tame that ape. The ape brain can self reflect real good now. Some programmers (or humans) hate switching paradigms or modes. Their brains literally don't have the idea hopping genius and correlation. It takes time for their brain to build up neurons that can grow at will.
Ah I see. I assumed you were mocking the obvious choice of F# for functional programming since that's what it was designed for, my mistake. I personally love F# and it makes me kind of sad how little it actually gets used in the job market. I wish Prime would try it; the syntax is almost identical to Ocaml, at least for the important parts (if I'm remembering right, they handle OOP differently, but you don't use those languages for OOP anyway). I'll bet he would actually really like it
C# is amazing. I find myself spoiled by C# and its ecosystem. I move to other languages and miss C#. But I have been starting Rust and am building a client project with it. But I think I am going to start with Go. Flexing my brain is why I want to do this!
Imo one should try all combinations of high-level vs low-level and simplistic vs complex with at least one programming each (so yes, at least for PL). Obviously they shouldn't try all at once and from the get-go (and in general a starter PL shouldn't be a complex one, beginners already have enough other stuff to deal with (you would be surprised at how many people struggle with understanding the concept of recursion in the beginning)), but over time one should do this. And after having a decent amount of experience in each category, then go and start judging them against each other, but don't be surprised if not everybody agrees with your conclusion.
The more time I spend using Go the more I find interfaces really elegant. Refactors and testing become a breeze and they make the code feel super nimble
At the end of the day, I find it joyous just to be able to learn new programming languages. It feels like I'm taking a peek into the brilliant minds that created them: a whole new universe to explore!
9:05 This is where the ease of learning Go is amazing, because introducing it to your team is a relatively easy way to escape a worse language by starting work on a new project in Go. Stuck in the hell of using dynamic programming languages for large projects, or of using them for applications that need performance? Go is an easy sell and is so much nicer to work in.
7:52 hahah, that's funny because i'm just barely starting Go, and the thing I don't like is the := thing. I just don't like way it looks haha. I feel ya man.
i have only one question why are people choosing go or rust over c or cpp? What am I missing. i mean if c and cpp is fastest what else you need that go or rust are doing better.
Funny you mention the if statements and snake case being a turn off for Rust initially. The one and only time I tried learning some Go a few years ago, I discovered the compiler forces opening braces to be on the same line. I use new line curly braces, and I hated Go forcing new line upon me so much I quit after the first exercise and haven't revisited the language since.
I'm also more or less all-in on Go at this point, but to the point about enums, interfaces and enums are complimentary. Enums are great when when you need a fixed number of data options, but unbounded behavior options, while interfaces work when you have unbounded data, but a fixed number of behaviors. Interfaces are great for representing things like streams, which go does, but awful for representing deeply nested data structures, such as syntax trees. For this reason, I believe enums would actually be a valuable addition to Go. They added generics, so anything's possible.
I have been using Go at work for few years and I am trying to become proficient with Rust. I like to learn new things and Rust ticks that box perfectly. Which one I like best? I love them both.
I find myself often writing really verbose workarounds for simple expressions in other languages. I think something that writes like Python with the speed of Go would be the best. For me, Python is the closest language to imperative paradigm pseudocode.
Hmm. Could that mean you're not writing idiomatic Go code, yet? Translating from English can result in long, awkward phrases; and the same is true when translating into English, too
It's funny how things don't feel verbose until you realize there's an alternative. When I was doing primarily Go for a while in 2017 - 2019, I really missed having either something like list comprehensions, or map/filter/reduce. And yet I had spent years happily writing for loops in C and pre-Streams Java.
@@creativecravingfor example, take a simple ternary operation. x = 2 if thing else 3 in go this becomes x := 2 if thing { x = 3 } Lots of small things like that cause a great deal of mental friction while writing simple code
Ive been an AI and game dev for 6 years and this is so accurate. I learned to like each language the way it is. Even down to colour tbemes. I use jetbraind ides and python c# and javascript is what i use mainly and each one i have a different colour theme that somehow suits the langauge for some reason and im pedantic in each one respectively about its own syntax and styling. This just happened over time with using then all enough for different tasks.
I'm switching to go too. İ need something modern and well designed. But most of new languages are very strict and complicated to start or worse they force to use a specific framework. i like go's philosophy
One of the benefits of Go is also that it's easier to make open source projects. People who do not know the language can easily understand it and even sometimes submit fixes or PRs.
I felt the same about snake case. I thought it was weird at first coming from Java, but it's so much more readable! Not as convinced about the parenthesis tho.
5:44 We gained union types in Scala and I can only disagree. Together with singleton types we can have types like `"lts" | "exp"`. Do I need an interface or an enum just for that? Well you just said that a simple language does not mean complex apps. But now it's proving the point that I need to make my app more complex because the language does not have that feature.
Few things that would make Go beautiful in my opinion: - tagged unions - operator overloading (had to work with big.math for past 2months and I hate it) - syntax for error bubbling (no if err != nil) I think it's unlikely that I'll be getting any of the features above, but that would really be lovely. I don't need anything else from the language, but even rn go is good enough that I use it despite lacking things described.
Java has this thing called Virtual Threads, which is essentially the same thing as Go Routine I think. I don't know anything about Go, but isn't Go Routine the most important feature that Go has to offer and everything else about Go is pretty much the same as other languages ?
i have issues with go and especially with its type system. remapping json for different services is pain especially if one thing sends you json with nested arrays in it. i try to avoid reflection all the time because it just makes things much harder to maintain. interfaces are another issue, because majority of libraries just accept interface{} and god knows which interfaces even must be implemented. it's either skill issue or I'm trying to do what go wasn't created for.
I just wish go would add a short way to handle null pointers. Something like `variable?.property`. I don't believe this goes against any of go's principles of simplicity, but it does make the language much faster to write and easier to read when you have a lot of possibly nulls to handle.
I've started using Go for most things as a security engineer. I mostly build microservices like AWS Lambdas to solve security problems which i think lends very well to the simplicity of Go. You already have a 'simple/micro' problem to solve and then take a language that succeeds in that simplicity and it is just beautiful.
i had this same issue learning rust. tried to port a calculator app but damn did the syntax fuck me over. everything felt so messy compared to when i did it in c++ or java. just a skill issue, but is something jblow also said himself. gave up on rust for now since my main goal is to get a job using c or cpp, and i think zig would be a more enjoyable and skill transferable language to learn.
Parts of what was mentioned in this video confirmed me even further that learning programming languages is not much different than learning culture languages. Gotta think in that language in order to succeed more than thinking on your mother base language and keep translating. Meaning can get lost easily.
You refute the thesis that “complexity is either in the language or the application is a dumb take” by telling how generics led to simplifying code everywhere, including Go’s standard library. Previously, Go authors were very much against generics, then they were putting them off “to make them just right”, and now they have it and it has simplified lots of things. So I guess the take is not dumb, it’s true in fact, but it has limits. Like when you have essential complexity you cannot reduce further without detriment to solving whatever problem you are trying to solve. There’s _also_ a lot of unnecessary, self-inflicted complexity. Who knows, maybe using just a little bit of inheritance and java-style exception handling could simplify even more things? Maybe not, but what if? Or should we be uncritically burning heretics for merely uttering the forbidden keywords?
Go is great for backend webby stuff. First class language for backend web development and very nice for CLI. However, I would never use it for high performance or system programming. It's a language not designed for those areas. As a C programmer, I love Go. So for all you webby folks, if you do Go on the backend, native JS on the frontend, and use websockets to connect both sides, your website/webapp will require minimum if any 3rd party dependencies.
I was once doing an app in Laravel with Svelte, and I didn't know how to set up Svelte with TypeScript. I love TS because of the type system, the hate against JS, and bla, bla, bla. So I said -Well, fk it, I'm going to rawdog JS for a while. Some time later, I managed to compile TS with Svelte, and I was happy; I would be able to use my beloved type system again! But... but then I realized that the modules and the logic that I had done with JS was much more simple, good and, overall, easier to understand. In TS I was worrying too much about generics, types, interfaces, trying to make traits, mixins (search that one out and tell me I'm not dumb). I think about that now... maybe I want a simpler language, with simpler tools to just get the job done, and not lose myself with all of that funcional, OOP jargon and stuff. Love you prime btw ❤
This is so true. When I came from JS to python and saw no semicolons I hated python. I still do but I have learned to love python. I think I key is to learn to love and focus on the problem not the tool
As much as I hate the self-serving fanboi-ing over a language, I really think these sorts of arguments miss why people like Rust. I hate the foundation, mozilla, etc. and have every possible reason to be biased against Rust, but at the end of the day when I first began using it it *_felt_* like how programming *_should_* feel in my head. Same thing happened when I switched to Linux, it *_felt_* like how a computer *_should_* feel in my head. It had the features I never even questioned why they were missing, it removed the flaws I never even questioned why they were there, and it gave me flexibility I never even knew I didn't have. When I try to do something in Rust and find myself fighting the compiler, (note : that isn't always the borrow checker either!) I invariably find out at some point during the debugging/research process that what I was trying to do had more complications that I wasn't aware of previously. Not in the stupid "XY problem" way which is just used as an excuse to avoid answering the question that someone actually asked, but in the "oooooh, that makes sense why I can't do it this way, it's not possible" way. For instance, I don't do "hello world"s, I just don't, I've never found them useful to learning a language, so for my first project in Rust I tried to do a little embedded LED blinker project with an Arduino and had issues assigning arbitrary pins to be used to drive the LED. This wasn't a real issue for the project mind you, but I was cobbling things together from different sources and noticed that they didn't cleanly click, so I wanted to implement it fully and 'right'. In the process of making that very simple blinker I learned about impls, dyn traits, etc. and, after more work looking into embedded, I have a much clearer picture of why what I was doing wasn't easily possible. (of course I don't know for *_certain,_* but typically output pins are memory mapped or otherwise 'linked' as one unit that you assign values to collectively, sort of like output pins in a shift register. To that end, of *_course_* you couldn't just pass in completely arbitrary pin numbers, because the math to get a 1 or a 0 in that specific position is different and requires different instructions) Debugging pre-runtime (not necessarily even comp-time) just *_feels_* right, you generally have some assurances, you can speak about your code with confidence, and you can, generally, be sure you understand what's going on with your code, or rather, you can be sure that you don't *_not_* understand anything going on with your code. As a language these aren't magically intrinsic benefits - and yeah, sometimes it's annoying and feels like you're having to beat your head against the wall to do even a basic task - but at the end of the day *_knowing_* you didn't, intentionally or otherwise, take any shortcuts and that you're final result *is* comprehensively valid is invaluable. Your final result works, and you can say that with confidence. If, for some reason, there *_are_* any esoteric bugs, it's either a problem with someone else's code or it's isolated to your very clearly designated unsafe blocks. When you're making small throwaway utilities that's not meaningful, but when you're making a project or even a full application? Yeah, that matters. There are times you want types, and there are times where god damnit you just want to assign an ASCII character to a bloody i32 for some reason. If you're making quick throw-away applications or something then yeah C or Go or some other "get the fuck out of my way" languages are good, but that's not what most people do. "Minimum viable product becomes production", and with Rust you literally cannot help but make MVP at least production grade because the compiler wont let you.
I recently did some programming in Haskell to get a feel for it, well technically PureScript but same thing for all intents and purposes, and had the same experience, modulo massively better error messaging in Rust. I'd run into an error, spend a bunch of time trying to figure out why it was complaining and swearing at the compiler only to realize I messed something up or neglected to consider a possibility-at least Rust is nice enough to even suggest fixes. Once I accounted for that possibility or fixed my mistake, everything compiled and the app ran without any errors. There's plenty of other languages from dynamic ones like Python and JS to even just weaker static type systems like Java and Go where it runs but either doesn't output the right result or what seems like an innocuous change causes all kinds of issues that seem like they came out of nowhere but actually just lucked into not being hit. I do think Rust is overkill for a lot of projects since many don't need deterministic memory management, but there's a ton to be said for the compiler keeping you honest and informed. If I could have a GCed language with Rust's level of error messaging and as conscientious a compiler, that'd be my go-to language in a heartbeat.
Got the same feeling with assembly language. Code in assembly feels like a true computer program, you don't need to have it rewritten by some compiler. It's perfectly aligned with how the computer works. It's not hiding anything. It makes perfect sense.
@@ITSecNEO I mean I'd argue Prime has 'given it a chance' as much as anyone can be reasonably asked, I just don't think he's used it in the way most people will or will want to. To me at least, Rust's one big advantage is it's explicivity. Both the compiler *_and_* future readers of your code (yourself included) can clearly and confidently know what it's saying, what it's trying to say, and if/when those two things don't match or might not match. (within reason) The compiler then takes that information and *_forces_* you to either rectify the problems or mark the parts where you smeared your shit against the keyboard and told the compiler to make it be a program today and someone else's problem tomorrow. (which, as I'll hopefully reinforce sufficiently later, isn't necessarily always the wrong route - not all code *_needs_* to be provably production-grade) When you're writing command-line utilities and the like (which Prime explicitly said is what he used Rust for) then that *_will_* just get in the way more often than not. The loosey-goosey typing and lasseiz-faire semantic rules of something like Python, Javascript, Go or C are excellent for niche little utilities that need to just do a job, do it reasonably well, and not take a ton of time to make. Rust's main value, at least as I see it, is that it forces you to have better practice than that though. Not in the "oh well this is more clean and idiomatic" way, but rather in the "where the *_fuck_* do you want me to put this string?! Do you want it on the bloody stack or the damned heap FFS?!" way that forces you to understand and reason about the things you're actually asking the computer to do. This means you can be (reasonably) confident that your final product is solid and robust, at the cost of requiring much more (and much lower-level) reasoning. Rust *_is_* (likely) more of a hinderance for the problem-space Prime used it in, and I don't think that counts as him 'not trying it'. I *would* agree that I don't think he's really understood why people value it, but I wouldn't say he hasn't tried it. I just think his usecase for it is rather niche in comparison to what most people would use it for, and he hasn't really thought beyond that application-space. (which, to be clear, I *would* still say is a flaw on his part, but speaking without realizing other people's perspectives is far less of a problem than speaking without even realizing your own perspective first.)
PrimeDaddy has announced his Gopher status, now let's see how popularity in their subreddits change over the next 6-12 months. As of today, Feb 15th, 2024: Golang => 238,000 subscribers Rust => 274,000 subscribers
i'm still on the rust train but i totally get what you're coming from. when i use go it feels like it's lacking features. i know that can be a positive thing but i don't like that. for prototyping or very simple apps, i do like that, but when it comes to actually building something i don't. i also enjoy the "process" of writing rust code and thinking through problems in that way.
Go isn't my favourite language at all but it's honestly so easy to be productive in and the tooling is great so I'm finding myself enjoying it more and more!
Maybe algebraic data types are best in domains that require sophisticated data semantics, and a simpler type system is good for a more performance focused domain that has less semantic complexity?
You can prove that language complexity matters by taking it to extremes. Some of the simplest languages are lambda calculus and combinators languages. I think one of the simplest languages possible is "Subleq". It has only a single instruction: "SUBtract and branch if Less-than or EQual to zero". Fully Turing Complete in one instruction. What could be simpler? On the other extreme, we could have a dedicated syntax for every single unique operation, which would require an every increasing vocabulary, though every program could be a single symbol in such a language. What could be simpler? Obviously neither of these extremes are desirable, but we need to find a happy medium.
New to golang. Can someone explain to me how to deal with the annoying issue of reading data from a DB and handling NULLs. Always get that annoying scan error when getting data from another source with my microservice in golang. Is there a short way to just cast null to nil or is it really taboo to do that.
I’ve been using rust a bit a now. I used to be a big hater but it’s chill now.. the type system is nice, just works and casting is very forward. Also less buggy for sure, if the rust app builds it’ll probably run smoothly for the most part - opposed to C++ builds you run will come across unknown bugs you have to manually debug now. I do wish you could have no brackets for single line statements though, I’ve always found using brackets for single line statements nasty but now I’m force lol
it's interesting how we kinda swapped around the same time. I've always been a sort of Go fanboy but I've started learning Rust last week and I'm genuinely enjoying it.
Hey dude, I'm sure this will get lost in the comments, but I wanted to know your opinion on languages for cybersecurity. I was thinking Go or python. What are your thoughts. Thanks bud.
I love Go, because it's so easy to join a new team or project and pretty much in any case, be productive right away. I've joined some Java projects in the past and if the project was large it always took me a decent amount of time to ramp up before I could really start contributing.
Go and productivity? xD Good laugh bro. Its not about writing code fast, the whole ecosystem matters for productivity. And Go's ecosystem suck*, they not even managed to release a good formatter. You definetly need to read more about languages before you decide to choose one...
@@ITSecNEO When your executable is built and ready to use, you don't care about the formatter anymore. And I have been impressed by how fast I was able to get that executable ready, starting from zero knowledge of Go.
@@brinckau Deploying Code is the final of development ^^ The Rest of the time you will code or test your code. So obviously, a formatter matters a lot during dev.
@@zelllers You say troll to me but you arent even able to discuss. Well, maybe because there is no need for a discussion because everyone who used Go in companies, will know that the ecosystem is bs :) Only thing you can is to raise the troll card on me. Again, leave your Go bubble and do a proper research about Go and the bad design choices. Start with fasterthanlime articles on this topic and you will understand
Go is great and you're right - a language is more than a tool. Great languages come with coding patterns and a PoV and you have to embrace it or your code will suck.
I recently created a basic benchmark to compare Odin and C. Yes, I know how hard it is to make meaningful benchmarks, but I wanted a rough idea. (this is relevant to the video btw) I made a singly linked list, started with 6 elements and added up to 1000 one at a time. Each time it added an element, it did a basic linear search to find the end and add the new node there. I then deallocate the whole list. I ran this 1000 times and averaged out the time it took. I found Odin took about 2.4ms per run. Unoptomized C took about 7ms, and then compiling with -01 or higher landed C at 0.5ms roughly. I'm still not sure exactly why the time discrepancy, but they are pretty close. I then wrote the exact same code in Go to see how close C and Odin really are in performance. I expected a garbage collected language like Go to be a lot slower than either manual memory management implementation. The average time for Go was about 5 microseconds, or about 100x faster than C. Either Go is optimizing away the whole process, or my best guess is that the garbage collector actually makes it more effective. Now, both my C and Odin code is very naive. I simply call malloc/new every single time I create a node. I'm guessing Go is able to create larger allocations and split them almost instantly per each node. At least, it's my guess that malloc is the bottleneck. I can't imagine why linear search would be any faster in Go. Is this to say Go is faster than C? No. Because the code isn't the same. I could create a better allocation strategy in C and get better performance than Go. But I think this is a very important idea. Yes, if you write the correct code, C is faster than Go. But with equivalent code with equivalent work put in (actually, Go was a lot easier to write than C), Go can be a lot faster. I assumed even a naive approach in C would have to be faster than any garbage collected language. It's manual memory management, how can it be slow? But a naive approach in C is much slower than a naive approach in Go. And this is a major part of the value of Go. Not only is Go much faster and enjoyable to write than a language like C, it's simply easier to write performant code. You don't have to study allocation strategies and optimize for your specific problem. The language will likely do a decent job and get you 90% of the way there for most things.
In before my Go program was actually cheating and not performing the same thing. I also ran the benchmark in Python btw. At first it took 3 hours (cause I had an infinite loop) but then it took 17 minutes total, with something like 106ms per run. Classic python. Edit: I also ran go using "go run" rather than building since that should in theory keep it in debug mode and not risk optimizing things away. It was 5x slower but still way faster than C.
Welcome to the club, Gopher! Go is amazing for CLIs, backends, data transforms, and even the PyTorch lib is bearable for Go. It is a wonderful language for what it’s built to do. Some people even code games in Go which I’d like to try since there’s libs for a few engines.
I tried Go ~4 years ago, thought the syntax was strange, and I didn't really give it an honest chance, just dismissed it as "yet another language". About a year ago I gave it another chance, and ended up really liking it once embracing it as its own thing. It is currently my "go-to" language where it makes sense, so I am happy that I gave it another shot.
@@bot1511 It would largely depend on your background, but nothing really specific beyond just "use it". Once you start creating more complex applications beyond tutorial-esque examples (might have to just slog through it at first), the design choices, which seemed odd begin to make moe sense and feel natural. Other things like the order of types/variables just need to overcome the muscle memory of doing it the C-style way. Embracing the "functions are first-class values" and "composition of inheritance" paradigms and using them effectively also helps break the old habits.
the blue hair was the Go foreshadowing
no, blue hair = rust developer. He had to switch to Go otherwise he would be trans by 2025
Dyed hair blue to become a real rust developer, ended up identifying with the gopher so much that golang is his main language now
@@AJewFR0 The Foundation is clearly suffering from it.
Blue hair is rust bro 😅
@@susiebaka3388 Yep. So is the agenda.
I’ve really come around to Go. I used to despise it but now I’m in love with the simplicity. In Go, I find myself asking “what is the most straightforward way to do this?” And more often than not that is clearly the best approach.
There's something very beautiful about this. When there's often only one path available, you just don't have to think too hard about the minutia
@@ThePrimeTimeagen ewww, that sounds like python. Gross
@@RossDmochpython is a lot different from golang 😅
@@susiebaka3388 WAYYYYY different
Is python known for doing everything one idiomatic way?
Prime C# dev 2025. Lets go.
C# .NET ftw
Context always matters, I think he's not challenged enough. Also C# NET ftw :')
This the arc we're all waiting for Visual Studio Enterprise C#
C# is like a duvet
C# is hot u know today
Imo, most people who like rust actually just like having native Option types and exhaustive pattern matching; just those two things solve something like 97% of bugs in most projects in mainstream languages just by getting rid of exceptions as control flow and forcing you to handle all cases. Beyond that, most of its features exist to address a specific kind of complexity that just isn't present in most software engineering contexts.
"complexivityness"... Learned a new word today
😂 That's a generous way to say it!
Nice find! 'Complexivity' is a great word indeed 🤓
hahah oh man, if i wasn't already subscribed, that line would've gotten the sub.
Now we need the adjective for that: complexivitynessfull
And ofc the noun complexivitynessfull ness
I like D because it has both sides of the coin somewhere in-between of Go and Rust:
you can start writing in a simple way very clean and fast with GC and simple structs.. And if you need to make some tricky magic - welcome to metaprogramming world with traits, mixins and templates. If you need even more speed - you can even disable GC and write your hot part with asm and great auto-vec support from GCC/LLVM world.
A pity that Go has a lot more drive behind it from employers
Go is my goto language because it goes
Where does Go go?
@@patrick_jane its going no where for prime
TypeScript, Go, Rust. Polyglot programming.
@@patrick_jane the places Go goes continues to grow as time goes on
Rob Pike knows Go is the go to language for a lot of people to the point that he has to put goto keyword in it
“Your app having complexity that is unmanageable is a skill issue” amen brother
Living is a skill issue
Thought he said a scale issue
Agreed! Modal design can be tricky. Here's a simple fix: .modal { width: 400px; display: none; position: fixed; bottom: 20px; right: 20px; padding: 20px; background: #f9f9f9; }
Go is pretty fun. Cool, that you give it a serious chance.
I love it for prototyping and testing new Ideas. You don't have to worry to much about types, to get things working, but once you want to tie things down, you can type things as strict as you want.
The only hard thing to wrap my head around was slices.
Once I realized that a Slice that is extended over its original capacity becomes a list of clones instead of references, everything was OK though.
Until you extend a slice over its original capacity, all elements in it are references to the original entries, allowing for some pretty fun stuff, when building multiple slices from the same base Array.
I think that depends how you are extending the slice. It's just a pointer to an array plus a size...
@@Rakstawr there is an append function, it returns a new slice.
Append to a slice, whos capacity has not been reached, and you get the original slice back, just with the new element appended.
However, if you append to a slice whos length is equal to its capacity already, then Go creates a new slice, that contains copys of the original slices contents + the appended element and a new capacity. instead.
I understood slices much more as I used them in Python and there is a lot of .
@@AScribblingTurtlethe capacity isn’t referring to the slices, but the underlying array. Slice is really just what the other user described
@@AScribblingTurtleI mean it's pretty obvious. Slice is just a reference to an array. And an array is a continuous block of memory, so if you append and it exceed the memory, you can't just put it in, it will override some memory blindly. So you have to create a new one.
I think this is a pretty great way of going about learning about the mysteries of how humans and teams of humans think about programming. Most languages have unintended consequences as a result of certain design decisions that eventually become crystalized and hard to avoid as it matures. I don't think a lot of people really know if the amazing expressivity and less than amazing complexity of rust affects the human behaviors of programmers working with it without trying something completely different like Go. I'll be following along and will be very curious what some of the unintended consequences of the decisions made during Go & Rust's development get uncovered.
I am with you.
Interesting perspective! Rust's expressivity vs complexity impact on human behaviors is a fascinating topic. Looking forward to your insights on Go's unintended consequences.
Commenter: Just use whichever language makes you happy
Prime: TRIGGERED
Haha, I see what you did there! 😂 Thanks for the feedback!
Looking forward to it! I've been gobbling up your Go content
Gobblin up the GoC
Love your take here, as a relatively new dev I'm currently learning Go and loving it, but I'm super excited about learning Rust next year. I love this idea of dedicating time, like a full year or two, to explore and get good at different paradigms and that's what I'm doing
I really like how there's a word "brain" in his transparent head on 5:40
Nice catch! 🤯 That's a clever design choice.
Too good timing.
Type masturbation is hilariously accurate
Yep, felt real
Nice! Here's a suggestion for the background color: #f9f9f9.
It’s not
type masturbation addict above ^
Prime, you actually one of the reasons iv switched from being node.js developer to Golang dev. Im happy and want to thank you!
I'm kinda of migrating from PHP and Laravel to node because of a job and I'm really enjoying it. But I'm thinking about giving Go a try to see if I like it. The thing is, there are some details that scares me like pointers, bc I did not had a great time learning that on college lol. I wanna see if Go is all that great like everyone talk about
@@porfiriodev pointers in go is simple, you don't need to think of them too much, because of garbage collector. Just understand what it is and when to use it and that's it
Wow, thanks for the kind words! 😊 Glad to hear that my content has inspired you to switch to GoLang. Good luck with your new journey! 🚀
Thanks
Reminds me of the crazy types I would see in TS when I would mouse over a variable in a React app. I watched some of Matt Pocock's TS videos a long while back because I wanted to get better at types, but I kept wondering "Is this level of complexity really necessary?"
I've been building a project in Go and the simplicity feels so worth it. I still catch myself overengineering things and have to dial it back when I refactor.
A lot of the crazy typescript types are necessary to type the things people are used to doing in JavaScript. You can do basic classes and data types and only do that if you want, it's just that people are used to certain (more convenient) patterns from JavaScript.
Matt Pocock is trying to polish a turd , and guess what? It’s still a turd!
Ah, fellow over-engineer! 😅 Go is great for simplicity, but we all struggle with it. 😅
I feel like lots of Go programmers are ex-java programmers who have never did professional programming outside Java (like yours truly) and once they did the shift to go they were impressed by the simplicity of the language, bear in mind half of java is spring boot with all it's features and complexity so it adds more to the complexity and abstraction you have to deal with.
Ah, I see! Many Java devs find Go's simplicity refreshing after dealing with Spring Boot's complexity. 😊
That’s my case. I’m a Java dev and I feel alright about Java itself, but this obsession with that awful Spring thing is just sick. Spring is a monster gobbling up your development time, totally broken and undebuggable, and Golang is a refreshingly beautiful ecosystem in comparison. One of the best things about Go is that there’s nothing like Spring there
I came from Java, Python, JavaScript, and I just can't for the life of me figure out pointers. It makes no sense.
@@aeggeska1 You should try C first, C is very plain and has very little things to learn. But it teaches pointers well.
Hey. I want to get placed in a job and also want to contribute to opensource.Can you tell Which would be good.. Java or go
"This chisel is a rubbish hammer"
Sorry to hear that! 😞 Can you tell me more about why you think it's a rubbish hammer?
I came from learning CS (with C, Java, C# and all the things) to do mostly PHP, some Ruby and ELM in between and a lot of JavaScript until I started to like TypeScript. Now Go is my main-language whenever I can. My first projects where pure chaos, since I was still stuck with JS-brain and trying to solve stuff that way. The more I looked at how go-devs solve stuff the go-way the more I embraced that, and now stuff feels so extremely elegant in it's simplicity. Combined with HTMX it's just beautiful.
What kind of projects do you do in Go, I am starting learning but I don't have idea what to build because my mind is so immersive in Frontend but I need a change
@@enzocam07 I started with some simple webservers. Replicated a few things I did in JS. Then I focused on a smart alarm. A replacement for an alexa echo dot with a raspberry pi underneath. What I also want to are some GTK-Desktop apps. Mainly to fill in blanks in my workflow I haven't found tools for that I like, and to learn a bit more about desktop-programming. Even tho go might not be the best for that, it still is better then electron.
Impressive your journey. What’s the the main or top 3 ups of go compared to the other languages you handled?
@@mauricioramirez2855 I just like the language which helps. But if I had to pick... Errors as values, the standard-library, and simplicity.
honorable mention to god-tier concurrency, BLAZINGLY(tm) fast compiles and the elegance with which you can solve a lot of things.
I remember discovering your channel and being appalled that you were bashing Go. You've come so far ❤
Wow, you've come a long way since your early Go-bashing days! 😊
Go builds and runs on almost anything-any OS, any architecture. It cross-compiles from anything to anything, statically links during cross-compilation, and doesn't care about glibc, bionic, or GPL drama. It has a built-in concurrent garbage collector and comes with everything you need out of the box, handling 90% of what C, C++, or Rust can do without the headaches.
I have been writing php code for years. I starting to use go whenever I can because of how simple it can be to learn and all of the powerful choices it has made for a language go is really good and I want to find a way to write more Go code.
I think Go will help your Rust since it will help you surface simple designs. I think this is how Tower came about. Before Tower, Rust web libraries were proc macro all the things, over complicated messes. They're powerful but if you get compiler errors, you need to use your galaxy brain to figure out what the heck happened. Well I'm sure someone saw how Go's handlers work and this completely inspired Tower and it's very simple and straight forward and composable.
When you write stuff in GO you are thinking about program you are doing, when you write in RUST you are thinking more about language and less what you want to achieve. This is dealbreaker (at least for me) when it comes to productivity.
Similarly true for java and c# as well.
100%
I actually find Rust has less of that problem for me than Haskell. It's because the type system is slightly less expressive, at least, without macros.
However, in C# I find myself spending too much time wondering what the simplest way to do something is, because it's so low-level that the simplest way to do something often looks complex.
So it ends up being a different kind of type masturbation. I'm very happy with Rust so far. (I started using it this year.)
Same with modern c++. Main reason why I switched to Go
Если среди разработчиков чувак придумавший ( со товарищи) чистый С и Unix, то go по определению не может быть говном! Жаль что чуваки сразу не подумали что модель исполнения (все статическое) + goroutines отлично подходит для baremetal микроконтроллеров софта. Но вроде наконец появился tinygo.
I definitely agree that there is no best language, there is just the best language for the situation. Sometimes it's a language you don't know yet. Insisting that there is only one good language is like saying welding is the only way to join two things, and if you can't weld those things you're using garbage materials. And then, a classical Japanese woodworker casually drops off a joined set of beams and says, "this survives a 6.0 earthquake in a 4 storey house" and walks away. No glue, no nails, no screws.
Always be learning.
Other languages exist because they solve a problem that existed when they were made. Sometimes they jump the shark and are brought where they shouldn't (looking at you, JavaScript), but there's still the core concept in mind, and you will know that it's the right idea to solve your problem when the time comes.
I did one big project in Golang and had a wonderful time. The suck started when using a graphics/sound library that had terrible performance. I kinda feel like giving it another go (hur-hur) after last year's C# excursion. I should give Rust another attempt but Golang is so much more comfy.
Perhaps that's where you shouldn't use the language. It is a language designed for the web, writing servers, and clis. So using it outside of that bounds I'm not exactly sure where it fails
@@ThePrimeTimeagenebiten is a pretty nice game engine for go, though.
Maybe try raylib with the go bindings?
@@Pabloparsil Maybe! I've been following it for a while and want to try it. Do you have experience with it and Golang?
@@amodo80 It's OK but it gave me a lot of pain actually. That's the library I was referring to. The shader system is kinda bad and dynamic audio synthesis is extremely laggy.
Is there any flavor of rust that disables syntactic sugar and fluffy features? I.e. if I basically want C with borrow checking and Rust compatible syntax?
I've been debating between switching from TS/JS to Rust, Go or Elixir and I decided to go with Elixir and I'm over the moon with it. I didn't think i'd like it as much as I have. Functional programming and the actor concurrency model has completely changed how I go about solving problems. It may not be as performant as Go or Rust but I write better structural code with it. Its understated how much of a quality of life improvement that has had that I was not expecting at all. There are also packages like Rustler that allows you to use Rust directly in Elixir if you need performance critical operations. I don't see myself leaving the language for quite some time.
I can't get over the fact everyone is using Phoenix for building web APIs even w/o liveview, and the amount of boilerplate it generates.
The thing I miss the MOST about Rust when moving to any other language is Rust's enums combined with match. Legendary features.
Even PHP has that now.
dart has it too
@@razvangrigore322 PHP.. no joke, is actually quite nice now.
Agreed! Rust's enums and match features are top-notch. 👍
00:41 loses only to typescript right? RIGHT?
I love this take. I write C# at work. How many times have I debated with colleagues whether such or such code should be an extension method, an abstract class or whatever else the language provides. By removing these options, Go shuts down all this useless chatter.
Thanks, glad you enjoy! C writing is awesome 😊
Go for me this year, too. I’m taking your Go and HTMX lessons and other Go lessons on Frontend Masters.
Your description of Rust is very close to how I felt when I was into Scala. I ended up ditching Scala for Go and never looking back.
I disagree slightly that using languages you really like gets you stuck using only that one or its associated paradigm. Personally, I've been having a TON of fun using Scala as my main language lately because I just like the way it feels (it has a lot of similar features that I love from Rust, but without the memory management), but when I need a more functional language, I tend to immediately reach for F# or Elixir (depending on what is needed for the project). If I want to practice OOP, I tend to use C#, Kotlin, or Ruby. Lower-level stuff gets Rust, C, or Go. I think you get the point...
For me, using those different languages was a way *to break into* new paradigms, not get stuck in a single one. In fact, a lot of times I get really bored if I have to use the same language for a lot of projects in a row. I dunno, maybe I'm the outlier, but I just think it's neat to see how different languages handle similar (and also different) scenarios.
"but when I need a more functional language, I tend to immediate reach for F#", clever guy! 😉
I mean, Scala can handle functional programming just fine. My point was just that if what he was saying was entirely true, I would've just stuck with the one language over choosing several.
Also, unrelated, thank you for bringing my attention to a typo that I missed!
@@Me-wi6ym I meant that as you use F# you are clever guy. I didn't notice the typo.
F# is a very good language. I started using it 2 months ago and migrated immediately a lot of my C# code to F#.
C# is a little bit too verbose (Java heritage) and I like a lot the functional approach in coding.
Having all the .NET ecosystem available when using F# , its great operability with C#, its great transpilers (Fable) make it a very good choice.
Its really a expression of the individual. Prime's telling on himself and how his brain works. It is very transparent of him to expose himself like that. I've seen these brain types before. They lock on to an idea and go full ape. But prime has learned to tame that ape. The ape brain can self reflect real good now.
Some programmers (or humans) hate switching paradigms or modes. Their brains literally don't have the idea hopping genius and correlation. It takes time for their brain to build up neurons that can grow at will.
Ah I see. I assumed you were mocking the obvious choice of F# for functional programming since that's what it was designed for, my mistake.
I personally love F# and it makes me kind of sad how little it actually gets used in the job market. I wish Prime would try it; the syntax is almost identical to Ocaml, at least for the important parts (if I'm remembering right, they handle OOP differently, but you don't use those languages for OOP anyway). I'll bet he would actually really like it
C# is amazing. I find myself spoiled by C# and its ecosystem. I move to other languages and miss C#. But I have been starting Rust and am building a client project with it. But I think I am going to start with Go. Flexing my brain is why I want to do this!
Genius adores simplicity over complexity
rust allows simplicity to mask complexity in a very nice way
When you are a genius, stuff looks simple which is actually complicated.
Obviously not true for all cases but I have seen it happen a few times.
@@aodhaiC++ allows simplicity by basically coding in C
Imo one should try all combinations of high-level vs low-level and simplistic vs complex with at least one programming each (so yes, at least for PL).
Obviously they shouldn't try all at once and from the get-go (and in general a starter PL shouldn't be a complex one, beginners already have enough other stuff to deal with (you would be surprised at how many people struggle with understanding the concept of recursion in the beginning)), but over time one should do this.
And after having a decent amount of experience in each category, then go and start judging them against each other, but don't be surprised if not everybody agrees with your conclusion.
The more time I spend using Go the more I find interfaces really elegant. Refactors and testing become a breeze and they make the code feel super nimble
At the end of the day, I find it joyous just to be able to learn new programming languages. It feels like I'm taking a peek into the brilliant minds that created them: a whole new universe to explore!
9:05 This is where the ease of learning Go is amazing, because introducing it to your team is a relatively easy way to escape a worse language by starting work on a new project in Go.
Stuck in the hell of using dynamic programming languages for large projects, or of using them for applications that need performance? Go is an easy sell and is so much nicer to work in.
I know nothing about Go. I know C but just the single-threaded C, not multi-threaded. How does Go solve the issue that Rust's borrow checker solves?
7:52 hahah, that's funny because i'm just barely starting Go, and the thing I don't like is the := thing. I just don't like way it looks haha. I feel ya man.
I started in TypeScript. I learned Go as a job requirement. I now write better TypeScript because of conventions Go introduced/enforced.
Why I don't use golang in 2024: my company loves paying hundreds of thousands of dollars in server cost a month because "PHP devs are cheaper"
hhhhh
im not sure php really raises server costs all that much as much as i dont like php.
@@koalakakes it does. It does A LOT. Rewrote a service in go. Went from $6k a month to
Sorry to hear that 😔. Have you considered exploring alternative options for cost-effective server solutions?
After I transitioned to Flutter I found weird how simple Dart is, now I love it.
What do you use to parse .templ files in NeoVim? I use coc-go for .go files but I didn't find anything for templ
For functional paradigm, Elixir is undoubtedly the choice, looking forward to your Elixir series xd
Elixir is cool. I spent all of december and january using it 10-20hrs / week. i’m sold it’s the solution for small teams. Phoenix is Rails but better.
Undoubtedly the best? Have you compared it to Lisp, Clojure, Haskell, Ocaml and Rust?
I haven't tried Elixir yet, so I can't make a comparison myself.
Elixir doesn’t have types, which are a must have for most people
@@harrybarden5438 So everything's a string? No arrays, no numbers, no hash tables?
Yeah Elixir is the best lang.
i have only one question why are people choosing go or rust over c or cpp? What am I missing. i mean if c and cpp is fastest what else you need that go or rust are doing better.
go is far easier than c++ and rust is for bragging rights
speed isnt the most important factor depending on the situation
Funny you mention the if statements and snake case being a turn off for Rust initially. The one and only time I tried learning some Go a few years ago, I discovered the compiler forces opening braces to be on the same line. I use new line curly braces, and I hated Go forcing new line upon me so much I quit after the first exercise and haven't revisited the language since.
I'm also more or less all-in on Go at this point, but to the point about enums, interfaces and enums are complimentary. Enums are great when when you need a fixed number of data options, but unbounded behavior options, while interfaces work when you have unbounded data, but a fixed number of behaviors. Interfaces are great for representing things like streams, which go does, but awful for representing deeply nested data structures, such as syntax trees. For this reason, I believe enums would actually be a valuable addition to Go. They added generics, so anything's possible.
I have been using Go at work for few years and I am trying to become proficient with Rust. I like to learn new things and Rust ticks that box perfectly. Which one I like best? I love them both.
I find myself often writing really verbose workarounds for simple expressions in other languages. I think something that writes like Python with the speed of Go would be the best. For me, Python is the closest language to imperative paradigm pseudocode.
Hmm. Could that mean you're not writing idiomatic Go code, yet?
Translating from English can result in long, awkward phrases; and the same is true when translating into English, too
It's funny how things don't feel verbose until you realize there's an alternative. When I was doing primarily Go for a while in 2017 - 2019, I really missed having either something like list comprehensions, or map/filter/reduce. And yet I had spent years happily writing for loops in C and pre-Streams Java.
@@creativecravingfor example, take a simple ternary operation.
x = 2 if thing else 3
in go this becomes
x := 2
if thing {
x = 3
}
Lots of small things like that cause a great deal of mental friction while writing simple code
Ive been an AI and game dev for 6 years and this is so accurate. I learned to like each language the way it is. Even down to colour tbemes. I use jetbraind ides and python c# and javascript is what i use mainly and each one i have a different colour theme that somehow suits the langauge for some reason and im pedantic in each one respectively about its own syntax and styling. This just happened over time with using then all enough for different tasks.
Tom loves Go for a reason
I miss your old hair Prime. It looks nice but very distracting for my caveman brain. I just tune out everything and focus on the hair.
Haha, This is what happens when you lose a bet, it'll be gone soon
I'm switching to go too. İ need something modern and well designed. But most of new languages are very strict and complicated to start or worse they force to use a specific framework. i like go's philosophy
Go got that dawg in him
this week I found out go doesn't even have immutability
One of the benefits of Go is also that it's easier to make open source projects. People who do not know the language can easily understand it and even sometimes submit fixes or PRs.
I felt the same about snake case. I thought it was weird at first coming from Java, but it's so much more readable! Not as convinced about the parenthesis tho.
5:44 We gained union types in Scala and I can only disagree. Together with singleton types we can have types like `"lts" | "exp"`. Do I need an interface or an enum just for that? Well you just said that a simple language does not mean complex apps. But now it's proving the point that I need to make my app more complex because the language does not have that feature.
Few things that would make Go beautiful in my opinion:
- tagged unions
- operator overloading (had to work with big.math for past 2months and I hate it)
- syntax for error bubbling (no if err != nil)
I think it's unlikely that I'll be getting any of the features above, but that would really be lovely. I don't need anything else from the language, but even rn go is good enough that I use it despite lacking things described.
Java has this thing called Virtual Threads, which is essentially the same thing as Go Routine I think. I don't know anything about Go, but isn't Go Routine the most important feature that Go has to offer and everything else about Go is pretty much the same as other languages ?
There was no blue hair dye, Prime became a gopher naturally
i have issues with go and especially with its type system. remapping json for different services is pain especially if one thing sends you json with nested arrays in it. i try to avoid reflection all the time because it just makes things much harder to maintain. interfaces are another issue, because majority of libraries just accept interface{} and god knows which interfaces even must be implemented. it's either skill issue or I'm trying to do what go wasn't created for.
I just wish go would add a short way to handle null pointers.
Something like `variable?.property`. I don't believe this goes against any of go's principles of simplicity, but it does make the language much faster to write and easier to read when you have a lot of possibly nulls to handle.
Looking forward to learning go with boot dev
hey, what's the number one type system you've seen then?
There's a nice quote I like: "Programming languages are tools, not religions"
I've started using Go for most things as a security engineer. I mostly build microservices like AWS Lambdas to solve security problems which i think lends very well to the simplicity of Go. You already have a 'simple/micro' problem to solve and then take a language that succeeds in that simplicity and it is just beautiful.
I switched to Go last week and it's nice to see you're doing the same
i had this same issue learning rust. tried to port a calculator app but damn did the syntax fuck me over. everything felt so messy compared to when i did it in c++ or java. just a skill issue, but is something jblow also said himself.
gave up on rust for now since my main goal is to get a job using c or cpp, and i think zig would be a more enjoyable and skill transferable language to learn.
Parts of what was mentioned in this video confirmed me even further that learning programming languages is not much different than learning culture languages. Gotta think in that language in order to succeed more than thinking on your mother base language and keep translating. Meaning can get lost easily.
You refute the thesis that “complexity is either in the language or the application is a dumb take” by telling how generics led to simplifying code everywhere, including Go’s standard library.
Previously, Go authors were very much against generics, then they were putting them off “to make them just right”, and now they have it and it has simplified lots of things.
So I guess the take is not dumb, it’s true in fact, but it has limits. Like when you have essential complexity you cannot reduce further without detriment to solving whatever problem you are trying to solve. There’s _also_ a lot of unnecessary, self-inflicted complexity.
Who knows, maybe using just a little bit of inheritance and java-style exception handling could simplify even more things? Maybe not, but what if? Or should we be uncritically burning heretics for merely uttering the forbidden keywords?
Go devs weren't against generics, it's a myth. Their site, since 2013 , said they wanted to add them, but had no idea how to make them simple
Go is great for backend webby stuff. First class language for backend web development and very nice for CLI. However, I would never use it for high performance or system programming. It's a language not designed for those areas. As a C programmer, I love Go. So for all you webby folks, if you do Go on the backend, native JS on the frontend, and use websockets to connect both sides, your website/webapp will require minimum if any 3rd party dependencies.
I was once doing an app in Laravel with Svelte, and I didn't know how to set up Svelte with TypeScript. I love TS because of the type system, the hate against JS, and bla, bla, bla. So I said -Well, fk it, I'm going to rawdog JS for a while. Some time later, I managed to compile TS with Svelte, and I was happy; I would be able to use my beloved type system again! But... but then I realized that the modules and the logic that I had done with JS was much more simple, good and, overall, easier to understand. In TS I was worrying too much about generics, types, interfaces, trying to make traits, mixins (search that one out and tell me I'm not dumb).
I think about that now... maybe I want a simpler language, with simpler tools to just get the job done, and not lose myself with all of that funcional, OOP jargon and stuff.
Love you prime btw ❤
This is so true. When I came from JS to python and saw no semicolons I hated python. I still do but I have learned to love python. I think I key is to learn to love and focus on the problem not the tool
As much as I hate the self-serving fanboi-ing over a language, I really think these sorts of arguments miss why people like Rust. I hate the foundation, mozilla, etc. and have every possible reason to be biased against Rust, but at the end of the day when I first began using it it *_felt_* like how programming *_should_* feel in my head. Same thing happened when I switched to Linux, it *_felt_* like how a computer *_should_* feel in my head. It had the features I never even questioned why they were missing, it removed the flaws I never even questioned why they were there, and it gave me flexibility I never even knew I didn't have.
When I try to do something in Rust and find myself fighting the compiler, (note : that isn't always the borrow checker either!) I invariably find out at some point during the debugging/research process that what I was trying to do had more complications that I wasn't aware of previously. Not in the stupid "XY problem" way which is just used as an excuse to avoid answering the question that someone actually asked, but in the "oooooh, that makes sense why I can't do it this way, it's not possible" way. For instance, I don't do "hello world"s, I just don't, I've never found them useful to learning a language, so for my first project in Rust I tried to do a little embedded LED blinker project with an Arduino and had issues assigning arbitrary pins to be used to drive the LED. This wasn't a real issue for the project mind you, but I was cobbling things together from different sources and noticed that they didn't cleanly click, so I wanted to implement it fully and 'right'. In the process of making that very simple blinker I learned about impls, dyn traits, etc. and, after more work looking into embedded, I have a much clearer picture of why what I was doing wasn't easily possible. (of course I don't know for *_certain,_* but typically output pins are memory mapped or otherwise 'linked' as one unit that you assign values to collectively, sort of like output pins in a shift register. To that end, of *_course_* you couldn't just pass in completely arbitrary pin numbers, because the math to get a 1 or a 0 in that specific position is different and requires different instructions)
Debugging pre-runtime (not necessarily even comp-time) just *_feels_* right, you generally have some assurances, you can speak about your code with confidence, and you can, generally, be sure you understand what's going on with your code, or rather, you can be sure that you don't *_not_* understand anything going on with your code.
As a language these aren't magically intrinsic benefits - and yeah, sometimes it's annoying and feels like you're having to beat your head against the wall to do even a basic task - but at the end of the day *_knowing_* you didn't, intentionally or otherwise, take any shortcuts and that you're final result *is* comprehensively valid is invaluable. Your final result works, and you can say that with confidence. If, for some reason, there *_are_* any esoteric bugs, it's either a problem with someone else's code or it's isolated to your very clearly designated unsafe blocks. When you're making small throwaway utilities that's not meaningful, but when you're making a project or even a full application? Yeah, that matters. There are times you want types, and there are times where god damnit you just want to assign an ASCII character to a bloody i32 for some reason. If you're making quick throw-away applications or something then yeah C or Go or some other "get the fuck out of my way" languages are good, but that's not what most people do. "Minimum viable product becomes production", and with Rust you literally cannot help but make MVP at least production grade because the compiler wont let you.
Yes, people who dont understand what advantages we have with Rust are just blind and dont give Rust a chance.
I recently did some programming in Haskell to get a feel for it, well technically PureScript but same thing for all intents and purposes, and had the same experience, modulo massively better error messaging in Rust. I'd run into an error, spend a bunch of time trying to figure out why it was complaining and swearing at the compiler only to realize I messed something up or neglected to consider a possibility-at least Rust is nice enough to even suggest fixes. Once I accounted for that possibility or fixed my mistake, everything compiled and the app ran without any errors. There's plenty of other languages from dynamic ones like Python and JS to even just weaker static type systems like Java and Go where it runs but either doesn't output the right result or what seems like an innocuous change causes all kinds of issues that seem like they came out of nowhere but actually just lucked into not being hit.
I do think Rust is overkill for a lot of projects since many don't need deterministic memory management, but there's a ton to be said for the compiler keeping you honest and informed. If I could have a GCed language with Rust's level of error messaging and as conscientious a compiler, that'd be my go-to language in a heartbeat.
Got the same feeling with assembly language. Code in assembly feels like a true computer program, you don't need to have it rewritten by some compiler. It's perfectly aligned with how the computer works. It's not hiding anything. It makes perfect sense.
@@ITSecNEO I mean I'd argue Prime has 'given it a chance' as much as anyone can be reasonably asked, I just don't think he's used it in the way most people will or will want to. To me at least, Rust's one big advantage is it's explicivity. Both the compiler *_and_* future readers of your code (yourself included) can clearly and confidently know what it's saying, what it's trying to say, and if/when those two things don't match or might not match. (within reason) The compiler then takes that information and *_forces_* you to either rectify the problems or mark the parts where you smeared your shit against the keyboard and told the compiler to make it be a program today and someone else's problem tomorrow. (which, as I'll hopefully reinforce sufficiently later, isn't necessarily always the wrong route - not all code *_needs_* to be provably production-grade)
When you're writing command-line utilities and the like (which Prime explicitly said is what he used Rust for) then that *_will_* just get in the way more often than not. The loosey-goosey typing and lasseiz-faire semantic rules of something like Python, Javascript, Go or C are excellent for niche little utilities that need to just do a job, do it reasonably well, and not take a ton of time to make. Rust's main value, at least as I see it, is that it forces you to have better practice than that though. Not in the "oh well this is more clean and idiomatic" way, but rather in the "where the *_fuck_* do you want me to put this string?! Do you want it on the bloody stack or the damned heap FFS?!" way that forces you to understand and reason about the things you're actually asking the computer to do. This means you can be (reasonably) confident that your final product is solid and robust, at the cost of requiring much more (and much lower-level) reasoning.
Rust *_is_* (likely) more of a hinderance for the problem-space Prime used it in, and I don't think that counts as him 'not trying it'. I *would* agree that I don't think he's really understood why people value it, but I wouldn't say he hasn't tried it. I just think his usecase for it is rather niche in comparison to what most people would use it for, and he hasn't really thought beyond that application-space. (which, to be clear, I *would* still say is a flaw on his part, but speaking without realizing other people's perspectives is far less of a problem than speaking without even realizing your own perspective first.)
PrimeDaddy has announced his Gopher status, now let's see how popularity in their subreddits change over the next 6-12 months. As of today, Feb 15th, 2024:
Golang => 238,000 subscribers
Rust => 274,000 subscribers
i'm still on the rust train but i totally get what you're coming from. when i use go it feels like it's lacking features. i know that can be a positive thing but i don't like that. for prototyping or very simple apps, i do like that, but when it comes to actually building something i don't. i also enjoy the "process" of writing rust code and thinking through problems in that way.
Go isn't my favourite language at all but it's honestly so easy to be productive in and the tooling is great so I'm finding myself enjoying it more and more!
Maybe algebraic data types are best in domains that require sophisticated data semantics, and a simpler type system is good for a more performance focused domain that has less semantic complexity?
You can prove that language complexity matters by taking it to extremes.
Some of the simplest languages are lambda calculus and combinators languages.
I think one of the simplest languages possible is "Subleq". It has only a single instruction: "SUBtract and branch if Less-than or EQual to zero". Fully Turing Complete in one instruction. What could be simpler?
On the other extreme, we could have a dedicated syntax for every single unique operation, which would require an every increasing vocabulary, though every program could be a single symbol in such a language. What could be simpler?
Obviously neither of these extremes are desirable, but we need to find a happy medium.
Great advice here. Make sure you are idiomatic in the code you write, so you can learn what the strengths and weakness are for the that tech choice.
C and Go are my "Go" to for most of my projects
goto golang;
New to golang. Can someone explain to me how to deal with the annoying issue of reading data from a DB and handling NULLs. Always get that annoying scan error when getting data from another source with my microservice in golang. Is there a short way to just cast null to nil or is it really taboo to do that.
thanks so much for taking the time to share the knowledge. Appreciate it.@@FraserChapman
whatever you do don't use pointers it will make your code disgusting to read
Glad to hear this, it will be interesting to hear reflections after six months.
Go is the king🏆 Hope it keeps get updated and get better and better💫
I have become a Go maximalist. Whenever I'm using another language I just keep thinking "I bet this would be simpler in Go."
I’ve been using rust a bit a now. I used to be a big hater but it’s chill now.. the type system is nice, just works and casting is very forward.
Also less buggy for sure, if the rust app builds it’ll probably run smoothly for the most part - opposed to C++ builds you run will come across unknown bugs you have to manually debug now.
I do wish you could have no brackets for single line statements though, I’ve always found using brackets for single line statements nasty but now I’m force lol
The Go fundamentals course in frontend masters is pretty good to get an idea of it
it's interesting how we kinda swapped around the same time. I've always been a sort of Go fanboy but I've started learning Rust last week and I'm genuinely enjoying it.
Hey dude, I'm sure this will get lost in the comments, but I wanted to know your opinion on languages for cybersecurity. I was thinking Go or python. What are your thoughts. Thanks bud.
I love Go, because it's so easy to join a new team or project and pretty much in any case, be productive right away. I've joined some Java projects in the past and if the project was large it always took me a decent amount of time to ramp up before I could really start contributing.
Go and productivity? xD Good laugh bro. Its not about writing code fast, the whole ecosystem matters for productivity. And Go's ecosystem suck*, they not even managed to release a good formatter. You definetly need to read more about languages before you decide to choose one...
@@ITSecNEO Bad troll
@@ITSecNEO When your executable is built and ready to use, you don't care about the formatter anymore. And I have been impressed by how fast I was able to get that executable ready, starting from zero knowledge of Go.
@@brinckau Deploying Code is the final of development ^^ The Rest of the time you will code or test your code. So obviously, a formatter matters a lot during dev.
@@zelllers You say troll to me but you arent even able to discuss. Well, maybe because there is no need for a discussion because everyone who used Go in companies, will know that the ecosystem is bs :) Only thing you can is to raise the troll card on me. Again, leave your Go bubble and do a proper research about Go and the bad design choices. Start with fasterthanlime articles on this topic and you will understand
Go is great and you're right - a language is more than a tool. Great languages come with coding patterns and a PoV and you have to embrace it or your code will suck.
Great insights shared, thank you.
I recently created a basic benchmark to compare Odin and C. Yes, I know how hard it is to make meaningful benchmarks, but I wanted a rough idea. (this is relevant to the video btw)
I made a singly linked list, started with 6 elements and added up to 1000 one at a time. Each time it added an element, it did a basic linear search to find the end and add the new node there. I then deallocate the whole list. I ran this 1000 times and averaged out the time it took.
I found Odin took about 2.4ms per run. Unoptomized C took about 7ms, and then compiling with -01 or higher landed C at 0.5ms roughly. I'm still not sure exactly why the time discrepancy, but they are pretty close.
I then wrote the exact same code in Go to see how close C and Odin really are in performance. I expected a garbage collected language like Go to be a lot slower than either manual memory management implementation. The average time for Go was about 5 microseconds, or about 100x faster than C.
Either Go is optimizing away the whole process, or my best guess is that the garbage collector actually makes it more effective. Now, both my C and Odin code is very naive. I simply call malloc/new every single time I create a node. I'm guessing Go is able to create larger allocations and split them almost instantly per each node. At least, it's my guess that malloc is the bottleneck. I can't imagine why linear search would be any faster in Go.
Is this to say Go is faster than C? No. Because the code isn't the same. I could create a better allocation strategy in C and get better performance than Go. But I think this is a very important idea. Yes, if you write the correct code, C is faster than Go. But with equivalent code with equivalent work put in (actually, Go was a lot easier to write than C), Go can be a lot faster. I assumed even a naive approach in C would have to be faster than any garbage collected language. It's manual memory management, how can it be slow? But a naive approach in C is much slower than a naive approach in Go.
And this is a major part of the value of Go. Not only is Go much faster and enjoyable to write than a language like C, it's simply easier to write performant code. You don't have to study allocation strategies and optimize for your specific problem. The language will likely do a decent job and get you 90% of the way there for most things.
In before my Go program was actually cheating and not performing the same thing. I also ran the benchmark in Python btw. At first it took 3 hours (cause I had an infinite loop) but then it took 17 minutes total, with something like 106ms per run. Classic python.
Edit: I also ran go using "go run" rather than building since that should in theory keep it in debug mode and not risk optimizing things away. It was 5x slower but still way faster than C.
Welcome to the club, Gopher! Go is amazing for CLIs, backends, data transforms, and even the PyTorch lib is bearable for Go. It is a wonderful language for what it’s built to do. Some people even code games in Go which I’d like to try since there’s libs for a few engines.
I tried Go ~4 years ago, thought the syntax was strange, and I didn't really give it an honest chance, just dismissed it as "yet another language". About a year ago I gave it another chance, and ended up really liking it once embracing it as its own thing. It is currently my "go-to" language where it makes sense, so I am happy that I gave it another shot.
I got the same thoughts about syntax and readability. Can you recommend some approaches to start from and clear old-used-language brain?
@@bot1511 It would largely depend on your background, but nothing really specific beyond just "use it". Once you start creating more complex applications beyond tutorial-esque examples (might have to just slog through it at first), the design choices, which seemed odd begin to make moe sense and feel natural. Other things like the order of types/variables just need to overcome the muscle memory of doing it the C-style way.
Embracing the "functions are first-class values" and "composition of inheritance" paradigms and using them effectively also helps break the old habits.