Thanks for your valuable comment I will certainly see if I can create a video on the topic..As far as studies are concerned I believe I am not the right person to give suggestions.. sorry about that.. Thanks for your comment 🙏🙏
I am losing interest in Go as many frameworks are coming into market. That means one needs to learn those libraries also in future. Which areas Go can replace C++?
Thanks for your comment… as far as I am concerned..I will not learn new frameworks until and unless I need it. I believe in terms of performance, type safety and multi core applications both GO and Rust has a chance to replace C++ at some point in times in the future… but things can change Thanks again for sharing your thoughts 🙏🙏🙏
@@Cognitive-Programmer Thanks. If you want to do database operations, Golang supports built in dependency injection? What about web server? Can i use built in server provided by standard library in Production?
all these years we were made to feel guilty of not knowing oops design patterns, and now your are saying its an overhead as it has nothing to do with business logic.? what about reusability, readability, maintainability and all that? i would understand for doing smaller programs we dont need oops', so should we say for doing microservices we dont need oops, that will make more sense isntit? so the paradigm should decide the language to use.
Dear Sir Thank you for your comment I am not saying that oops is bad or something.. if it works for some scenarios, it works.. the idea of reusability, maintainability, and readability has nothing to do with business logic because I can write the same business logic in procedural way also.. All these things are invented for software developers, making their life easy when they look into the code written by others. But many a times I personally felt suffocated to use these patterns even though they may not be suitable for a scenario.. that’s what I am trying to say Hope I made it a bit clear.. Thanks again 🙏🙏🙏
@@Cognitive-Programmer thanks for the response. i agree with you. out of frustration i wrote that comment. actually oops frustrates me as well. i would like to explore more of go and understand the full potential of go.
OOP doesn't have much to do with code reusability. If you actually spend the time to learn newer languages like Rust and Go you'll find that OO design is fundamentally flawed to begin with. These languages offer better primitives for polymorphism and encapsulation, all the while not requiring you to build piles and piles of brittle inheritance hierarchies. Go's interfaces, for example, can be used with code from other people who don't even know about the interfaces you've defined for your use case. Go's struct embedding provides a clean and zero-overhead solution for sharing implementation, all without the costs of inheritance. Rust can achieve the same and more with its traits system and being a C++ derivative language, it offers multiple major types of polymorphism unlike most OO-first languages. If you want to climb higher in the abstraction hierarchy, you can check out Julia. Julia's multiple dispatch and subtyping capabilities blow every single OOP system out of the water. OO languages can't even dream of that level of code reusability. Inheritance has been so much of a dumpster-fire that even James Gosling, the creator of Java aka the language that popularized the type of OOP we're used to came forward and said that he would've left it out from Java if he were to design the language again from the ground up. You can pretty much assume this hypothetical Java would look nearly identical to Go, because this is literally the route these languages are taking these days e.g., green threads, AOT compilation, value types, and so on. Design patterns for OO is another bag of failures. Probably about half of all the design patterns are about preferring interfaces to sharing implementation through inheritance and like I've already mentioned, Go handles this better than all these languages. 9 out of 10 times, language/library features win over design patterns e.g., C#'s events over the observer pattern, Go's closures over the command pattern, Python's decorators and metaobjects over the decorator and factory patterns, and first class functions over many, many other ones. Most of these design patterns exist because Java and C++ were lacking good language and library support for these concepts back in those days. If you still prefer these overengineered solutions to simple problems over what I've mentioned, you're basically still living in the '90s, which makes sense because the CS curriculums in our part of the world suck miserably. The SOLID principles are like the only things that are still relevant, but even those come naturally when you're writing code in a language that prefers functional programming - and Rust does this with zero-cost abstractions so that you can write code that's more expressive and better performant at the same time.
Yes…every language has its own area of expertise and there can’t be any universal language. Multiple languages will coexist in future. I have talked about my own experience of systems programming in this video
Thank you for the nice content. If possible, could you make a video on Apache Kafka?
Thanks for your comment. I already have a playlist on Apache Kafka th-cam.com/play/PL_dsdStdDXbrsM74LnOrDYlshQM84X7hF.html
How much time to become Golang developer ?
Don't think I can answer, Really depends upon individual and what you want to create with golang. Thanks for your comment 🙏
Sir, make a series Devops. And what should a student have on major in his college to be a good devops or cloud native engineer?
Thanks for your valuable comment I will certainly see if I can create a video on the topic..As far as studies are concerned I believe I am not the right person to give suggestions.. sorry about that..
Thanks for your comment 🙏🙏
When you started Go did you have already worked with Java or C++?
Yes…I did worked on C++ and Java before..
💎✨👍
Thanks 🙏
Is it good for general purpose like console applications.
Yes you can create general purpose console applications... if you’re looking for GUI applications then there are packages...
Go is great. Frameworks shouldn't destroy it in the future !
I agree. Thanks for your comment 🙏🙏🙏
Go cannot replace c/c++ where ever system level programming is required because it has the cost of the runtime by default
Thanks for sharing your thoughts 🙏🙏🙏
IMHO you should reconsider learning Rust.
Fearless multi threading is a thing.
Rust will be a central language in the future
Thanks for your comment.. many people have asked me to learn Rust and I do believe it will have a bright future.. and yes..next target for me is Rust
I am losing interest in Go as many frameworks are coming into market. That means one needs to learn those libraries also in future.
Which areas Go can replace C++?
Thanks for your comment… as far as I am concerned..I will not learn new frameworks until and unless I need it.
I believe in terms of performance, type safety and multi core applications both GO and Rust has a chance to replace C++ at some point in times in the future… but things can change
Thanks again for sharing your thoughts 🙏🙏🙏
@@Cognitive-Programmer
Thanks. If you want to do database operations, Golang supports built in dependency injection? What about web server? Can i use built in server provided by standard library in Production?
Hello
Thanks for your comment.. many things depends upon the scenario.. I will talk about more in some later videos.. . Thanks again 🙏🙏🙏
You don't have to use the frameworks though. I don't see how that's valid
all these years we were made to feel guilty of not knowing oops design patterns, and now your are saying its an overhead as it has nothing to do with business logic.? what about reusability, readability, maintainability and all that? i would understand for doing smaller programs we dont need oops', so should we say for doing microservices we dont need oops, that will make more sense isntit? so the paradigm should decide the language to use.
Dear Sir
Thank you for your comment
I am not saying that oops is bad or something.. if it works for some scenarios, it works..
the idea of reusability, maintainability, and readability has nothing to do with business logic because I can write the same business logic in procedural way also..
All these things are invented for software developers, making their life easy when they look into the code written by others.
But many a times I personally felt suffocated to use these patterns even though they may not be suitable for a scenario.. that’s what I am trying to say
Hope I made it a bit clear..
Thanks again 🙏🙏🙏
@@Cognitive-Programmer thanks for the response. i agree with you. out of frustration i wrote that comment. actually oops frustrates me as well. i would like to explore more of go and understand the full potential of go.
OOP doesn't have much to do with code reusability. If you actually spend the time to learn newer languages like Rust and Go you'll find that OO design is fundamentally flawed to begin with. These languages offer better primitives for polymorphism and encapsulation, all the while not requiring you to build piles and piles of brittle inheritance hierarchies. Go's interfaces, for example, can be used with code from other people who don't even know about the interfaces you've defined for your use case. Go's struct embedding provides a clean and zero-overhead solution for sharing implementation, all without the costs of inheritance. Rust can achieve the same and more with its traits system and being a C++ derivative language, it offers multiple major types of polymorphism unlike most OO-first languages. If you want to climb higher in the abstraction hierarchy, you can check out Julia. Julia's multiple dispatch and subtyping capabilities blow every single OOP system out of the water. OO languages can't even dream of that level of code reusability.
Inheritance has been so much of a dumpster-fire that even James Gosling, the creator of Java aka the language that popularized the type of OOP we're used to came forward and said that he would've left it out from Java if he were to design the language again from the ground up. You can pretty much assume this hypothetical Java would look nearly identical to Go, because this is literally the route these languages are taking these days e.g., green threads, AOT compilation, value types, and so on. Design patterns for OO is another bag of failures. Probably about half of all the design patterns are about preferring interfaces to sharing implementation through inheritance and like I've already mentioned, Go handles this better than all these languages. 9 out of 10 times, language/library features win over design patterns e.g., C#'s events over the observer pattern, Go's closures over the command pattern, Python's decorators and metaobjects over the decorator and factory patterns, and first class functions over many, many other ones. Most of these design patterns exist because Java and C++ were lacking good language and library support for these concepts back in those days. If you still prefer these overengineered solutions to simple problems over what I've mentioned, you're basically still living in the '90s, which makes sense because the CS curriculums in our part of the world suck miserably. The SOLID principles are like the only things that are still relevant, but even those come naturally when you're writing code in a language that prefers functional programming - and Rust does this with zero-cost abstractions so that you can write code that's more expressive and better performant at the same time.
i won't leave python until and unless go brings some cool libraries for webdevelopment and also ml and dl
Yes…every language has its own area of expertise and there can’t be any universal language. Multiple languages will coexist in future.
I have talked about my own experience of systems programming in this video