I've been learning a bit of Go. I'm a Sysops/Devops engineer and I find it much more manageable than Python.
@wl4dymir Жыл бұрын
What type of stuff do you automate with it ? I find myself content with ansible 99% of the time, I'm interested in Go but I think it would be hard to find a usecase.
@fraternitas5117 Жыл бұрын
@@wl4dymir ansible is walking dead dude, not designed for k8 native problems.
@drgr33nUK Жыл бұрын
I've not done a whole load with Go as I've only just started to pick it up but I've done a little working with Linux containers and some AWS deployment tasks etc. I've tinkered with Ansible and converted a vCloud inventory plugin that I originally wrote in Python. If you're working predominantly within Ansible then I would stick to Python. I suppose it all depends on the use case really. I use Terraform quite a lot for deploying infrastructure and Ansible for configuration etc. Long term, I think I will use Go for writing IaaC as well as some tooling. I have a little Python project that lifts a bunch of static assets from a Java app, copies them over to S3 and then runs an invalidation as part of a deployment pipeline. When using Python, I have to manage a whole bunch of dependencies like Boto3 and botocore as well as use setuptools to present the tool as a cli application. With Go I don't have to manage anything! Just compile the binary and pop it in my PATH.
@drgr33nUK Жыл бұрын
@Fraternitas I agree, Ansible isn't really designed for that type of work. I wouldn't say it was walking dead though :) Say I was going to deploy my own K8S cluster. I would use Go or Terraform for spinning up the resources and then Ansible to deploy and configure the cluster. I suppose it all depends on the problem you're trying to solve.
@wl4dymir Жыл бұрын
@@drgr33nUK Thanks for the clarification. I don't write any python, only ansible. I may use terraform soon but most of our deployments are single-vm so I have no need for complex infrastructure and just spin up VMs (or configure them on client site) all with ansible, that's what I was wondering. So I guess anything that kube/ansible/terraform doesn't do, you automate it in go ? Do you use anything like pulumi for example ?
@TrishanthDiwate Жыл бұрын
what I love about Go is the limited keywords and syntax, and there is not many ways you can write a program, which makes writing code and reviewing much easier
@alexanderfreeman Жыл бұрын
What's a language whose keyword count or syntax flexibility makes it harder to review?
@nhopf Жыл бұрын
@@alexanderfreeman C++
@edboss36 Жыл бұрын
@@alexanderfreeman good question. Keep on asking more like that, I do it as well
@twigoftheforest Жыл бұрын
@@alexanderfreeman Assembly, but it does have limited keywords and syntax
@pmkansara Жыл бұрын
Nice and clear explanation as always. I was interested in Go language for long time and peeked at it couple of times, but never went too deep into it. Now you gave me a reason to explore it more.
@sankethsk97696 ай бұрын
Is it worth learning?
@bazoo513 Жыл бұрын
Let me just note that Golang is far from being the only language with built in language-level parallelism, "green" threads (that is, those managed by the language runtime rather than the underlying OS) or other forms of concurrency. However, it may easily be the simplest and easiest to adapt to for people coming from C/C++ or Java world.
@aghileslounis Жыл бұрын
i don't think it's parallelism at all, it's concurrency yes but not parallel, parallelism is another level i have no idea of Go langauge, but I don't think it can handle parallelism just like that with go routines, probably some lower level package
@bazoo513 Жыл бұрын
@@aghileslounis You mean parallelism like in Algol 68, Occam or some versions of Prolog? Yes, I agee, but most languages require explicit OS support for _any_ kind concurrency.
@ioannischristou2362 Жыл бұрын
@@aghileslounis if your program utilizes 100% of your CPU and your CPU has 24 or 128 cores, is that program "parallel" or "concurrent" ? what is your definition of "concurrent program" versus "parallel program" ?
@sephirot7581 Жыл бұрын
@@aghileslounis Its parallelism. It will schedule the green threads on a thread pool (OS). So you have real parallel computing
@LunaticEdit Жыл бұрын
Word of warning - as someone who implemented a good chunk of the Diablo 2 engine in go (10.2k stars on github, now archived), I'd make sure you read all up on "CGO performance". Go is a wonderful little language that I'd happily use for microservices or small console apps. But I'd _strongly_ recommend not even trying to use library bindings for any thing that requires decent performance. It's insanely slow and the 'workarounds' basically revolve around writing half your code in C, defeating most of the reason for not using C in the first place. I really hope they solve the CGO issue as it is a huge roadblock from it becoming anything more than a niche language. To reiterate, I love the language itself and its syntax, it's just a shame it has such a large 'gotcha'.
@vitalyl1327 Жыл бұрын
For the same reason, everyone must learn Occam and Erlang, just to get a feeling of what concurrency and parallelism really are. Coroutines are an important concept to know, but not the only one.
@esquilo_atomico Жыл бұрын
elixir is a good option too
@GabrielMartins-jh6np Жыл бұрын
É a tropa do elixir 😎
@steve-adams Жыл бұрын
You know, I've been writing Go a lot and a little since it was released, and... I still can't put my finger on what exactly I like and dislike about it. I know I love its standard library; it's a stunning improvement over most languages I use, especially on the web. On the other hand, its general verbosity and extremely explicit error handling sometimes get on my nerves. The generics implementation seems like a giant nothing-burger for most use applications, which has been a little frustrating at times. Overall though I can't deny that it's a great language, and the oddities are minor and certainly possible to live with. As for goroutines, I think I agree. It beats the hell out of most languages I've used with concurrency. However, I do find it far easier to optimize concurrent processes in Rust. To Go's credit, this is almost always passable and often even great right out of the box. In Rust, it's only good if you use good crates. If performance optimization matters though, I'll usually take Rust over Go. I think this comes down to memory management being more readily tuned in Rust, so this detail is only applicable if that's ever something you actually need to do. If not, Go is a clear winner. Also, this video's description lead to me to seeing your video on dual core programming with the RP2040, which I hadn't really considered yet but I'm much more excited about now. Both great videos, thanks!
@helge000 Жыл бұрын
This was a very neat summary. I absolutely concur about the standard lib. I exclusively use it for backends - here Golang really shines IMHO.
@alenttt4814 Жыл бұрын
I would like to know, if I have a struct with some other struct fields, when to use object for its field type and when to use pointer type. . .
@TheSulross Жыл бұрын
tend to agree with that assessment my fav thing about Go is that it's a concise language and easy to start learning there is some actual trickiness to the channels in combo with goroutines, select, and range that takes a bit longer and some experience to really get a handle on, but overall I really like its baked-in concurrency features. For a lot of software that gets written, Go is very adequate (performance-wise, ease of coding and maintaining) And yeah, when writing system code and such where big runtimes that do garbage collection aren't an option, switch over to the likes of Rust (or perhaps some up and coming C replacement language such as Zig)
@haschid Жыл бұрын
@@alenttt4814 As a rule of the thumb, in go I would only use pointer for fields if I want the field to be nullable. If you can't think of a reason as to why the field should carry a null value, just use the object.
@davidlee588 Жыл бұрын
@@TheSulross do you have any advice on where I could practice go routines and channels, esp hands on labs? Thank you.
@Gosu9765 Жыл бұрын
Yep - that is badass. I love abstractions such as this and even Python doesn't have its interface for that so clean (not to mention GIL). Very cool feature.
@jonathandawson3091 Жыл бұрын
Python has it, see async await. Also Python had it under the hood for a long time as generators; coroutines are just syntactic sugar on top of it.
@Gosu9765 Жыл бұрын
@@jonathandawson3091 Python has it, but it's a threading module - async is just context switching within a thread. Async helps only with IO bound applications due to GIL and the fact it's the same thread - this go's solution can use multiple cores as it's a subprocessed thread. Even then the simple "go" is so much cleaner than task gathering. Still winning here no doubt.
@sephirot7581 Жыл бұрын
@@Gosu9765 You are 100% percent correct! Even without GIL async would only help us with IO-bound works because its like you said, just context switching within in a thread
@cjmarquez Жыл бұрын
I've read the documentation and watched some other videos, none was enough for me to understand channels, thank you for this video, very clear and easy to understand thanks to the great examples!
@paxdriver6 ай бұрын
I spent a weekend drilling into processing, multiprocessing and asyncio just to finally get it cemented in my head. Your videos helped tremendously, thank you!
@Verrisin Жыл бұрын
Most languages have some support for green threads. The unique feature about Go is it's duck interface implementation from outside a type. That I would say is much more defining of the language.
@Verrisin Жыл бұрын
Also, I have no idea why they needed special syntax for chan send/receive, as they are just methods on the chan ...
@user-dz6il2bx5p70 Жыл бұрын
@@Verrisin cuz its cooler
@KANJICODER Жыл бұрын
GoLang is what got me into C. If you like Go, but you hate the garbage collector, C is for you.
@svensvensson8102 Жыл бұрын
I have to say that my first experience with Go was rather pleasant. It's a straight forward language, with a build system and simple unit testing out of the box, nice enough concurrency mechanisms, good integration with IDEs and so on. Very fast to get going. However, as projects and complexity grows the poor encapsulation, lack of basic data structures, containers and algorithms and so on becomes a real problem. The recent addition of generics goes someway but it's not great, yet. At this point I want to like it but I'm not sure I do.
@EdouardTavinor Жыл бұрын
I find go's duck-typing of interfaces makes it a really good fit for large projects. it allows you to create abstractions without having to modify existing code.
@rob-890 Жыл бұрын
Rust is simply the best in terms of breaking the mold and solving memory safety in a robust way. Makes complete sense coming from "functional" java and the pain of C++
@GaryExplains Жыл бұрын
I also have videos on Rust for those who prefer it over Go.
@42Siren Жыл бұрын
Its so amazing to thing that using goroutines spawning using loop and passing inputs/outputs through channel, you are effectively simulating the entire Kafka message broker in 5-10 lines of code. Such a powerful too.
@RandomShowerThoughts Жыл бұрын
yup exactly, it's fascinating. I remember learning goroutines and it blew my mind
@TomMcGuire Жыл бұрын
Been trying to learn computer programming and using Go as my first language. Probably not everyone's first choice but from what I have read and the small amount I have done it does make some sense to me so sticking with it. This video was great to get my head round go routines. Would be great to have more videos about Go!
@TomMcGuire Жыл бұрын
@@BboyKeny thanks, I go interested in go because I was listening to a podcast about AI and I knew phyton was a big part of that but the presenters were talking about Go so I went looking. I thought why not learn it. I am just dabbling around trying to figure out what sort of things I could make. I haven't focused on one thing yet.
@BboyKeny Жыл бұрын
@@TomMcGuire Awesome! Glad to have another programmer in learning. I'm learning Rust at the moment, maybe this can help with inspiration. I'm building tool for scheduling social media posts as a learning/side project. The idea is that I have a folder called ".delaygram" in the home folder with this structure: .delaygram/ Photos/ category_1/ photo_1.jpg Scheduled/ photo_2.jpg Templates/ template_1.json Snippets/ snippet_1.json config.json schedule.json Every time the program starts, it checks if the folders and files exists and creates them if not. It has an interface where you can change settings, upload photos, create posts with templates which contains text and snippets (think of reusing hashtags). It shows thumbnails of posts and photo's and you can schedule posts by using an interactive calendar. It's basically a Hootsuite clone in essence. It explores the filesystem, creating an interface and connects to Instagram. So it's a manageable diversity of topics. I'm going to actually use it for my business and my girlfriend for her cosplay account, so it's also relevant for me as a project. Those 2 points are very useful to take into account when choosing a project. It doesn't have to be particularly useful like my project, writing a text based game for in the terminal is also a fun and good way to learn the language. A terminal game could be from text-based adventure like "You arrive at a crossroad, which direction do you want to go?" and then get user input. Or it could be having your army of 1000s orcs fighting another army asynchronously with go routines, showing the numbers go down in the terminal to the player. Sorry for the wall of text, I hope it's useful 😄
@dpu11 Жыл бұрын
You are not alone.
@edboss36 Жыл бұрын
@@BboyKeny nice that sounds like a really useful project. My first project was an Etsy webscraper to get data about 300 products at once and sort them in Python. But Go and Rust are amazing as well
@adityamore9435 Жыл бұрын
such a nice and clear cut example of go routines. Thanks Gary!
@nathanruben3372 Жыл бұрын
There are many languages that do that stuff as easy as go. Erlang, Elixir, Julia etc. Corouitines, channels are commodity nowadays. If you want thousands of lightweight threads look erlang. Go only brings table static compilation and less dependecy.
@Eden_Maker Жыл бұрын
Wow Gary. The educational value here is absurdly high. Thank you.
@stuartajc8141 Жыл бұрын
I'm already convinced. It's a great language. Could you please do a follow-up video showing how to do this in a clustered system, for example a Pi cluster running MPICH?
@arcariusmexen1104 Жыл бұрын
This was helpful. Thank you. I use Elixir/Erlang so a video on concurrency was very welcome. I am convinced to try out Go at some point in my career. Take care, Gary.
@sangramreddy5549 Жыл бұрын
Java too has virtual threads now. With version 20 onwards
@1MarkKeller Жыл бұрын
*GARY!!!* Good morning Professor!!! Good morning fellow classmates!!! Stay safe out there everyone!!!
@GaryExplains Жыл бұрын
MARK ‼️
@RandomShowerThoughts Жыл бұрын
Golang is a fantastic language. Goroutines and concurrency are so easy once you are using Golang
@vercolit Жыл бұрын
To me go is great because it's very simple (incredibly easy to learn and write code in), relatively fast, and with an amazing multithreading support. So your code will definitely be slower than optimised C/C++/Rust/zig/etc, but you'll write it much faster, and it'll have much much better performance than similar languages like python. So if you need something fastish, safe and productive, go is the answer. You want something very fast and safe? Rust. You want to actually understand systems programming? C. Just my opinion of course
@FreeTheUyghurs Жыл бұрын
Honestly as much as the async ecosystem is still in progress I feel I can wrap my head around Rust's threading and channels easier. Feels like my intentions are more explicit as to what I would like the hardware to do.
@raianmr2843 Жыл бұрын
Go isn't really a systems language and has goals different from Rust's. If you don't need millions and millions of concurrent green threads then Rust will do just fine I believe.
@coder415 Жыл бұрын
rust async is still problematic...
@cezarynyszko8907 Жыл бұрын
Awesome explanation! It's interesting to see concurrency support built into the language. I'm primarily coding with C#, and doing the same stuff there is definitely more convoluted (it doesn't have dedicated channel keywords, operators, and requires usage of Tasks API instead of Goroutines). Still, there're some external packages that, imho, make C# version easier to follow for this kind of processing in more complex cases? await GetData() .ToChannel(capacity: 1_000_000) .Pipe(maxConcurrency: 3, capacity: 1_000, transform: TransformStep1) .Pipe(maxConcurrency: 5, capacity: 1_000, transform: TransformStep2) .ReadAll(ProcessResult);
@EdouardTavinor Жыл бұрын
The great thing about go for concurrency is the 'select' statement. also you can destroy threads just as easily as you start them. For example, a standard pattern is: func multiplyLink(multiplier int, in
@citstuff Жыл бұрын
This is much better than many languages. Not quite as simple as Erlang.
@GoWithAndy-cp8tz5 ай бұрын
I like the way you speak English. I guess you're from the UK. I really enjoy the accent and Go as well. Cheers!
@anafabula Жыл бұрын
Honestly Rust can do everything you have shown about as easily with async/await (or threads if you just do computationally heavy work). Rust has channels in its standard library too. The only thing that's technically slightly harder in Rust is that it doesn't come with a default async runtime, but 99.99% of the time you can just take the most popular one (tokio) and be fine. I guess it's nice having the syntax for goroutines build into the language directly though.
@everestshadow Жыл бұрын
For hello world example it sure does but in real world business logic can be a complex mixture of blocking and non blocking operations. If you look at Rust's async runtimes they are mostly cooperative. Which means the programmer must take care of task scheduling and it can be a big mental burden for any complex application as someone not being cooperative can mess up everyone. On the other hand go is default to preemptive runtime where the runtime takes care the scheduling.
@GaryExplains Жыл бұрын
I also have videos covering Rust, for those who would prefer it over Go.
@9SMTM6 Жыл бұрын
I do love Rust, and vastly prefer it over Golang. But it has to be said, that even Tokio typically has shortcomings compared to Golangs Runtime. When Golangs Runtime falls flat that's REALLY problematic for it, which is the reason for the state of Rusts async ecosystem as Rust wants to serve a much broader range of ecosystems, including eg. Embedded. But if you're trying to solve your more typical developer tasks then Rust+Tokio is more complex than Golang and often does a worse job. The reason I still prefer Rust is that I want to be able to solve these atypical situations too, and also MOST successful projects eventually end up in a situation where they will be hurt by shortcomings of languages like Golang, but are stuck because the system is too large at that point. I highly dislike being in that situation, and the solutions that typically breeds, so I'll stick with Rust which has the necessary tools to solve these issues.
@appledore Жыл бұрын
Yes please. If you find it profitable, then please more Go videos. Thanks.
@semicharmedkindofguy3088 Жыл бұрын
I've heard of go but never really looked into it. This video is really piquing my interest in go
@nomadtrailsАй бұрын
Definitely A killer feature, but I don't know if it's THE killer feature. That would really depend on your use case. Fast compile times and easy compilation to multiple targets without sacrificing runtime speed or having to manually manage memory could be the killer feature. The standard library coming with everything under the sun so that you can boot fast and do anything in a serverless context dependency free could be the killer feature... so many reasons to love Go for various things.
@JoelJosephReji Жыл бұрын
Hello Gary, it would be fantastic if we could have more programming/programming language content in this channel!
@GaryExplains Жыл бұрын
Sure. What topics would interest you?
@JoelJosephReji Жыл бұрын
@@GaryExplains videos along the lines of this one would be great. cool features of particular programming languages, unique paradigms in different programming languages. for eg, the ownership concept in rust (which I believe you already did cover in your rust video) I would also be interested in stuff like design patterns and also trends in programming but they are being covered by the youtube channel, Fireship already so I am not sure if there is any point in repeating the same content. Anyway, thanks for all the cool videos!
@TheSulross Жыл бұрын
as well as looking ar at operating system projects - like Serenity - and especialy those OS projects that are being written in Rust (is Rust working out for them is the burning question)
@hetaeramancer11 ай бұрын
More C programming please, maybe its low-level application or data structures @@GaryExplains
@robchr Жыл бұрын
The problem with go routines is that they don't provide structured concurrency. And error handling is a pain.
@EdouardTavinor Жыл бұрын
they do provide structured concurrency. you comunicate with them using channels. error handling is really good. you just add a channel for errors, or you pass structures through the channels with an error field (which then act like the result monad)
@mkrichey1 Жыл бұрын
Great tutorial, love the language and glad to see it getting great content :)
@George-W-Jenson2 ай бұрын
yup, thats a killer feature
@DingoAteMeBaby Жыл бұрын
Very cool! I get the sense that at the upper end with the slowing/changing nature of Moore's Law (towards NN-based GPU parallelism), I think we will only see more languages/language features which syntactic-sugar integrate concurrency features into their baseline workflow
@ViewBothSides Жыл бұрын
Unfortunately syntactic sugar isn't enough. There's the runtime support for async execution AND the crucial support for asynchronously awaiting events from multiple sources. Python hasn't managed to standardise these things without needing breaking changes in the *language*.
@JamesSmith-cm7sg Жыл бұрын
There's a reason multi threading is more complicated in other languages, and it's not because they wanted to make it difficult.
@raianmr2843 Жыл бұрын
That's true, *it's because they weren't created for that purpose.*
@xeon2k8 Жыл бұрын
@@raianmr2843 you must be joking or only know coding in 1 or 2 other languages
@paulcarter7445 Жыл бұрын
Multi threading is not more complicated in F#. F# threads are light-weight (it was the first .NET language to include that capability natively).
@Schusy123 Жыл бұрын
At 4:35 it only prints the word "hello" 4 times, why is that?
@n0kodoko143 Жыл бұрын
Awesome! Thanks Gary!
@ashrafulfuad29673 ай бұрын
Thanks its really helpful
@firedawn Жыл бұрын
Great examples! Very clear and very useful!
@novarem9828 Жыл бұрын
Go is nice because its basically a nice updated version of C. This concurrency stuff is not beneficial for all tasks though. In many situations it can make things worse and introduce complexity where was none. Still cool that it has support for this stuff baked into the language itself.
@DingoAteMeBaby Жыл бұрын
I think you are right, however at the upper end with the slowing/changing nature of Moore's Law (towards NN-based GPU parallelism), I think we will only see more languages/language features which syntactic sugar integrate concurrency features into their baseline workflow
@raianmr2843 Жыл бұрын
What are your use cases?
@Verrisin Жыл бұрын
I mean ... Kotlin or Rust or most languages can do pretty much the same with async support ... - Yes, Go has better support for 'blocking' anywhere ... but is it really a reason to use the language for ? In fact, there is a lot missing in Go. Some they tried to "verbosely patch" with Context, some requiring weird workarounds for requiring specific thread to run the goroutine (i.e. OpenGL) and more -- Kotlin scoped coroutines are a lot nicer in most ways, for example. - The error handling and lack of many features really discourage me, despite some nice support for easily implementing other things, the compilation is nice...
@Verrisin Жыл бұрын
The unique feature about Go is it's duck interface implementation from outside. That I would say is much more defining for the language.
@sephirot7581 Жыл бұрын
Async its not kinda the same. Async in most languages are only for IO-bound Work. Pretty sure the same goes with Kotlin. It will generate a state machine with can switch the context. When you have CPU-bound Work, async will not help you and you doesnt gain any advantages. In Go is different, here the goroutines will be scheduled over the cores, even with CPU-bound work like in the video
@Verrisin Жыл бұрын
@@sephirot7581 It's exactly the same in this regard. You might know async only from JS/Python which are single threaded, but Kotlin/C#/Rust/Haskell/Elixir/... most languages, sensibly schedule coroutines over N threads (sometimes configurable, other times number of CPU cores) - In fact, the only thing async _cannot_ do is blocking IO and you have to be careful to use non-blocking, as JVM for example allows both and uses blocking by "default" making problems for async libraries if you use it incorrectly, as it blocks the whole thread and other coroutines cannot be scheduled on it. I'm not sure if CGO has to be cautious about that too, but I would expect so. - Difference between Kotlin/JS/C# and Go is a bit of extra overhead in Kotlin+, as it "simulates" a stack that can survive a yield by copying variables from VM stack frame into a "linked list of frames" stored on heap, where it survives a context switch. That implies a difference that async stack in such languages is not a continuous chunk of memory as it mostly can be in Go, which uses an array of "inline" stack frames and just allocates more when it runs out. - I love the way Go manages thread memory, so it's cheap and persist thread context switches, but in 99% of use cases, it's not worth using Go over something more ergonomic for this one nice thing.
@sephirot7581 Жыл бұрын
@@Verrisin Thx for your explanation! I'm a C# developer and was really thinking that the async/await construct only applies on IO-bound work but i saw with researching that this concept can also be applied on real threads which just using the same interface "Task". Thx for the explanation!
@EdouardTavinor Жыл бұрын
i don't really like Kotlin as a language. it's too complicated for big projects--every developer knows their subset of the language. also lack of duck-typing for interfaces means that it's very difficult to keep code safe if you interact with other libraries. rust is just too difficult for me. i try to learn it about every six months and give up after a couple of days. the strength of go for concurrency is how easy it is to coordinate stuff through channels and also how easy it is to tear stuff down in a controlled manner. for example, i once wrote a program which ran more than 100 goroutines for processing information in pipelines. each pipeline had a number of goroutines. configuration changes could mean that new pipelines needed to be created or destroyed. with go this was very simple to implement without losing a single packet of information from the pipeline. i honestly do not know how i would have solved this problem using something other than channels, lightweight-threads and the select statement.
@ThePowerRanger Жыл бұрын
Very valid reason.
@foxman6611 Жыл бұрын
Problem is libery support is poor 😕compared to java or js
@RichardDriscoll-ve9mi Жыл бұрын
Looks to me as if the channels idea comes from the Imos Transputer programming language Occam which I used to use in the '80 and early 90's. Occam channels were only ever unidirectional so the synchronization issue you demonstrated couldn't arise. Why didn't Google also impose that restriction I wonder?
@EdouardTavinor Жыл бұрын
channels can't be unidirectional. that would be pointless. channels work by a producer adding things to the channel and then a receiver getting things out of the channel. in go you do this by explicitly stating if the channel is a receive channel or a send channel for that particular function. for example, a function that starts a go routine to read from a channel will have a parameter like "addressChan
@saumyacow4435 Жыл бұрын
Yes, it has a neat syntax for concurrency.. but this can all be done in (for instance) Java... doesn't really make me want to go to all the trouble and then deal with all the inevitable idiosyncrasies and gotchas that get bundled with a new language.
@athfaannfasee3154 Жыл бұрын
Go is like 100 times faster than Java. What are you talking abt my man? Companies are switching their backends from Java to go. Even Big tech companies (ex : Twicth). There are other reasons too, like Go forces you do things in the correct way, one specific way of doing things means cleaner code and teammates no need to deal with others' completely different style of codes. Go is like the next generation child. Java is still popular only bcs it's costly for companies to switch to another language from their traditional Java ecosystem
@xeon2k8 Жыл бұрын
@@athfaannfasee3154 lol they said the same about ruby back then and here we are Java/Kotlin are still the main (by A LOT) backend for big techs. Stop spreading fake news dude.
@athfaannfasee3154 Жыл бұрын
@@xeon2k8 I didn't see any such news for Ruby like you say. Plus go is google's language and they are keep improving it. Plus if you can , be specific abt the fake news in my comment lol cz I only stated facts
@EdouardTavinor Жыл бұрын
akka actors make concurrency tolerable in java, but they still require many times the mental load of channels, goroutines and the select statement in go. (oh and about 20 times the code) (oh and also you can't have millions of actors in a system)
@saumyacow4435 Жыл бұрын
@@EdouardTavinor You can build your own classes to do the work of channels etc. Saved me a lot of time.
@ighsight Жыл бұрын
Very well done.
@GaryExplains Жыл бұрын
Glad you liked it!
@petery6775 Жыл бұрын
weird, but i get an error from last example- fatal error: all goroutines are asleep - deadlock!
@PaulMcCarthyYT2 ай бұрын
Concurrency is a great feature but what I want to know is how easily I can deploy it on Ubuntu on AWS Lightsail. I've seen Gitea (written in Go) running on it and it runs well but that doesn't mean I can deploy my code easily.
@hz8711 Жыл бұрын
Very interesting video, thanks!
@prashanthb6521 Жыл бұрын
This is interesting. I have done 'multiprocessing' in python only. Go seems nice but I am actually more interested in Julia than Go.
@beest_ Жыл бұрын
You have a race condition in your channel example. R can be 25 or 15 based on how quickly main can read the R value.
@GaryExplains Жыл бұрын
Eh? Don't I actually explain that in the video.
@beest_ Жыл бұрын
@@GaryExplains aaaand you indeed have 😁. I did the annoying watch half way and comment. Please accept my apologies. In my defense though, even with a single-item channel you are still in a race condition. Disclaimer:. I've use channels in another language and I don't have Go experience but the channel function is exactly the same behavior.
@lhpl Жыл бұрын
@@beest_ chan_sum3 "fixes" that error, bit another problem remains. Suppose main launches several go routines after starting sum. As they share sums input and output channels, if the try to send data, they might mix each others x and y data when sending, and also read resulting sums intended for a different go routine. Concurrent programming is hard... Disclaimer: I don't know Go very well, and it might have some constraints on how to share channels with go-routines that will prevent this.
@visheshl Жыл бұрын
It's actually pretty awesome!
@pabloqp7929 Жыл бұрын
Aye sure more Go would be awesome Sire
@charlesdavis3802 Жыл бұрын
Making concurrency a high level primitive is the magic of Go.
@HansMilling Жыл бұрын
The colon equal gives me pascal vibes, looks like a mix of Pascal and C. Anyway C# have a sync/await to deal with this, so why should go be better?
@EdouardTavinor Жыл бұрын
try bulding a system with fundreds of things running at the same time with complicated logic as to when which parts need to be restarted and then do so without the possibility of data loss. go makes things like that easy.
@HansMilling Жыл бұрын
@@EdouardTavinor Sounds like some over engineered code you have there if that is the case.
@EdouardTavinor Жыл бұрын
@@HansMilling some problems are difficult to solve. Being able to coordinate hundreds of parts of an asynchronous system is sometimes very useful.
@abrrrakadabrrra Жыл бұрын
@@EdouardTavinor let's do a challenge
@gad_leybharts Жыл бұрын
@@EdouardTavinor seems like the whole point of go, hence requiring Grand Master Ken Thompson to get the job done. Great comment. the guy there above seem to beleive that if you pretend problems do not exist, they'll go away!
@Ownedyou Жыл бұрын
While the focus on concurrency is a great feature, as is, the channels feel like a bit of a footgun.
@vladlu6362 Жыл бұрын
Why not learn Go: You need (proper) Generics. You need syntax that doesn't seem to be stuck in the 70's/is consistent (looking at loops and type annotations. Imagine making them worse than C, and also... Why are there two different assignment operators, depending on assignment and reassignment?). You need a programming language that isn't garbage collected. You need a programming language that uses LLVM. Why use Go: Almost Erlang-like concurrency. Need to replace java for something efficient. Need performance in a high level language (if we consider C and Rust low level languages) Have a fetish with C but unable to not segfault in C. Need a simple language (when would anyone need such thing? Don't ask me, idk.). Need a language that compiles fast Huh... Concurrency? Concurrency. And concurrency. Yeah, go is good at concurrency. And efficient. But that's pretty much it. Personally, the syntax is beyond horrible and a deal breaker.
@Alexey-gp7vc9 ай бұрын
yeap, it's disappointing to dig up language from the 80's call it modern and not give it anything modern.
@TheHeroArchetype Жыл бұрын
I’m still not sure what would be the real world scenario for using a go routine; could it be useful for something like a csv to database mass import?
@charliesta.abc12311 ай бұрын
Interesting feature! Is this how docker is built?
@muddyexport5639 Жыл бұрын
Thanks! GO More!
@Ou8y2k2 Жыл бұрын
What do you think of Carbon, Zig, and V?
@metaltyphoon Жыл бұрын
One caveat. Go’s concurrency is the main cause as to why its so slow to interop with any other language. Calling useful library written in other languages is horrific slow in Go.
@mingyenwu9621 Жыл бұрын
04:36 How come it prints 4 "Hello" and 5 "World"? I would expect goroutine to print the same amount of "Hello" and "World"...
@GaryExplains Жыл бұрын
The main program exits before the goroutines complete.
@mingyenwu9621 Жыл бұрын
@@GaryExplains Ah! I see! Thank you for the explanation!
@harahatchi9923 Жыл бұрын
Can I "Go" an encapsulated Bash scripts ?
@Verrisin Жыл бұрын
Go ... a language based around channels, yet has NO kind of union types. (tagged/disjoint) - So crucial for modelling. You usually need order between different kinds of events... - Google seems to dislike unions, in any of their languages ... So annoying. - Not to mention their handling of errors is atrocious and is meant to be a union, but instead you fill stuff with nils ... as if people long time ago didn't figure out that nulls are evil, and should not be implicit everywhere... - They did a few things well, and then so many atrociously.
@Verrisin Жыл бұрын
:= is also pretty stupid. Just because I used the same variable above, I can no longer use it. - Why can I not redefine the original binding? You force me to mutate the original var, and I have to change it to = ... so annoying and pointless.
@GaryExplains Жыл бұрын
Could you expand a bit on your dislike of :=, I don't quite understand the problem you are describing?
@Verrisin Жыл бұрын
@@GaryExplains - say I have code `c := foo()` which works fine - if I now write more code ABOVE and want to use variable name c, which should not affect the code below (more than it has to) I have to change the original code to `c = foo()` (assuming the type is the same, and I'm fine mutating the original variable) - in languages like Clojure, Elixir, Rust or I believe F#, even C# subscopes, I don't need to change any code after, and it still understands that's where the variable is defined. (And more, but this is off top of my head) - In say Python, the mutation is implicit, but again, no need to change the code further down. - Sure, in some languages, it's not possible at all to redefine a variable (including Go) so it's nice definition is as similar to assignment, but the feature is poorly designed from my perspective. Additionally this is especially annoying when moving variables for multi return assignments, and suddenly I have to change := to = just because none of the variables is new. But it's fine to mix them with := . Just allow to "redefine" variables and make the language much more consistent. `a, b := ` can mutate or define either, based on which is already present in scope. It makes the code less clear, consistent, and if I change something above, I might even need to delete the colon, because suddenly it's a problem.
@GaryExplains Жыл бұрын
I understand now, it is the fact you are adding code above. Well from my point of view it is a good job that Go enforces that. Reusing variables within the same scope without making it painful is a bug just waiting to happen. There is a difference between coding and software engineering. I guess you want easier coding, I am all for better software engineering. Thinking back to earlier programming languages, all variables had to be declared before use. I understand the easy of coding aspect when, say in a loop, you want to declare and initialize a variable within a specific scope. But beyond that I think it is dangerous. You may disagree, but what I am trying to out point is that there is some rationale to this behavior, it isn't just "stupid".
@Verrisin Жыл бұрын
@@GaryExplains I might be too critical, but I also dislike the mutability by default (well, only). It should be redefinition by default (ala Rust or to a degree langs like Kotlin) - Also, I am not really happy with any language. To the point that I've been occasionally designing my own for years, knowing I will never really implement it nor make it dominant despite how well I might design it, because I'm depressed and have very little energy to even actually work. - From the point of someone who's been thinking about language design for a long time, I see all the things I dislike in all languages I work in or look into, and admit to being overly critical, but I cannot help it when I see people repeating the same design errors (as far as I see it, at least) - I quite like Rust, btw. except (few things and) its types end up being rather verbose, as ~all functions need full written signature, instead of inferring at least return types. (I believe anything crate-local could skip a lot of manual decorating...) Anyway, I'm lazy (not just in a bad way) and annoyed when I have to do something ceremonial (e.g. writing anything the computer could figure out) - I believe languages should be much more ergonomic. - I'm sad I have many good ideas for designing a language (maybe even compiler and package structure/management) yet none will ever see the light, partially because nobody would care, and partially because I'm too weak to complete or 'sell' any of it. ... anyway, sorry for being so negative. At least I have the excuse that I'm depressed and tired and somewhat passionate about language design. - Then again, not that it matters much: soon, most coding will be AI assisted, and all will probably look very different...
@tonytenbreock8546 Жыл бұрын
Nice lesson about a topic I don't know. Google is promoting Go. Noticed python programmers earn twice what Go programmers do. How to choose what to learn?
@abrrrakadabrrra Жыл бұрын
C#
@parlor3115 Жыл бұрын
I don't see any benefits to concurrency being built into the language. It's almost identical to how other languages implement it, which via the use of callbacks. I think the only real advantage to GO is that it compiles to machine code and so doesn't require a runtime to be installed on the host.
@rickseiden1 Жыл бұрын
4:36 It only "said" hello 4 times. What happened to the fifth hello?
@Birdulon Жыл бұрын
Probably didn't flush the output buffer when the main thread exited, and main() didn't wait for it to finish.
@abrrrakadabrrra Жыл бұрын
one missing hello - who cares :)
@idjtoal Жыл бұрын
@@abrrrakadabrrra Main routine exits before subroutines are done... lol. Makes me not want to even learn this now.
@guilherme5094 Жыл бұрын
Really nice👍
@greendsnow Жыл бұрын
I decided to use Pocketbase, Go. I learned the language in 2 hours (except for the structs and pointers :P) I learned Echo in an hour. Now I wonder, how can I replace Nginx with something Go and handle SSL etc...???
@charlesbcraig11 ай бұрын
Caddy is a web server written in Go
@Test-iv4pm Жыл бұрын
How low level can I get with Go Routines? Would I be able to save some current register state, and load in a different register state?
@GaryExplains Жыл бұрын
Why would you want to do that in a goroutine?
@erikschiegg68 Жыл бұрын
They had PL1 to do all that multithreading stuff.
@Tony-dp1rl Жыл бұрын
As much as I like everything I have seen about Go, there is not yet any justification for switching to it. We are not even close to being CPU limited in any of our applications, so we would see no real gain in performance, but would lose huge amounts of time and money in the change (assuming we could even find parity in libraries and good developers). Much cheaper and less risky just to add a CPU now and again - they are cheap. :(
@hamm8934 Жыл бұрын
This is the true reality. It is rare that rewriting is ever the correct decision.
@SimonJackson13 Жыл бұрын
occam 2
@user-co1dw3lx7t9 ай бұрын
cool video)
@anb4351 Жыл бұрын
looks similar to kotlin coroutines and kotlin flow
@godofwinetits3826 Жыл бұрын
can you run this on a single thread processor?
@GaryExplains Жыл бұрын
Yes
@apoorvgupta9680 Жыл бұрын
What about elixir and erlang?
@GaryExplains Жыл бұрын
What about them?
@morthim Жыл бұрын
your multiprocessing video should have a timestamp for when you talk about multiprocessing.
@commentarytalk1446 Жыл бұрын
Ah, so the go routines help with concurrency which in turn helps with scaling up. I understand now.
@anatheistsopinion9974 Жыл бұрын
7:20 Wouldn’t there be a race condition even in that first example with a channel length of 1? My assumption from watching the video is that a thread is blocked from reading an empty channel and from writing into a full channel. But in this case, what prevents the main function from immediately reading the 15 it’s just written before the go routine may have had the chance to read it (making the channel empty) then write the sum? The video seems to suggest that the race condition only occurs when the channel length is bigger than 1. If that’s true, what am I missing? Thanks
@GaryExplains Жыл бұрын
You are quite right, there would also be a race condition when the channel is of length 1.
@anatheistsopinion9974 Жыл бұрын
In any case, the lesson to take out is that there should be two channels. Thanks :)
@fraternitas5117 Жыл бұрын
remind me what the s next to string is there for? 3:03
@fraternitas5117 Жыл бұрын
oh a local variable in the function nvm
@GaryExplains Жыл бұрын
It is the variable name of the argument.
@taufiqtoki Жыл бұрын
its looks similar to C
@RafaelMilewski Жыл бұрын
Learning new language is never a bad idea.. but between go and rust... you should do rust. rust helps you write perfect code.. I mean it..
@GaryExplains Жыл бұрын
I have videos covering Rust as well, for those who would prefer it over Go.
@obinnaokafor6252 Жыл бұрын
Nice one Gary. Can you do something similar in C# 11 and .NET 7?
@GaryExplains Жыл бұрын
That is a possibility. Do you mean a video on why to learn C# and .NET 7? Or a video on concurrency in C# and .NET 7?
@obinnaokafor6252 Жыл бұрын
@@GaryExplains Why to learn C#. And if possible, both of them
@lactobacillusprime Жыл бұрын
I question I have is - is this one of those experimental Google things that Google is eventually going to take away prematurely? Like so many other things...
@GaryExplains Жыл бұрын
It has been around for 13 years and is being used widely. It is also open source.
@da_revo5747 Жыл бұрын
Yeah it's open source. You can't just "take it away"
@drgr33nUK Жыл бұрын
Go ain't going anywhere but I'm still salty about my Google glass :)
@da_revo5747 Жыл бұрын
@@drgr33nUK and gamers knew stadia was DOA
@lactobacillusprime Жыл бұрын
@@GaryExplains That is very good to know. I like Google for the innovations but sometimes loathe it when it takes away something I personally really enjoy(ed).
@hroszell Жыл бұрын
In my experience modern Go prefers context over channels
@EdouardTavinor Жыл бұрын
context is something different. it allows you to group goroutines together so they all receive a signal at the same time. context is not used for the information flow.
@RayHorn5128088056 Жыл бұрын
Go routines are simulated threads that use one core. Try making Go use all available cores.
@GaryExplains Жыл бұрын
If you want to run goroutines in parallel, Go provides the ability to add more via the GOMAXPROCS environment variable or runtime function. Since Go 1.5, the default value is the number of cores.
@CappySmack Жыл бұрын
@@GaryExplains Feel free, sow e how easy this is for GO. I want to learn!
@GaryExplains Жыл бұрын
I don't understand. Goroutines run in parallel automatically on multicore machines, or concurrent when there are more goroutines than cores.
@CappySmack Жыл бұрын
@@GaryExplains GO Routines can have race conditions because they are all running in the same process space as the GO runtime otherwise, race conditions would be less easy to produce, as you so eloquently did in your video.
@CappySmack Жыл бұрын
@@GaryExplains You, Sir, are quite mistaken. GO Routines are AKA micro threads, not real threads. Also, there is a difference between using whatever cores the OS has assigned to a process versus using all available cores under programmatic control. GO out of the box is quite single-threaded regardless of what the OS thinks it is doing with the GO runtime process. Welcome to Computer Science. BTW, you can see this when using htop to show the activity for all your cores, assuming you have more than one core.
@gadgetboyplaysmc7 ай бұрын
Why is the end of the video the most replayed part 😭
@GaryExplains7 ай бұрын
Eh?
@endergamerxp5530 Жыл бұрын
it's like fork ?
@GaryExplains Жыл бұрын
No, not really. I have a video on fork. Did you get a chance to watch it?
@endergamerxp5530 Жыл бұрын
@@GaryExplains yes
@GaryExplains Жыл бұрын
Ok, so you understand that fork splits a process in two. That doesn't happen here. These are threads, lite threads to be more precise.
@endergamerxp5530 Жыл бұрын
okay so go are using threads (illusive multitask) thanks
@GaryExplains Жыл бұрын
It isn't illusionary when you have multiple cores. I have a thread test tool (written in Go) in my GitHub repo. When there are multiple cores they are all used.
@thewelder3538 Жыл бұрын
The whole point about threading is a bit of a lie really. In the large majority of cases, you end up waiting on that thread. I've coded SO many multithreaded applications and although in a certain set of cases it can give you a win, in others, it's just offsetting a problem. Unless your thread is virtually completely independent of the main thread, you're going to end up waiting. Let's say, you're doing some parallel processing and doing some I/O too... inevitably, your I/O is going to be much slower than your processing, so your just going to end up with threads waiting for the I/O to complete. Only in cases where things are separate, such as keeping a UI responsive whilst you're doing processing on another thread is the only real way to get a decent win. Even if you're doing networking, you're going to be waiting on the request. So Go being all about routines and parallel processing, is all a bit of smoke and mirrors unless you're use-case is right.
@ioannischristou2362 Жыл бұрын
how about writing web-servers, containers and the like? don't they benefit from multi-threading? how about scientific computing, where you need to solve a differential equation over a large domain, with very little communication between the various domains (and only across the boundaries)? and so on. Multi-threading has a lot of "wins" in complex problems that are amenable to some kind of decomposition (even recursive). And given the number of cores in today's CPUs, not utilizing them is just wrong (which of course you can masquerade for "readable code that avoids the complexities of multi-threading that nobody really understands")
@thewelder3538 Жыл бұрын
@@ioannischristou2362 Sure, there are wins in multithreading and like I said, where the threads can almost act independently, that's where you get the win, but that's not usually how people write threading. They have all this stuff pushed onto background threads that then end up having to join the main thread and spend most of their time waiting. Take a look at the basis of say C# with its async Task and await. It's like a threading nightmare.
@commieTerminator Жыл бұрын
the "cin" and "cout" channel names gave me C++ vibes