@@killerdroid99 Never really gave it a chance. I feel like functional programming isn't where it's at for me, procedural really hits the spot. But I'll give it a shot, sure. Even tho Go covers almost everything I need, there are only a few small things that could be better.
Yeah, kinda copy of fireship (the styling at least), but the speech is slower and a bit boring. Also the intonation is kinda of sleep-inducing. But you can work these out given enough time and practice.
I have done a 10hr go course and your video just sumsup every crucial topic with clear concise explanation. This is a must video for anyone who wishes to start learning this beautiful yet strong language.
0:08 “Most dev surveys show Go as one of the fastest growing languages” _shows a chart of growth of programming languages where Go is closer to the bottom than to the top_ Great video though 😁
The chart gives numbers that do not distinguish between real growth and noise. As for language activity on GitHub, it appears that Go is among the three fastest growing in the last three years
What an excellent video! Your explanations around the difference between pointers and values really clicked for me. Would love more Go content from you!
That was great. Your explanation was so much clearer than my attempts to understand the official tutorial. I really struggle with the type of simplicity that Go chooses. From the perspective of a Java programmer, the simple choice is to not have pointers.
Have doesn't have pointers because it would make no sense, is a VM where you don't control memory, being simple by having access to less abstractions makes a lot of sense in the way go does it, for me.
I don't understand your argument. Go uses GC, so I don't see the difference between a real and a virtual machine in that case. My understanding of how that works for WASM is that the pointers are implemented with hidden offsets.
That was a great video, I've been learning go for a while an love it's simplicity yet great power, also it's error handling and pointers give you so much freedom that in other languages you don't have (try catch hell )
I write C# daily I have been on it since almost 20 years ago and I still love it, while I have always explored lots of other languages and technologies too. I am not a Go developer though, so I am learning new things here, and some aspects of the language pretty interesting. Even though it cannot compete with Rust, which I also know and love. While I do still think C# is really amazing and generally great to work with, I also see some of it's drawbacks. I now believe that programming languages which allocate their objects as values in the stack by default do a much better job. You have copy semantics by default, but you can take a reference to it and pass that to functions. Such as Go and Rust do. Even though Go is a GC language, such design decisions hold tons of work load away from the GC, which can make a lot of difference in performance. Because a GC only deals with heap, never with anything on the stack. C# still does a better job than Java in this sense that it has value types, but that is still bound to specific types and not an option for anything which already exists as a class, a reference type, which is a limiting problem. Even the dotnet team is aware of that and this is why they have been developing so much high efficiency things like Spans, ref structs and inline arrays to the language, which are all advancements on the value type side. And which is really great. But C# is also suffering from the Too Many Features issue, and adding ever more stuff to the language does not solve that issue. I think It's inevitable though.
For me, it's the lack of magic. You can just follow the code and understand how things are hooked up. I know it makes it less versatile in terms of expressiveness but it's so nice to easily understand other peoples source code without barriers. I've been using Elixir too, it's very good but they have way too much syntax. And a lot of libraries love macros which makes learning it a chore.
Go definitely would be both simple and good language, if not some pitfalls and drawbacks. Golang tries to pretend simple, but it is far from simple. The language has tons of nuances, that do not allow you to make some assumptions about one part of the language when you know another part (like knowing nuances of the slices does not allow you to work efficiently with hash-maps, because nuances of both do not overlap). Golang lacks expressiveness. Almost all in the language is just statements, it lacks even a basic ternary operator. So, using Go after versatile languages like Python or JS, Kotlin, C#, etc. is a pain. Lack of expressiveness is the reason, why we have almost no frameworks on the Go. Go has a weak type system, and many things, that can be expressed in other languages in very simple and obvious ways, are hard to express on Go (like regular sum-type, aka enum, that can be expressed even in Pascal). As to error handling, is not bad, but verbose - so you'll have to repeat 'if err != nil' mantra almost after each line of code. At the same time - error handling is optional, so you can easily miss or forget to handle an error since Go lacks of Option / Result type... Actually, the Go has so many shortcomings, that even whole books exist, like "100 Go Mistakes and How to Avoid Them" that describe all the language shortcomings and how to avoid them. In addition, the Go community is toxic. When you try to discuss the reasons for the pitfalls and possible ways how to overcome them, you meet pure aggression. You hear - "That's by design, that's a special philosophy of simplicity; you don't understand anything, get off!" The similar behavior you meet from Go authors. By years they will repeat that "You don't need this feature in the language at all!" (like about generics), and then they will add some ad-hoc solution, but in such a way that it would be better if they did nothing at all... The same situation we had not long ago. As a developer, you would love to have some means to work with your custom collections inside 'for ... range' loop. Go, of course, doesn't support using 'range' with custom collections. The solution would be using some iteration protocol, that is already in use in many languages, like Python, JS, Rust etc. What did the Go's authors make? They just ignored such requirements. Instead, they changed the logic of how 'for' loop captures variable values, and broke backward compatibility in the minor version of the language. Ah, in addition, they added min() and max() functions in the core of the language. A couple of functions, that you can write on your own just in a minute. Huge language improvement, yeah. That's "The Go way"!.. So, on the whole, Go looks like a very fast and sophisticated web framework, with all those nuances and the way the authors support and develop the language. It's good for web services, like REST API or for CLI utilities. But if you want to pick up the general purpose language, or trying to select your first programming language - you'd better pick up another one, like Python, or JS, or Kotlin or something different.
Expressiveness can be a double edged sword. I like Scala for its expressiveness, but this comes with complexity, a higher barrier of entry, and lower adoption rates. At the end of the day, I want to "bet" on a language that comes with the certainty of longevity. Wide adoption is a key factor for this.
@@awesome-coding Please, don't take me wrong, I'm not the Go hater. As a Turing-complete one, it allows you to create any program that can be written in Python, Java, C++, or Rust. And great concurrency model, enforced with auto-memory-management (aka GC) and relatively simple language is a huge PROs of the Go. But it definitely has cons, and I've mentioned not all of them; but the worst thing, as to me - Go authors just neglect devs' requirements, and instead of fixing real problems to make Go indeed a cool language spend time and effort to fix un-existed issues, like adding min() and max() as Go's built-ins...
You missed another important Go Pain Point. Go's interop is the badest I have ever seen and comes with huge performance Issues. A language with such a bad interop should never be used, because you cant extend the language or use another language as a base.
Good video, but please don’t use init functions to establish connections… They should only be used to prepare state or bind environment variables in most cases. Even then they are discouraged.
Thanks for the input! Will keep that in mind. I wanted to mention init functions, and some theory suggests those use-cases as appropriate for init functions.
Nice video, I learned something usefull. Would you do a video about Go routines ? I am interested in this topic 00:02:35 Python can also return multiple values, there are language that have pattern matching that is more powerful 00:06:39 To be honest, the OOP we have nowaday is a bit broken and far away of the original OOP (that's why FP devs laugh at OOP) languages like Go and Rust really inherit the core principles of true OOP Thanks again for your video !
Thanks for your feedback! I have a lot of Go content planned - Goroutines included. Good point about the pattern matching - clearly something very useful in any language.
let me say one thing puting pub / public before the function or stuct members is not a lot of work, but working with pascal case and camel case within one package or even within one struct is head ace, you got to remember not to use pascal case or all the functions and struct members will be exposed to public.
Yep - this is a weird choice, especially if your background is in a rigorous language like Java, and in an enterprise setting, where things have to always be explicitly defined. After 15 years of writing Java, seeing something like "os.Open()" in Go looks way of.. it should be "OS.open()" right?! :))
Great intro to go! However at 2:22, please never ever initialize a db connection in an init function. There are very few use cases for init - cobra cli code generation is a good example. Rather create the db connection as part of the running program (in main) and inject it where you need it. Init runs when a module is imported, and it could lead to very confusing code if somehting breaks just because it was imported. Please use with caution.
V is a better Go. I don't really know that, but I do really like V. It has some nice things which Go doesn't and its compile time is much faster and interops with C much better than Go.
I'm really not that familiar with V. Correct me if I'm wrong, but I believe the level of support & the community behind go is much bigger. It also helps the language is backed by Google. Even though V might be better, I think it's tough to compete with the Go ecosystem.
@@awesome-coding, Well, with V you have all of C available. So, that says something. You would have to map the library to V, which I wouldn't know how to do, I suppose I could learn if I needed to do that. Yes, V has a small community but it continues to push towards 1.0. So, yes, even though V is still in its early days, it appears to be keeping the promises it originally set forth that the naysayers said wasn't possible. So, will it ever get as big as Go? Maybe not, but it is pretty nice to work with!
Go is probably the best language ive ever used, ive seen many languages and the horrors they provide and Go removes all of that, it balances simplicity and power at the cost of some speed and being quite boring due to just how efficient, easy and quick to work with the language that it is
i like go more javascript, but it feels like it's lacking features. especially with error handling and type safety. i don't _mind_ using it but it's not my preferred choice.
I agree - this is one of those small "annoying" things when you first work with go, especially if using upper / lower case had a concrete meaning in other languages you know.
You'd have to rewrite it, if you are talking about backend JS (Node / Bun / Deno). If you are looking at a frontend project, Go can help you with the rendering, but UI behaviour still has to happen in JS.
package main import ("fmt") func main() { var i,j int fmt.Print("Type two numbers: ") fmt.Scan(&i, &j) fmt.Println("Your numbers are:", i, "and", j) }... Man this feels like C code in java 🤣🤣
In my opinion Go is a great language if you want performance and you or your team don't know any low level languages. Ex: You have to make a chess engine for a college class. Go would be ideal for this because it is simple and fast. However in the long term, Rust is the better language because it is not overly simplistic. It is better for more long term projects where performance and safety really matters.
@@awesome-codingGo uses Interfaces, Rust call it Traits. I saw examples for implementing interfaces in Go, and I didn't like it. Maybe you could talk about how IDEs help implementing interfaces?, i.e. Rust can aid you to auto-implement all missing members. Compare syntax of Go vs Rust, like for example Go's generic in swap vs Rust's. Definitely Rust won't have it easier to explain concurrency due to the need of Rust's to make sure you're not commiting data race (Rust pass by value with "owner transferal", whereas Go (maybe?) deep clones it. So maybe first "How would you do it with Rust way" and then "how much you would have to do to make it semantically similar to Go" How Go's Slices (maybe?) are just Rust's equivalent to Vecs or dynamically sized arrays, and that the term for slices is A struct which points to some memory, and holds the slice lenght (and of course, able to perform pointer arithmetic)
Rust and C++ don't even fall in the same category as Go. In C# you will most likely use some fat abstraction of a framework to get your job done -> Top-down approach In Go you will most likely have to write a fair amount of functionality on your own -> Bottom-up approach Have in mind these approaches are relative. Go is top-down compared to something like C++. I agree with the top comment saying that its hard to master Go. Concurrency is not easy. Most Go jobs out there are meant for Senior Engineers, this is for a reason.
@@ihatesun I am talking about how hard the language itself compared to the other language, not how to use it professionally in specific field or how can a framework could help you to get your job done. Yes, in Go, most likely you will have to write a lot, and that a good thing to know how things are working under the hood, but there are also frameworks that can help you to take the top-down approach. I do not know about concurrency in other languages how hard is it, but I do not think it's easier.
I did not like Go. In my line of work (Machine Learning) I do not use concurrency and threading at all, so for me Go does not bring any benefit against say Python.
Ironically they say Rust is more "complex" and harder than Go, yet the first code example at 1:37 rewritten in Rust is actually shorter 🤣 see below: let mut slices = Vec::new(); for i in 0..5 { let mut input = String::new(); println!("Enter {}:", i+1); io::stdin().read_line(&mut input).expect("Failed to read line"); slices.push(input.to_string()); } slices.sort(); slices.iter().for_each(|x| println!("{}", x));
Right, but fewer lines does not imply simplicity. Fewer lines usually come at the cost of abstractions and syntactic sugar, which require more knowledge and skills. For comparison, here is the Kotlin code: List(5) { println("Enter ${it + 1}:") readLine() ?: "" }.sorted().forEach(::println) } 5 lines in total, including the closing bracket. Sure, you can read it, and understand it, but I doubt you'd be able to write it without a deep understanding of the language.
@@awesome-coding yes I can read is perfectly given I love Kotlin (that's my second go to language). I would argue fewer lines is almost always better, unless you go all the way to languages like APL (which I also love). It means way less mistakes and easier to reason with.
Hey! Please let me know what guidelines I did not follow? I know for certain that having both pointer and value receivers on the same struct i frown upon, but other than that I'm not sure what I missed.
As someone who's used to Java in the university and at work, Go is a breath of fresh air.
Same, I want to use golang for work so bad
Exactly!
You would love elixir then
Go is just amazing💯
@@killerdroid99 Never really gave it a chance. I feel like functional programming isn't where it's at for me, procedural really hits the spot. But I'll give it a shot, sure.
Even tho Go covers almost everything I need, there are only a few small things that could be better.
Bro, I have to say your content has gotten so much better, and I think you have found a unique way of displaying your material. Well done!
Hey! Thank you so much for your message! It really means a lot!
Yeah, kinda copy of fireship (the styling at least), but the speech is slower and a bit boring. Also the intonation is kinda of sleep-inducing. But you can work these out given enough time and practice.
I just learned Go recently and this video did such an efficient job at clearly wrapping up the fundamentals into 10 minutes.
Glad to hear!
I have done a 10hr go course and your video just sumsup every crucial topic with clear concise explanation. This is a must video for anyone who wishes to start learning this beautiful yet strong language.
Glad it was helpful! Thank you for your feedback!
0:08 “Most dev surveys show Go as one of the fastest growing languages”
_shows a chart of growth of programming languages where Go is closer to the bottom than to the top_
Great video though 😁
Yep... I know 😅
I did the voiceover first, knowing Go was highlighted as growing fast.
Imagine my surprise when I actually saw the chart 🤦♂️
that was a chart about growing on urmom. He just showed it by mistake. Sorry man 😢
The chart gives numbers that do not distinguish between real growth and noise.
As for language activity on GitHub, it appears that Go is among the three fastest growing in the last three years
1 - Go Basics [ 0:54 ]
2 - Variables & Pointers [ 3:07 ]
3 - Control Flow [ 4:21 ]
4 - Type System [ 5:01 ]
5 - Data Structure [ 7:46 ]
6 - Concurrency [ 8:43 ]
7 - Standard Library [ 9:33 ]
Thank you!
What an excellent video! Your explanations around the difference between pointers and values really clicked for me. Would love more Go content from you!
Glad to hear it helped! More Go content will follow for certain.
More GO please, especially around error handling and best practices.
if err != nil {
fmt.Println("Uh oh")
log.Print(err)
}
@@iCrimzonLOL
@@iCrimzon That's what I was doing in the start to haha. Returning errors is simply superior to catching them
More go content please
will do for certain!
That was great. Your explanation was so much clearer than my attempts to understand the official tutorial. I really struggle with the type of simplicity that Go chooses. From the perspective of a Java programmer, the simple choice is to not have pointers.
Have doesn't have pointers because it would make no sense, is a VM where you don't control memory, being simple by having access to less abstractions makes a lot of sense in the way go does it, for me.
I don't understand your argument. Go uses GC, so I don't see the difference between a real and a virtual machine in that case. My understanding of how that works for WASM is that the pointers are implemented with hidden offsets.
Glad it was helpful!
That was a great video, I've been learning go for a while an love it's simplicity yet great power, also it's error handling and pointers give you so much freedom that in other languages you don't have (try catch hell )
Well said!
Try if err != nil every 5 lines :)
Great tour of Go
Thank you!
at 7:57. You can modify the array's content, but not its length
Yep - you are right. Thanks for clarifying this.
this is a very good video. your channel is gaining popularity just like i said in the past. you deserve the recognition my man. all the best
Thank you so much! I really appreciate the message and support!
Please also give C# a try.
It’s an amazing language and you can do everything imaginable with it. 😊
Easy Inheritance: Hi, I'm tech debt
I write C# daily I have been on it since almost 20 years ago and I still love it, while I have always explored lots of other languages and technologies too.
I am not a Go developer though, so I am learning new things here, and some aspects of the language pretty interesting. Even though it cannot compete with Rust, which I also know and love.
While I do still think C# is really amazing and generally great to work with, I also see some of it's drawbacks.
I now believe that programming languages which allocate their objects as values in the stack by default do a much better job. You have copy semantics by default, but you can take a reference to it and pass that to functions. Such as Go and Rust do.
Even though Go is a GC language, such design decisions hold tons of work load away from the GC, which can make a lot of difference in performance. Because a GC only deals with heap, never with anything on the stack.
C# still does a better job than Java in this sense that it has value types, but that is still bound to specific types and not an option for anything which already exists as a class, a reference type, which is a limiting problem.
Even the dotnet team is aware of that and this is why they have been developing so much high efficiency things like Spans, ref structs and inline arrays to the language, which are all advancements on the value type side. And which is really great.
But C# is also suffering from the Too Many Features issue, and adding ever more stuff to the language does not solve that issue. I think It's inevitable though.
For me, it's the lack of magic. You can just follow the code and understand how things are hooked up. I know it makes it less versatile in terms of expressiveness but it's so nice to easily understand other peoples source code without barriers.
I've been using Elixir too, it's very good but they have way too much syntax. And a lot of libraries love macros which makes learning it a chore.
This makes me wanna learn go
You really should!
super good and concise introduction to Go :) very well done, thanks!
Glad it was helpful! Thank you!
Go definitely would be both simple and good language, if not some pitfalls and drawbacks. Golang tries to pretend simple, but it is far from simple. The language has tons of nuances, that do not allow you to make some assumptions about one part of the language when you know another part (like knowing nuances of the slices does not allow you to work efficiently with hash-maps, because nuances of both do not overlap).
Golang lacks expressiveness. Almost all in the language is just statements, it lacks even a basic ternary operator. So, using Go after versatile languages like Python or JS, Kotlin, C#, etc. is a pain. Lack of expressiveness is the reason, why we have almost no frameworks on the Go.
Go has a weak type system, and many things, that can be expressed in other languages in very simple and obvious ways, are hard to express on Go (like regular sum-type, aka enum, that can be expressed even in Pascal). As to error handling, is not bad, but verbose - so you'll have to repeat 'if err != nil' mantra almost after each line of code. At the same time - error handling is optional, so you can easily miss or forget to handle an error since Go lacks of Option / Result type...
Actually, the Go has so many shortcomings, that even whole books exist, like "100 Go Mistakes and How to Avoid Them" that describe all the language shortcomings and how to avoid them.
In addition, the Go community is toxic. When you try to discuss the reasons for the pitfalls and possible ways how to overcome them, you meet pure aggression. You hear - "That's by design, that's a special philosophy of simplicity; you don't understand anything, get off!"
The similar behavior you meet from Go authors. By years they will repeat that "You don't need this feature in the language at all!" (like about generics), and then they will add some ad-hoc solution, but in such a way that it would be better if they did nothing at all... The same situation we had not long ago. As a developer, you would love to have some means to work with your custom collections inside 'for ... range' loop. Go, of course, doesn't support using 'range' with custom collections. The solution would be using some iteration protocol, that is already in use in many languages, like Python, JS, Rust etc. What did the Go's authors make? They just ignored such requirements. Instead, they changed the logic of how 'for' loop captures variable values, and broke backward compatibility in the minor version of the language. Ah, in addition, they added min() and max() functions in the core of the language. A couple of functions, that you can write on your own just in a minute. Huge language improvement, yeah. That's "The Go way"!..
So, on the whole, Go looks like a very fast and sophisticated web framework, with all those nuances and the way the authors support and develop the language. It's good for web services, like REST API or for CLI utilities. But if you want to pick up the general purpose language, or trying to select your first programming language - you'd better pick up another one, like Python, or JS, or Kotlin or something different.
Agreed. It is not a very expessive language. Though it has its uses cases, unlike some certain languages..
Expressiveness can be a double edged sword. I like Scala for its expressiveness, but this comes with complexity, a higher barrier of entry, and lower adoption rates.
At the end of the day, I want to "bet" on a language that comes with the certainty of longevity. Wide adoption is a key factor for this.
@@awesome-coding Please, don't take me wrong, I'm not the Go hater. As a Turing-complete one, it allows you to create any program that can be written in Python, Java, C++, or Rust. And great concurrency model, enforced with auto-memory-management (aka GC) and relatively simple language is a huge PROs of the Go. But it definitely has cons, and I've mentioned not all of them; but the worst thing, as to me - Go authors just neglect devs' requirements, and instead of fixing real problems to make Go indeed a cool language spend time and effort to fix un-existed issues, like adding min() and max() as Go's built-ins...
You missed another important Go Pain Point. Go's interop is the badest I have ever seen and comes with huge performance Issues. A language with such a bad interop should never be used, because you cant extend the language or use another language as a base.
@@ITSecNEO Interesting - I have no experience on this front, but I'd love to find out more if you have some more details to share.
i feel i should continue learning go now
Great vid! Yes to the maps deep dive
please provide technical deep dive for go generics 🙏
Added it on my list!
Good video, but please don’t use init functions to establish connections…
They should only be used to prepare state or bind environment variables in most cases. Even then they are discouraged.
Thanks for the input! Will keep that in mind. I wanted to mention init functions, and some theory suggests those use-cases as appropriate for init functions.
Nice video, I learned something usefull. Would you do a video about Go routines ? I am interested in this topic
00:02:35 Python can also return multiple values, there are language that have pattern matching that is more powerful
00:06:39 To be honest, the OOP we have nowaday is a bit broken and far away of the original OOP (that's why FP devs laugh at OOP) languages like Go and Rust really inherit the core principles of true OOP
Thanks again for your video !
Thanks for your feedback!
I have a lot of Go content planned - Goroutines included.
Good point about the pattern matching - clearly something very useful in any language.
Go rocks
Great video, thank you 🤍
let me say one thing puting pub / public before the function or stuct members is not a lot of work, but working with pascal case and camel case within one package or even within one struct is head ace, you got to remember not to use pascal case or all the functions and struct members will be exposed to public.
Yep - this is a weird choice, especially if your background is in a rigorous language like Java, and in an enterprise setting, where things have to always be explicitly defined.
After 15 years of writing Java, seeing something like "os.Open()" in Go looks way of.. it should be "OS.open()" right?! :))
Great intro to go! However at 2:22, please never ever initialize a db connection in an init function. There are very few use cases for init - cobra cli code generation is a good example. Rather create the db connection as part of the running program (in main) and inject it where you need it. Init runs when a module is imported, and it could lead to very confusing code if somehting breaks just because it was imported. Please use with caution.
Thanks for the tip! Will keep it in mind moving forward.
Great video.
Glad you enjoyed it
Rust, the programming language not the game.
V is a better Go. I don't really know that, but I do really like V. It has some nice things which Go doesn't and its compile time is much faster and interops with C much better than Go.
I'm really not that familiar with V. Correct me if I'm wrong, but I believe the level of support & the community behind go is much bigger. It also helps the language is backed by Google. Even though V might be better, I think it's tough to compete with the Go ecosystem.
@@awesome-coding, Well, with V you have all of C available. So, that says something. You would have to map the library to V, which I wouldn't know how to do, I suppose I could learn if I needed to do that.
Yes, V has a small community but it continues to push towards 1.0.
So, yes, even though V is still in its early days, it appears to be keeping the promises it originally set forth that the naysayers said wasn't possible.
So, will it ever get as big as Go? Maybe not, but it is pretty nice to work with!
Intresting, never seen TSQL language. Can anyone point to specs for tsql?
Go is probably the best language ive ever used, ive seen many languages and the horrors they provide and Go removes all of that, it balances simplicity and power at the cost of some speed and being quite boring due to just how efficient, easy and quick to work with the language that it is
💯
Go😎
Noice 👌
i like go more javascript, but it feels like it's lacking features. especially with error handling and type safety. i don't _mind_ using it but it's not my preferred choice.
Pointer arithmetic is possible, just by using the unsafe package
That's true. But the use of the unsafe package is discouraged, and the DX is atrocious.
3:03 I'd rather have a key word for that but I guess every language has to have some quirk.
I agree - this is one of those small "annoying" things when you first work with go, especially if using upper / lower case had a concrete meaning in other languages you know.
Are you the sound of Deno videos?
Yes - in some of them.
R*ST left the chat
How do I convert my javascript html project to GO?
You probably can't. Html is a markup language, not a programming language, and javascript has the special property that it can run in browsers
You'd have to rewrite it, if you are talking about backend JS (Node / Bun / Deno).
If you are looking at a frontend project, Go can help you with the rendering, but UI behaviour still has to happen in JS.
you could use a popular templating language called 'templ'. it has a unique syntax and features for go.
package main
import ("fmt")
func main() {
var i,j int
fmt.Print("Type two numbers: ")
fmt.Scan(&i, &j)
fmt.Println("Your numbers are:", i, "and", j)
}... Man this feels like C code in java 🤣🤣
😅😂
Encapsulation is not inheritance :)
No it is not, did I make it seem like it in the video?
In my opinion Go is a great language if you want performance and you or your team don't know any low level languages.
Ex:
You have to make a chess engine for a college class. Go would be ideal for this because it is simple and fast.
However in the long term, Rust is the better language because it is not overly simplistic. It is better for more long term projects where performance and safety really matters.
This is an interesting point. I'm exploring Rust these days, so I'll be able to do a proper comparison at some point.
@@awesome-codingGo uses Interfaces, Rust call it Traits. I saw examples for implementing interfaces in Go, and I didn't like it. Maybe you could talk about how IDEs help implementing interfaces?, i.e. Rust can aid you to auto-implement all missing members.
Compare syntax of Go vs Rust, like for example Go's generic in swap vs Rust's.
Definitely Rust won't have it easier to explain concurrency due to the need of Rust's to make sure you're not commiting data race (Rust pass by value with "owner transferal", whereas Go (maybe?) deep clones it. So maybe first "How would you do it with Rust way" and then "how much you would have to do to make it semantically similar to Go"
How Go's Slices (maybe?) are just Rust's equivalent to Vecs or dynamically sized arrays, and that the term for slices is A struct which points to some memory, and holds the slice lenght (and of course, able to perform pointer arithmetic)
No abstraction. just do the job
Fact!
Go syntax is easy. Mastering Go is not.
Master Go is easier than any programming language, try learning Rust or C++ or C#, not even master.
Rust and C++ don't even fall in the same category as Go.
In C# you will most likely use some fat abstraction of a framework to get your job done -> Top-down approach
In Go you will most likely have to write a fair amount of functionality on your own -> Bottom-up approach
Have in mind these approaches are relative. Go is top-down compared to something like C++.
I agree with the top comment saying that its hard to master Go.
Concurrency is not easy.
Most Go jobs out there are meant for Senior Engineers, this is for a reason.
@@ihatesun I am talking about how hard the language itself compared to the other language, not how to use it professionally in specific field or how can a framework could help you to get your job done. Yes, in Go, most likely you will have to write a lot, and that a good thing to know how things are working under the hood, but there are also frameworks that can help you to take the top-down approach.
I do not know about concurrency in other languages how hard is it, but I do not think it's easier.
What language is easy to master?
@@laszlotorhosi1867
syntax : Go, but it will force you to know more about how computer works.
in general : python.
2:40 returning multiple values from a function should not be a powerful feature of any language.
Every language I know does it.
😒 C, Java, JavaScript, C#, Swift, PHP, Ruby...
@awesome-coding C#, Rust and Zig can do it
I did not like Go. In my line of work (Machine Learning) I do not use concurrency and threading at all, so for me Go does not bring any benefit against say Python.
The most boring lang. There is no way to have a little joy programming in this, if you've ever touched something like C# or Rust
Now that I'm getting older, I actually appreciate "simple and boring" more :D
.
go ligmaballs
gott’em
Too many memes and stock vids.
Believe me, I can add way more :))
You're basically Fireship now ❤
Love the content, but find the way of speaking difficult to hear clearly. Perhaps shadowing native English speakers would help of you are interested.
Thanks for your feedback! I'm working on my accent, but it's pretty tough to fix it 🥲
Ironically they say Rust is more "complex" and harder than Go, yet the first code example at 1:37 rewritten in Rust is actually shorter 🤣 see below:
let mut slices = Vec::new();
for i in 0..5 {
let mut input = String::new();
println!("Enter {}:", i+1);
io::stdin().read_line(&mut input).expect("Failed to read line");
slices.push(input.to_string());
}
slices.sort();
slices.iter().for_each(|x| println!("{}", x));
Right, but fewer lines does not imply simplicity.
Fewer lines usually come at the cost of abstractions and syntactic sugar, which require more knowledge and skills.
For comparison, here is the Kotlin code:
List(5) {
println("Enter ${it + 1}:")
readLine() ?: ""
}.sorted().forEach(::println)
}
5 lines in total, including the closing bracket. Sure, you can read it, and understand it, but I doubt you'd be able to write it without a deep understanding of the language.
@@awesome-coding yes I can read is perfectly given I love Kotlin (that's my second go to language). I would argue fewer lines is almost always better, unless you go all the way to languages like APL (which I also love). It means way less mistakes and easier to reason with.
@@Anhar001 Fair enough!
Please follow gopher guidelines
Hey! Please let me know what guidelines I did not follow?
I know for certain that having both pointer and value receivers on the same struct i frown upon, but other than that I'm not sure what I missed.
I always get mad at go because it so stupid.. but less noise with obscure syntax so im probably more productive in it xd
😂