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.
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
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.
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.
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
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.
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.
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 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.
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 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'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 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.
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.
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.
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.
8 месяцев назад+1
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.
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.
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 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'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.
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
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
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
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
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.
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!
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.
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.
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.
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.
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
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.
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?
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.
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.
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.
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!
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
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.
I was waiting for you to come around to Go! I'm a nerd like you and like powerful languages with all the bells and whistles. But when it comes down to real life, Go is simply more practical for most cases. It forces you to do things one way that's simple, stripping away what you don't really need. Go isn't perfect by any means. But for most projects, when you take ALL factors into consideration (including for example speed of development and readability), generally speaking Go will come out on top and the obvious choice. The fact that it's garbage collected also doesn't seem to have that much of an impact on performance for general use cases. It still performs in the same league as other low level statically typed languages.
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’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
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 had started programing 6 years ago, with JavaScript. To me, was the GOAT language for everything. Now, typescript still the majority part of my salary, but i see Kotlin and Go as the best well design, go for, language.
Typescript is still the best typing system I've worked with so far, even though I prefer statically typed languages, the way you can play with types is really powerfull, unfortunately there's nothing like that in statically typed languages except for rust, but to achieve the level of flexibility typescript has you need macros
The downside of bouncing between popular languages - which was my first 15 years or so of programming - is that all of them are iterations on "Fortran" (to borrow Forth creator Chuck Moore's sentiments) so you don't get to spend a lot of time doing anything really wild - you get to consume a type system that's a little more or less sophisticated, and some new libraries. The stuff that isn't a Fortran, no corporation wants to hear about, and the barrier to casual usage outside of that sphere tends to be much higher as well - less documentation, example code etc. I bring up Forth in part because it's the "simple to implement" kind of simple; implement a tiny core and then bootstrap the rest and you have a Forth system - even the IF ELSE THEN statements can be metaprogrammed in a minimal Forth. Does that make it productive like Go? Not exactly. I've been using it for retrogame coding and I like debugging Forth because it has the repl interactivity you need to really drill down and craft a very exact implementation of something. But it does not "help you with that" - it's just a thin layer of glue over chunks of assembly code, and its approach to memory management is to bump the allocation pointer word, "HERE", as you declare new words. One of the first things you will do as a Forth beginner is crash it by inverting the order of source and destination in the write-to-address word "!". So in practice, I've got a setup where I have Lua generate Forth source. I can write Forth directly and push it upwards semantically by metaprogramming, or I can treat it as a dumb stack machine and implement some compiler semantics and just use it to debug. It takes me much longer to build solutions than if I were in my usual comfort zone and leveraging libraries and all of that, but as a hobby exploration of computing, I finally feel like I get to understand my spec very precisely, since ALL the magic parts have been removed. I'm throwing a great deal of engineering brainpower at some very small problems.
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 ❤
Back in 2012~ i was a PHP developer and at my job tthere was a coworker who used C/C++ style parentheses for class and function declarations and if/loop statements, meaning even the leading parentheses are always on a new line. It was such a minute and irrelevant thing but annoyed the shit out of me when i saw it, especially coming from a Java background originally. Year later i somehow love it and much prefer it to in-line leading parentheses, and now im unhappy in most modern codebases where its not done that way lol.
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.
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.
Go is what happens when php graduates and goes to university. Sometimes it feels procedural and then other times it feels more broken up into packages but it’s the obvious logical choice a php dev like myself can to move into, start embracing type systems and compiled performance. Give it a shot, you’ll be surprised at what you might learn
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?
In my experience, the amount of context that you have to keep in your head with Rust is extremely high. Over time, and we’re probably talking years for most people, a lot of it becomes more muscle memory / lizard brain, like driving a car. At that point the potential is phenomenal, but it takes a good while to get there. I’m not there yet :).
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?
My minor complaint with Go is that you can't add whitespace with operators. Other than that, i love how Go makes you think if you can simplify a problem
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.
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 ?
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?
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.
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
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
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.
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
Looking forward to it! I've been gobbling up your Go content
Gobblin up the GoC
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! 🚀
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! 😊
"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 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
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
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 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.
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. 😅
“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; }
"This chisel is a rubbish hammer"
Sorry to hear that! 😞 Can you tell me more about why you think it's a rubbish hammer?
Commenter: Just use whichever language makes you happy
Prime: TRIGGERED
Haha, I see what you did there! 😂 Thanks for the feedback!
Thanks
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.
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 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.
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'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.
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.
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 ^
Go for me this year, too. I’m taking your Go and HTMX lessons and other Go lessons on Frontend Masters.
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.
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 switched to Go last week and it's nice to see you're doing the same
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.
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.
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!
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. 👍
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.
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 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 😊
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.
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
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
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
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
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
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.
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.
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!
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.
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 started in TypeScript. I learned Go as a job requirement. I now write better TypeScript because of conventions Go introduced/enforced.
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.
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.
Looking forward to learning go with boot dev
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
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.
Glad to hear this, it will be interesting to hear reflections after six months.
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
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.
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.
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.
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!
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
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.
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.
I was waiting for you to come around to Go! I'm a nerd like you and like powerful languages with all the bells and whistles. But when it comes down to real life, Go is simply more practical for most cases. It forces you to do things one way that's simple, stripping away what you don't really need. Go isn't perfect by any means. But for most projects, when you take ALL factors into consideration (including for example speed of development and readability), generally speaking Go will come out on top and the obvious choice. The fact that it's garbage collected also doesn't seem to have that much of an impact on performance for general use cases. It still performs in the same league as other low level statically typed languages.
After I transitioned to Flutter I found weird how simple Dart is, now I love it.
Go is the king🏆 Hope it keeps get updated and get better and better💫
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.
Great insights shared, thank you.
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
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.
There was no blue hair dye, Prime became a gopher naturally
I had started programing 6 years ago, with JavaScript. To me, was the GOAT language for everything. Now, typescript still the majority part of my salary, but i see Kotlin and Go as the best well design, go for, language.
Typescript is still the best typing system I've worked with so far, even though I prefer statically typed languages, the way you can play with types is really powerfull, unfortunately there's nothing like that in statically typed languages except for rust, but to achieve the level of flexibility typescript has you need macros
this week I found out go doesn't even have immutability
The downside of bouncing between popular languages - which was my first 15 years or so of programming - is that all of them are iterations on "Fortran" (to borrow Forth creator Chuck Moore's sentiments) so you don't get to spend a lot of time doing anything really wild - you get to consume a type system that's a little more or less sophisticated, and some new libraries. The stuff that isn't a Fortran, no corporation wants to hear about, and the barrier to casual usage outside of that sphere tends to be much higher as well - less documentation, example code etc.
I bring up Forth in part because it's the "simple to implement" kind of simple; implement a tiny core and then bootstrap the rest and you have a Forth system - even the IF ELSE THEN statements can be metaprogrammed in a minimal Forth. Does that make it productive like Go? Not exactly. I've been using it for retrogame coding and I like debugging Forth because it has the repl interactivity you need to really drill down and craft a very exact implementation of something. But it does not "help you with that" - it's just a thin layer of glue over chunks of assembly code, and its approach to memory management is to bump the allocation pointer word, "HERE", as you declare new words. One of the first things you will do as a Forth beginner is crash it by inverting the order of source and destination in the write-to-address word "!".
So in practice, I've got a setup where I have Lua generate Forth source. I can write Forth directly and push it upwards semantically by metaprogramming, or I can treat it as a dumb stack machine and implement some compiler semantics and just use it to debug. It takes me much longer to build solutions than if I were in my usual comfort zone and leveraging libraries and all of that, but as a hobby exploration of computing, I finally feel like I get to understand my spec very precisely, since ALL the magic parts have been removed. I'm throwing a great deal of engineering brainpower at some very small problems.
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've been doing go for a while in production and it's been frankly good. There's a lot of missing things though
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 ❤
Back in 2012~ i was a PHP developer and at my job tthere was a coworker who used C/C++ style parentheses for class and function declarations and if/loop statements, meaning even the leading parentheses are always on a new line. It was such a minute and irrelevant thing but annoyed the shit out of me when i saw it, especially coming from a Java background originally. Year later i somehow love it and much prefer it to in-line leading parentheses, and now im unhappy in most modern codebases where its not done that way lol.
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.
Talk more about what you mean by overcoming Arc 👀 I wanna graduate too
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.
00:41 loses only to typescript right? RIGHT?
Go is what happens when php graduates and goes to university. Sometimes it feels procedural and then other times it feels more broken up into packages but it’s the obvious logical choice a php dev like myself can to move into, start embracing type systems and compiled performance. Give it a shot, you’ll be surprised at what you might learn
You can do union type in Golang. Just use multiple return values, one for each type and check which one is not nil in the caller :D
I'm gonna join you on the journey bro. Go is a solid language.
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?
In my experience, the amount of context that you have to keep in your head with Rust is extremely high.
Over time, and we’re probably talking years for most people, a lot of it becomes more muscle memory / lizard brain, like driving a car.
At that point the potential is phenomenal, but it takes a good while to get there. I’m not there yet :).
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?
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?
Tom loves Go for a reason
Bill Kennedy recently said that Google created a great language for the average developer, referring to Go.
My minor complaint with Go is that you can't add whitespace with operators. Other than that, i love how Go makes you think if you can simplify a problem
The Go fundamentals course in frontend masters is pretty good to get an idea of it
C and Go are my "Go" to for most of my projects
goto golang;
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.
A union type can be great for a closed set. For open (extensible) sets you need interfaces.
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 ?