The One BIG Reason to Learn Google's Go Language
Вставка
- Опубліковано 25 чер 2024
- A goroutines are lightweight threads managed by the Go runtime. They are easy to use, and make Go brilliant for concurrency. Goroutines , in my humble opinion, are the top reason why you should learn Go. Here is a quick tutorial about goroutines and how to use them with another Go feature called channels.
---
Fork and Pthreads - A Guide To Get You Started with Multiprocessing - • Fork and Pthreads - A ...
Dual Core Programming for the Raspberry Pi Pico, ESP32, and ESP32-S3 Using the Arduino IDE - • Dual Core Programming ...
Multitasking vs Multithreading vs Multiprocessing - • Multitasking vs Multit...
Let Me Explain T-shirt: teespring.com/gary-explains-l...
Twitter: / garyexplains
Instagram: / garyexplains
#garyexplains
I've been learning a bit of Go. I'm a Sysops/Devops engineer and I find it much more manageable than Python.
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.
@@wl4dymir ansible is walking dead dude, not designed for k8 native problems.
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.
@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.
@@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 ?
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.
Is it worth learning?
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!
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
What's a language whose keyword count or syntax flexibility makes it harder to review?
@@alexanderfreeman C++
@@alexanderfreeman good question. Keep on asking more like that, I do it as well
@@alexanderfreeman Assembly, but it does have limited keywords and syntax
such a nice and clear cut example of go routines. Thanks Gary!
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!
Wow Gary. The educational value here is absurdly high. Thank you.
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'.
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?
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.
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.
@@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.
@@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
Great examples! Very clear and very useful!
Great tutorial, love the language and glad to see it getting great content :)
Awesome! Thanks Gary!
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.
elixir is a good option too
É a tropa do elixir 😎
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.
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
@@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.
@@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" ?
@@aghileslounis Its parallelism. It will schedule the green threads on a thread pool (OS). So you have real parallel computing
Thanks its really helpful
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!
This was a very neat summary. I absolutely concur about the standard lib. I exclusively use it for backends - here Golang really shines IMHO.
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. . .
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)
@@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.
@@TheSulross do you have any advice on where I could practice go routines and channels, esp hands on labs? Thank you.
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!
@@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.
@@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 😄
You are not alone.
@@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
GoLang is what got me into C. If you like Go, but you hate the garbage collector, C is for you.
Very interesting video, thanks!
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.
Also, I have no idea why they needed special syntax for chan send/receive, as they are just methods on the chan ...
@@Verrisin cuz its cooler
Very valid reason.
I've heard of go but never really looked into it. This video is really piquing my interest in go
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.
yup exactly, it's fascinating. I remember learning goroutines and it blew my mind
Yes please.
If you find it profitable, then please more Go videos.
Thanks.
This is much better than many languages. Not quite as simple as Erlang.
It's actually pretty awesome!
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.
Very well done.
Glad you liked it!
Aye sure more Go would be awesome Sire
Golang is a fantastic language. Goroutines and concurrency are so easy once you are using Golang
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
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*.
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++
I also have videos on Rust for those who prefer it over Go.
*GARY!!!*
Good morning Professor!!!
Good morning fellow classmates!!!
Stay safe out there everyone!!!
MARK ‼️
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.
Thanks!
GO More!
Java too has virtual threads now. With version 20 onwards
There's a reason multi threading is more complicated in other languages, and it's not because they wanted to make it difficult.
That's true, *it's because they weren't created for that purpose.*
@@raianmr2843 you must be joking or only know coding in 1 or 2 other languages
Multi threading is not more complicated in F#. F# threads are light-weight (it was the first .NET language to include that capability natively).
Hello Gary, it would be fantastic if we could have more programming/programming language content in this channel!
Sure. What topics would interest you?
@@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!
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)
More C programming please, maybe its low-level application or data structures @@GaryExplains
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.
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.
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);
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
Really nice👍
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
Interesting feature! Is this how docker is built?
I like the way you speak English. I guess you're from the UK. I really enjoy the accent and Go as well. Cheers!
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.
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.
I also have videos covering Rust, for those who would prefer it over Go.
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.
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.
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.
rust async is still problematic...
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?
What do you think of Carbon, Zig, and V?
This is interesting. I have done 'multiprocessing' in python only. Go seems nice but I am actually more interested in Julia than Go.
cool video)
yup, thats a killer feature
At 4:35 it only prints the word "hello" 4 times, why is that?
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?
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
Can I "Go" an encapsulated Bash scripts ?
Making concurrency a high level primitive is the magic of Go.
The problem with go routines is that they don't provide structured concurrency. And error handling is a pain.
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)
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.
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.
Eh? Don't I actually explain that in the video.
@@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.
@@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.
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?
Why would you want to do that in a goroutine?
Problem is libery support is poor 😕compared to java or js
weird, but i get an error from last example- fatal error: all goroutines are asleep - deadlock!
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?
C#
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.
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
@@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.
@@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
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)
@@EdouardTavinor You can build your own classes to do the work of channels etc. Saved me a lot of time.
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...
The unique feature about Go is it's duck interface implementation from outside. That I would say is much more defining for the language.
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
@@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.
@@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!
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.
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
You are quite right, there would also be a race condition when the channel is of length 1.
In any case, the lesson to take out is that there should be two channels. Thanks :)
Nice one Gary. Can you do something similar in C# 11 and .NET 7?
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?
@@GaryExplains Why to learn C#. And if possible, both of them
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?
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.
@@EdouardTavinor Sounds like some over engineered code you have there if that is the case.
@@HansMilling some problems are difficult to solve. Being able to coordinate hundreds of parts of an asynchronous system is sometimes very useful.
@@EdouardTavinor let's do a challenge
@@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!
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...???
Caddy is a web server written in Go
While the focus on concurrency is a great feature, as is, the channels feel like a bit of a footgun.
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.
can you run this on a single thread processor?
Yes
04:36 How come it prints 4 "Hello" and 5 "World"?
I would expect goroutine to print the same amount of "Hello" and "World"...
The main program exits before the goroutines complete.
@@GaryExplains Ah! I see! Thank you for the explanation!
occam 2
They had PL1 to do all that multithreading stuff.
Ah, so the go routines help with concurrency which in turn helps with scaling up. I understand now.
What about elixir and erlang?
What about them?
looks similar to kotlin coroutines and kotlin flow
4:36 It only "said" hello 4 times. What happened to the fifth hello?
Probably didn't flush the output buffer when the main thread exited, and main() didn't wait for it to finish.
one missing hello - who cares :)
@@SSwoodwork107 Main routine exits before subroutines are done... lol. Makes me not want to even learn this now.
Not bad :)
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.
👍🏼
In my experience modern Go prefers context over channels
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.
remind me what the s next to string is there for? 3:03
oh a local variable in the function nvm
It is the variable name of the argument.
#GO to work. 👩🔧
the "cin" and "cout" channel names gave me C++ vibes
your multiprocessing video should have a timestamp for when you talk about multiprocessing.
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. :(
This is the true reality. It is rare that rewriting is ever the correct decision.
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..
I have videos covering Rust as well, for those who would prefer it over Go.
its looks similar to C
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.
:= 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.
Could you expand a bit on your dislike of :=, I don't quite understand the problem you are describing?
@@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.
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".
@@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...
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.
yeap, it's disappointing to dig up language from the 80's call it modern and not give it anything modern.
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.
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
What are your use cases?
Go routines are simulated threads that use one core. Try making Go use all available cores.
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.
@@GaryExplains Feel free, sow e how easy this is for GO. I want to learn!
I don't understand. Goroutines run in parallel automatically on multicore machines, or concurrent when there are more goroutines than cores.
@@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.
@@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.
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...
It has been around for 13 years and is being used widely. It is also open source.
Yeah it's open source. You can't just "take it away"
Go ain't going anywhere but I'm still salty about my Google glass :)
@@drgr33nUK and gamers knew stadia was DOA
@@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).
it's like fork ?
No, not really. I have a video on fork. Did you get a chance to watch it?
@@GaryExplains yes
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.
okay so go are using threads (illusive multitask) thanks
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.
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.
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")
@@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.
Why do UA-cam keep flaging me up for comments and taking them down ?? they'll never give me the comment in question? I have no idea what they're talking about and I don't believe I've pitched any guidelines, they can suspend me for whole day! I send them feedback with this problem but they never get back to me. I'm starting to feel like I'm being harassed and bullied by UA-cam.
Your comment got through!
@@GaryExplains thanks for letting me know but that doesn't solve the issue 😆
You not heard about this problem then... it's only happened recently. And another annoying thing that's happened recently is subscribers I'm limited to I think about 70 never used to be the case why are they limiting my subscribers? You know cheers!!
@@hoobsgroove it's not only you.
@@miepmiepzoefzoef you don't know what's going on then with it? what are they doing at UA-cam??
@@hoobsgroove mostly out are bots and you used an "illegal" word or an "illegal" combination of words.
Copy your reply before submitting it.
When your comment is gone after a few seconds, change some words and retry...
Why is the end of the video the most replayed part 😭
Eh?
Go but No Go!