I also went from python to go! I felt like it was kinda the opposite. Go's standard library is relatively small. Actually pretty helpful to learn the language. But I definitely felt like some things were missing coming from Python's expansive stdlib.
Re: Java - for quite a few years now Java has RECORDS, so you no longer need to create getters, setters, constructor or methods related to comparing object. You can simply define your movie type like this: `public record Movie(String name, double score) { }`
Yep, and C#, which in Program.cs you could write: ``` var a = new Movie(Name: "Seven", Score: 10); record Movie(string Name, float Score); ``` But the convention-based approach of Go looks reasonably nice to me (the uppercase versus lowercase names dictating public versus private). There was nothing I saw in the video that would make me switch to Go, but I can still respect it is elegant syntax.
For me, the biggest shortcoming of go is all properties being optional. If you could set a compiler flag for required properties or add a lil syntax, it would go a long way.
It sounds like you are doing something wrong. The only case when you need to explicitly check for nil is usually error handling. Everything else can be covered by default values and nil receivers
@@hamm8934yeah that's my biggest issue with it too. I'm surprised how little anyone else mentions this. I think your comment here is the first one I've seen, aside from all my own.
It's been a few weeks that I made the decision to ditch Node.js in the company I work for. Every one of our Node.js applications will be rewritten over time in Go or Java due to obvious reasons.
@maacpiash @girxchin Glad you asked. We started 3 years ago using Node.js. It was chosen as our main platform due to the following reasons: a) The team's average technical skills and stack at that time. Apart from myself, we had two beginner developers who only knew front-end JavaScript and had limited (college-level) knowledge of Python. We immediately discarded Python as an option for the back-end (the reasons for this should be obvious). b) The size and scope of the applications we were building back then. At that time, we were creating simple web apps for a single industrial customer, hosted locally. Few users, simple authentication mechanism, we theoretically had available as much computing power as we needed. As time passed, the complexity of our customers' demands increased. As the codebase of our apps grew, maintaining the code and adding new features became increasingly difficult. This wasn't due to poor design, architecture, or lack of clean code. This is an inherent issue with any other dynamically typed language. [Quick advice: if you want robust, less error-prone applications, you need a static/strict/strong-typed language.] I felt it was time to enforce the adpotion of TypeScript. The team quickly got the hang of it. And we kept using it up to this day. However, I knew that TypeScript would eventually reach its limitations. As we gained more customers, we started building and selling larger, multi-tenant applications. Our team grew in size and experience, and the developers became familiar with concepts like types and pointers. The perhaps not-so-obvious reasons for moving from Node.js to Go/Java are as follows: a) JavaScript The language was not created for back-end. It was adapted. The most important issue is that as a dynamically typed language, it has a high level of ambiguity, particularly with its "truthy" and "falsy" values - for example, "if (0)" translates to "if (false)" in JS. Such a situation wouldn’t occur in a properly typed language like Go or Java. b) Compilation and build size (Go advantage only) Recently we deployed a complex queue handler app in a container with a single 9MB executable! c) Memory consumption (Go advantage only) It's fairly known that Go applications eat a lot (like, A LOT) less memory than Node runtime. Also, Go's learning curve is shallow. Hope this clarifies.
@maacpiash @girxchin Glad you asked. We started 3 years ago using Node.js. It was chosen as our main platform due to: a) The average technical skill and stack of our team at that time. Except for myself, we had two beginner devs that knew only front-end JS and a bit (college knowledge only) of Python. Note: Python was immediately discarded as an option for back-end (I assume the reasons for this one are obvious here). b) The size and scope of the applications we were building back then. We were crafting simple web apps for a single industrial customer, hosted locally. Few users, simple authentication mechanism, we theoretically had available as much computing power as we needed. Time passed by and the complexity of our customer demands increased. As the codebase of our apps was growing, it was becoming harder and harder to maintain the code and to adding new features. It was not a matter of design or architecture or clean code. It would happen with any other dynamically typed language. [Quick advice: if you want robust, less error-prone applications, you need a static/strict/strong-typed language.] I felt it was time to enforce the adpotion of TypeScript. The team quickly got the hang of it. And we kept using it up to this day. However, I knew it was only a matter of time for TypeScript to not be sufficient anymore. We gained more customers and started building and selling multi-tenant, bigger apps. The team grew in size and we are more experienced. Devs now understand types and pointers. The perhaps-not-so-obvious reasons for moving from Node.js to Go/Java are: a) JavaScript The language was not created for back-end. It was adapted. The most important thing: as it's dynamically typed, the level of ambiguity is high, especially because of the famous "truthy" and "falsy" values - "if (0)" translates into "if (false)" in JS. Something like that wouldn't compile in a properly typed language, like Go or Java. b) Compilation and build size (Go advantage only) Recently we deployed a complex queue handler app in a container with a single 9MB executable! c) Memory consumption (Go advantage only) It's fairly known that Go applications eat a lot (like, A LOT) less memory than Node runtime. Also, Go's learning curve is shallow. Hope this clarifies.
I really like go. You can type go doc and the package name when you forget something you want to use and it pops right up in the terminal. Most of what you need is already in the language. Very nice.
Imo Go is possibly the fastest GCPL there is. This is a great pity, since it's made to be so versatile and not tied to any ecosystem (*ahem*swift*ahem*). I feel Google made a mistake here when they created three different PLs (Go, Kotlin, Dart) for different use cases. They should only have made Go, then aggressively pushed Android to switch from Java to Go, likewise with Flutter. Now Kotlin is stuck with the JVM which slows down its compile speed while Dart is only about as fast as JavaScript even though JS as a dynamic PL is JIT compiled and Dart as a static PL is AOT compiled.
It might just be me, but I kind of disagree about Go being concurrent. It using physical cores or threads is kind of irrelevant to how the code behaves, and it behaves as parallel threads, and that's the entire reason why Go's model sets itself apart from C++ for example, where parallelism often requires complex thread locking and mutexes, which don't preclude deadlocks in the least. Concurrent to me is more like C++ coroutines, where you have many tasks you are juggling and it is explicit by the API that there's context switching happening within the scope of your app, not the operating system's automated scheduling. In other words: if you start a bunch of tasks, and they all happen at the same time - then it doesn't matter if the scheduler technically split them up into small chunks, as far as your code is concerned, it's parallel. Otherwise, if you implement coroutines in Go, what do you call those? Super/Strict Concurrency? Nah
I really want to, but the language has some strange paradigms that I'm not fond of and I keep returning to Rust due to finding I trust my code more. But Golang is very appealing in terms of all that it does well, and how flexible it is.
rust syntax is closer to js than go which is one reason that i like it more. mainly the type system and pattern matching is something i find difficult to live without.
Started learning Go today. Because I can't constantly build and run my application, it's helped me to write features more incrementally by taking baby steps rather than defaulting to building and running my aoplication, especially when writing large chunks.
Go is the future of web dev. By 2030, Go is going to be a powerhouse once Templ, HTMX, and Alpine get more mature. Go is what typescript and pedantic pretend to be.
Error handling in Go reminds me of the "Try Pattern" in C# where a method would return a boolean for status and have one or more "out" parameters to get your stuff back. I'm using Unity 90% of my time and I use this pattern A LOT to get around object lifecycle and I like it very much, so I guess GO would not be hard to adapt to.
I have also recently started exploring Go. My background is mostly in Java but I also have a good understanding of Python and JS as well. I'm not really impressed by my first week of learning Go. I like the fact that is compiled in a single binary. I actually like the errors as values because it forces you to think more about error handling and it would definitely be my go to for writing concurrent programs. However, I'm really annoyed with the systax sometimes, for example appending to a slice, type conversion etc Do you think that I would get used to it and start liking it more once I get more familiar with the standard library and the "go way of things"? How was your experience in the beginning coming from JVM languages as well?
>Do you think that I would get used to it and start liking it more It is quite possible. I hated some of the things in Go when I started working with it Now, after about 5 years of working with it on daily basis I love it and understand why those things were done the way they were.
I tried it, I had problems with reading files. Many problems. I did not have that problem with any other new languages I was starting with. I passed it after an hour of fights. You may say I'm noob, yes I am, but to me that's much hassle with simple things making work.
Would be interested to know what those problems were. My first Go use case was parsing, splitting & writing csv files. Whilst it wasn't quite as simple as something like NodeJS, it was not complex & extremely performant. Struct tags are a great feature, I find.
@@awesome-codingwith the zig linker you can make statically linked binaries even with libraries that use CGO. It's not flawless and I haven't seen perf testing, but it works
One of Golang's aims was to keep it as a simple language and so they won't keep adding features to it like they do to Java, C++ and Rust. And Java creators aim was never to keep it simple.
I learned java first then switched to go and it is simple and fast I am loving it but it sucks at handling errors. Also I am following java these days and it seems it is improving a lot. Now Java method can also return multiple different type values, no setter getters required with record . they are also working on project like Lilliput, Valhalla and Leyden to improve performance and cut memory usage by almost 50%. If this happen I will happily switch to java again
So the separation of structs and interface is a reaction to oop? To simplify things when before all these methods, and types were bound up in a class? Am I understanding this correctly?
i like go for very small projects and prototyping. it's too simple and verbose when i want to be expressive. if there was a better balance it would be the perfect language. i like elixir phoenix more.
JS has the worst syntax, you need to create separate functions just to catch and handle errors, otherwise your code is going to nest too much. I like understanding how my code works at a deeper level and I would have to spend too many hours doing that in JavaScript.
@@awesome-coding they had to create a lot of libraries to make it enterprise level, ex. Uber has to create zap as go standard logger wasn't that good, jaeger for distributed tracing. I had to create my own tracer for printing the traces in logs. All these are autoconfigured in java
@@diamondkingdiamond6289 Fully agree. I started to learn Go after C#. C# much more thought out lang than go. And It has channels too. The most ugly thing in the Go is the implicit interface implementation. Never knows what interfaces has the struct.
He wasnt skeptical of go, but templ and htmx, both of which are very young and will improve a lot over the next few years. Also, he’s so deep in react, he couldnt justify it for himself.
@@hamm8934 Ah I got it. There is a big distinction between Templ / HTMX and Go. I'm thinking Go in broader terms, as a general purpose language, not just as a solution to build UIs.
@@hamm8934 also a "fullstack app stack" in go is not really beginner friendly since go is a "structure your project yourself" language, which propably scares of a lot of people. myself, i build a "dev" command with wgo, which works great, but is pretty advanced. also templ lsp is a bit frustating, so i switched to Gomponents, with the downsides of no intellisense for tags and attributes and you cant copy paste stuff from other projects or components. kinda makes sense that people go back to js, since its easier and sometimes you just need to get stuff done quickly
What you are talking about bro ? Go is the neat and clean language. Half of the community love go only for its simplicity, minimal and neat code. And bonus is it has almost fastest compiler.
@@tokisuno So you must be loving typing this in js/ts and probably in any other lang :- try { const res =await funcMightThrowErr(opts); return res; } catch (error) { // handle error or return } than typing := res,err := mightThrowErr(opts) if err != nil { // handle error return }
@@awesome-coding I was skeptical because of its typing system. Now, after building, launching and maintaining 3 medium (100000LoC) to large (1_000_000 LoC) that Elixir covers more of the pain points of developing a server-side web app and web backend than go, and has tons of more useful, unique features that make the bug resolution easier than having a static type check. Also the memory profile of elixir is much more stable than go while still having the flexibility of using rust or zig for CPU-bound tasks. So putting it all together, I will choose Elixir for any server code rather than Go and Rust, given the chance. And the community and the documentation! Just amazing! If you like, I can go on about it for the rest of the day. Just know that Elixir is probably the most underrated language I have seen.
@@awesome-coding Yeah, it true it's pretty steep unfortunately. THANK YOU for talking about the real purpose of OOP. I think Go and Rust are the true spiritual heirs of OOP
@@log8746 In one function you just need one try catch block and in the catch block you can write logic to segregate the errors by its type. Now compare this with golang error handling where after every function call you need to add a if statement to check if the function is returning error
I'm actually really excited about it, and I am planning to integrate it in one of the projects I am working on. But I am curious to find out why you don't like it.
* The most ugly thing in Go is the implicit interface implementation. Never knows what interfaces a struct implements * Dependency injection in GO is very convoluted * Handling dependencies (external packages versioning) in GO is more difficult than in C#. * The way to handle attaching methods to pointers and values. They are different in behavior and polymorphism can be broken. Theres an example of that in the book - Go n Action.
@@awesome-coding unlike go, it has the best abstraction about OOP from Dr Alan. Go was also inspired by Erlang mailboxes Elixir/Erlang just does it better
@@awesome-coding I’m dumb. You are practical I guess 🙂😅 but yeah, I agree rust is difficult. But it is so enjoyable to write backend in it. I used Axum. It is like you wrote it once and have no surprises in prod as with js. And just writing rest APIs, connecting to db is not that hard. Also sqlx in rust is so good
Nah, Go is no fun, verbose as hell. It has just too many weird things going on too, like enforcing public or private methods by relying on case sensitivity. The community is also toxic as soon as you tell them to use anything but the stdlib. It's an awesome language if you don't want to have fun writing and want something worse than Java - in terms of being verbose.
@@flarebear5346 What I mean by that is that Golang, compared to Java, is more like C-low-level oriented. Because of this, you sometimes have to write a lot more boilerplate or reinvent the wheel in Golang compared to Java. It doesn’t offer the same level of abstraction that you get with Java’s ecosystem. E.g. write a transaction in Go vs write a transaction in Java with Spring.
@superakaike pretty sure that’s why a lot of people like Go - that you can actually do stuff from scratch without wanting to shoot yourself in the face.
Keep in mind that I am still mostly a Kotlin dev and Kotlin has amazing syntactic sugar. Cons compared to Go: - Long build times especially if you pair it with something like Spring which is pretty bad for microservices; - The JVM setup; - This might be subjective but Maven / Gradle are a nightmare to deal with.
@@awesome-coding Well, you said it all. Sometimes, when I’m planning to work on a new project, I wonder: “What programming language should I choose?” I often think of Kotlin, but then I remember that setting up a Kotlin project can be a nightmare, almost forcing you to use JetBrains’ IntelliJ IDEA to get it working. It’s such a shame for a modern language to have such poor tooling! Just this is enough for me to not use Kotlin. A programming language should not require a factory to be used. A single file and a simple command to run it should be enough.
@@awesome-coding Well, you said it all. Sometimes, when I’m planning to work on a new project, I wonder: “What programming language should I choose?” I often think of Kotlin, but then I remember that setting up a Kotlin project can be a nightmare, almost forcing you to use JetBrains’ IntelliJ IDEA to get it working. It’s such a shame for a modern programming language to have such bad tooling/ecosystem! A modern programming language should not require a factory to get started in.. Just this is enough for me to not use it.
@@awesome-coding Yeah the technology on top of which kotlin is based kind of sucks. However I think you should focus on something that Go really got right that is duck-typing, this is really what makes a lot of things easier compared to other languages and it's a game changer because it's duck typing that allows you to not care anymore about inheritance and "implements" of interfaces aka traits. If Kotlin ever decides to support it, I would forget about Go and invest time into Kotlin the day after, but I don't think they ever will.
@@awesome-coding The JVM setup!?!?!? I will say gradle and maven are terible and to just get a working jar can take weeks to figure out. Enjoy your time with go!!!!! Dont forget kotlin!!!!
go is too radical in it's vision of simplicity. anything beyond a toy program ends up being more complex and verbose than languages that are less simple. at least with more features you can decide whether or not you would like to use them. go doesn't give you any choices. it's one of the worst experiences i've had with a language.
@@awesome-coding go doesn't have map, filter, reduce, iterators, linked lists, etc. you have to reinvent the wheel every time you use it. the error handling is bad but that's on the lower end of my criticisms. interfaces and concurrency can also be very verbose and difficult. the simplicity makes the language worse.
@@awesome-coding my ideal language is gleam, but it's still in it's early stages and needs more time. my preferred language given all of the current options is rust. it has it's own set of drawbacks but the positives outweigh the negatives for me. i would prefer to use gleam for most things, but like i said it still needs more time.
@@justintie exactly I don't get why people are malding over this. try-catch either leads to a nesting hell or forces you to write more code just to prevent nesting too much.
Alan Kay seems to be the inspiration for the Golang logo.
😂😂😂 shame on you!
@@awesome-coding xD sorry it just seemed to me
@@dei8bitThat was hilarious
underrated comment 😂
how dare you! 😂😂😂😂😂
Going from Python to Go has been pretty fun for me tbh. So much just in the standard library.
Glad to hear!
That's an interesting comment. The Python stdlib is known to be quite large and varied.
I also went from python to go! I felt like it was kinda the opposite. Go's standard library is relatively small. Actually pretty helpful to learn the language. But I definitely felt like some things were missing coming from Python's expansive stdlib.
Concurrency deep dive!
Noted!
Yes, please.
Please!
Yes please!
yes pls!!!
Re: Java - for quite a few years now Java has RECORDS, so you no longer need to create getters, setters, constructor or methods related to comparing object.
You can simply define your movie type like this: `public record Movie(String name, double score) { }`
Good luck using those on old projects
Yep, and C#, which in Program.cs you could write:
```
var a = new Movie(Name: "Seven", Score: 10);
record Movie(string Name, float Score);
```
But the convention-based approach of Go looks reasonably nice to me (the uppercase versus lowercase names dictating public versus private). There was nothing I saw in the video that would make me switch to Go, but I can still respect it is elegant syntax.
for who is reading, this is only for making IMMUTABLE objects. it doesn't generate setters! sadly, we're not quite there in Java ;-;
@@victorbitencourt9481 records are intentionally immutable which is a massive benefit.
It's from scala actually(case class), and some of other higher level lang has this like kotlin dataclass
good luck if error is not nil
“_err” problem solved
😅
errors as values is the best feature of golang
@@sequbeats I agree, but it takes a bit of time to get used to them.
My life for syntax sugar:
f, ? := os.Open(filename) // return err and zero everything else out
f, ?err1 := os.Open(filename) // call func err1
f, ?err2 := os.Open(filename) // call func err2
I started with Go last year, but then tried Rust and then got in love with it.
Same
Same
Greatest intro, I'd love to see more of Go from you
More to come! Thanks for the feedback!
I was the biggest Go fanboy you could imagine but I'm sick to the teeth of having to check if every interface is nil or a pointer to nil or...
For me, the biggest shortcoming of go is all properties being optional. If you could set a compiler flag for required properties or add a lil syntax, it would go a long way.
It sounds like you are doing something wrong. The only case when you need to explicitly check for nil is usually error handling. Everything else can be covered by default values and nil receivers
@@bionic_batman if your function accepts an interface type as an argument, that argument can be nil at runtime
@@hamm8934yeah that's my biggest issue with it too. I'm surprised how little anyone else mentions this. I think your comment here is the first one I've seen, aside from all my own.
much love for go, especially the package manager saves me so many nerves
Go is looking pretty good, might give it a spin instead of hammering everything in with TypeScript
It's been a few weeks that I made the decision to ditch Node.js in the company I work for. Every one of our Node.js applications will be rewritten over time in Go or Java due to obvious reasons.
May I ask what those obvious reasons are?
i want to know too
@@maacpiash like idk, it's literally JavaScript?
@maacpiash @girxchin Glad you asked.
We started 3 years ago using Node.js. It was chosen as our main platform due to the following reasons:
a) The team's average technical skills and stack at that time.
Apart from myself, we had two beginner developers who only knew front-end JavaScript and had limited (college-level) knowledge of Python. We immediately discarded Python as an option for the back-end (the reasons for this should be obvious).
b) The size and scope of the applications we were building back then.
At that time, we were creating simple web apps for a single industrial customer, hosted locally. Few users, simple authentication mechanism, we theoretically had available as much computing power as we needed.
As time passed, the complexity of our customers' demands increased. As the codebase of our apps grew, maintaining the code and adding new features became increasingly difficult. This wasn't due to poor design, architecture, or lack of clean code. This is an inherent issue with any other dynamically typed language.
[Quick advice: if you want robust, less error-prone applications, you need a static/strict/strong-typed language.]
I felt it was time to enforce the adpotion of TypeScript. The team quickly got the hang of it. And we kept using it up to this day.
However, I knew that TypeScript would eventually reach its limitations.
As we gained more customers, we started building and selling larger, multi-tenant applications. Our team grew in size and experience, and the developers became familiar with concepts like types and pointers.
The perhaps not-so-obvious reasons for moving from Node.js to Go/Java are as follows:
a) JavaScript
The language was not created for back-end. It was adapted.
The most important issue is that as a dynamically typed language, it has a high level of ambiguity, particularly with its "truthy" and "falsy" values - for example, "if (0)" translates to "if (false)" in JS. Such a situation wouldn’t occur in a properly typed language like Go or Java.
b) Compilation and build size (Go advantage only)
Recently we deployed a complex queue handler app in a container with a single 9MB executable!
c) Memory consumption (Go advantage only)
It's fairly known that Go applications eat a lot (like, A LOT) less memory than Node runtime.
Also, Go's learning curve is shallow.
Hope this clarifies.
@maacpiash @girxchin Glad you asked.
We started 3 years ago using Node.js. It was chosen as our main platform due to:
a) The average technical skill and stack of our team at that time.
Except for myself, we had two beginner devs that knew only front-end JS and a bit (college knowledge only) of Python. Note: Python was immediately discarded as an option for back-end (I assume the reasons for this one are obvious here).
b) The size and scope of the applications we were building back then.
We were crafting simple web apps for a single industrial customer, hosted locally. Few users, simple authentication mechanism, we theoretically had available as much computing power as we needed.
Time passed by and the complexity of our customer demands increased. As the codebase of our apps was growing, it was becoming harder and harder to maintain the code and to adding new features. It was not a matter of design or architecture or clean code. It would happen with any other dynamically typed language.
[Quick advice: if you want robust, less error-prone applications, you need a static/strict/strong-typed language.]
I felt it was time to enforce the adpotion of TypeScript. The team quickly got the hang of it. And we kept using it up to this day.
However, I knew it was only a matter of time for TypeScript to not be sufficient anymore.
We gained more customers and started building and selling multi-tenant, bigger apps. The team grew in size and we are more experienced. Devs now understand types and pointers.
The perhaps-not-so-obvious reasons for moving from Node.js to Go/Java are:
a) JavaScript
The language was not created for back-end. It was adapted.
The most important thing: as it's dynamically typed, the level of ambiguity is high, especially because of the famous "truthy" and "falsy" values - "if (0)" translates into "if (false)" in JS. Something like that wouldn't compile in a properly typed language, like Go or Java.
b) Compilation and build size (Go advantage only)
Recently we deployed a complex queue handler app in a container with a single 9MB executable!
c) Memory consumption (Go advantage only)
It's fairly known that Go applications eat a lot (like, A LOT) less memory than Node runtime.
Also, Go's learning curve is shallow.
Hope this clarifies.
I really like explanation. It's clear, concise, and insightful. Keep it up!
Thank you!
I really like go. You can type go doc and the package name when you forget something you want to use and it pops right up in the terminal. Most of what you need is already in the language. Very nice.
Good tip!
Not everything is or was in the language. Why do frameworks or libraries like gin exist?
@@hugochavez6170 Most != everything.
@@hugochavez6170 because js devs come to Go and immediately start writing libraries instead of reading the docs
@@hugochavez6170 most != everything
I switched from Python to Go for both internal CLIs and webwidgets last year at work and haven't regret it.
I took the Elixir pill and I'm really happy
How is it?
Great video! Very insightful about OOP and objects.
Go is now actually simpler than Python.
go is beautiful. my current favorite
Imo Go is possibly the fastest GCPL there is. This is a great pity, since it's made to be so versatile and not tied to any ecosystem (*ahem*swift*ahem*). I feel Google made a mistake here when they created three different PLs (Go, Kotlin, Dart) for different use cases. They should only have made Go, then aggressively pushed Android to switch from Java to Go, likewise with Flutter. Now Kotlin is stuck with the JVM which slows down its compile speed while Dart is only about as fast as JavaScript even though JS as a dynamic PL is JIT compiled and Dart as a static PL is AOT compiled.
Good points!
I was waiting for this🙏🏻
✌️
It might just be me, but I kind of disagree about Go being concurrent. It using physical cores or threads is kind of irrelevant to how the code behaves, and it behaves as parallel threads, and that's the entire reason why Go's model sets itself apart from C++ for example, where parallelism often requires complex thread locking and mutexes, which don't preclude deadlocks in the least.
Concurrent to me is more like C++ coroutines, where you have many tasks you are juggling and it is explicit by the API that there's context switching happening within the scope of your app, not the operating system's automated scheduling.
In other words: if you start a bunch of tasks, and they all happen at the same time - then it doesn't matter if the scheduler technically split them up into small chunks, as far as your code is concerned, it's parallel.
Otherwise, if you implement coroutines in Go, what do you call those? Super/Strict Concurrency? Nah
I really want to, but the language has some strange paradigms that I'm not fond of and I keep returning to Rust due to finding I trust my code more. But Golang is very appealing in terms of all that it does well, and how flexible it is.
You forgot to mention web assembly. Go compiler can build in that and you effectively have a web app as well :)
I actually have a whole video on this exact topic - ua-cam.com/video/v8-yeWXCsi4/v-deo.html
rust syntax is closer to js than go which is one reason that i like it more. mainly the type system and pattern matching is something i find difficult to live without.
Fair :D
Started learning Go today. Because I can't constantly build and run my application, it's helped me to write features more incrementally by taking baby steps rather than defaulting to building and running my aoplication, especially when writing large chunks.
Great to hear!
things I dont get used to is, the awareness to know directly when to use * or & , why must have package name that follow its folder name?
Go is the future of web dev. By 2030, Go is going to be a powerhouse once Templ, HTMX, and Alpine get more mature.
Go is what typescript and pedantic pretend to be.
Go's simplicity makes programs extremely verbose
Thing is I don't think that any of the languages I use ( JS, PY, GO ) is good. I just use them that's all ...
Concurrent , but verbose, and generics being added late to the language, the libraries needs to adapt. Awesome standard library.
Error handling in Go reminds me of the "Try Pattern" in C# where a method would return a boolean for status and have one or more "out" parameters to get your stuff back.
I'm using Unity 90% of my time and I use this pattern A LOT to get around object lifecycle and I like it very much, so I guess GO would not be hard to adapt to.
I have also recently started exploring Go. My background is mostly in Java but I also have a good understanding of Python and JS as well. I'm not really impressed by my first week of learning Go. I like the fact that is compiled in a single binary. I actually like the errors as values because it forces you to think more about error handling and it would definitely be my go to for writing concurrent programs. However, I'm really annoyed with the systax sometimes, for example appending to a slice, type conversion etc
Do you think that I would get used to it and start liking it more once I get more familiar with the standard library and the "go way of things"? How was your experience in the beginning coming from JVM languages as well?
>Do you think that I would get used to it and start liking it more
It is quite possible. I hated some of the things in Go when I started working with it
Now, after about 5 years of working with it on daily basis I love it and understand why those things were done the way they were.
@@bionic_batman that's encouraging! Thanks
@@bionic_batman. After 5 years you can like every language.
You came from another universe.
I tried it, I had problems with reading files. Many problems. I did not have that problem with any other new languages I was starting with. I passed it after an hour of fights. You may say I'm noob, yes I am, but to me that's much hassle with simple things making work.
Would be interested to know what those problems were. My first Go use case was parsing, splitting & writing csv files. Whilst it wasn't quite as simple as something like NodeJS, it was not complex & extremely performant. Struct tags are a great feature, I find.
the best part is it's cross compiler and pair it with zig linker and it's just awesome
Didn't get the chance to spend too much time with Zig yet.
@@awesome-codingwith the zig linker you can make statically linked binaries even with libraries that use CGO. It's not flawless and I haven't seen perf testing, but it works
@@C4CH3S wdym by flawless?
@@TechBuddy_ it will sometimes fail to produce a binary whereas a regular linker wont.
@@C4CH3S huh wierd, i never had that issue. the zig linker is just the clang one with some stuff around it so it shouldn't be different
Folks warning ! Unused variables is a error in go
Why is this a problem?
its annoying
Java used to be a nice simple language too. Go is heading in the same direction
One of Golang's aims was to keep it as a simple language and so they won't keep adding features to it like they do to Java, C++ and Rust. And Java creators aim was never to keep it simple.
Go is a cool language at first but I found myself reinventing the wheel a lot for very simple things. Does it have a map now?
Yes... It had maps for long time now
Go ❤
I learned java first then switched to go and it is simple and fast I am loving it but it sucks at handling errors. Also I am following java these days and it seems it is improving a lot. Now Java method can also return multiple different type values, no setter getters required with record . they are also working on project like Lilliput, Valhalla and Leyden to improve performance and cut memory usage by almost 50%. If this happen I will happily switch to java again
I didn't know about Java supporting multiple value returns.
GO to C#
Much better and more modern in every aspect you can imagine.
Exactly.
I endorse this message
arent objects simply data structures + algorithms (methods) ? if so then GO handles objects, but operations like inheritance are not implemented
If I have to build a api or service, sure I am using go.
You should try the new Java
Please make a deep dive tutorial on concurrency please.
Will do!
I find go hard to follow and read
So the separation of structs and interface is a reaction to oop? To simplify things when before all these methods, and types were bound up in a class?
Am I understanding this correctly?
Great video.
Can anyone recommend good data validation library for Golang?
i like go for very small projects and prototyping. it's too simple and verbose when i want to be expressive. if there was a better balance it would be the perfect language. i like elixir phoenix more.
Fair
what will you build with it tho?
Mostly backends / microservices
go is my favourite language
Real
I wish you could use it in my job, but JavaScript frameworks like Next.js make everything move faster in development.
The syntax throws me off.
I prefer Rust because of this. Its syntax is more similar to JS.
It's the other way for me. I find Rust's syntax off compared to Go :))
That's a wild take. Rust has a strange syntax and Golang's syntax is in line with C, C++ and Java type of languages.
JS has the worst syntax, you need to create separate functions just to catch and handle errors, otherwise your code is going to nest too much. I like understanding how my code works at a deeper level and I would have to spend too many hours doing that in JavaScript.
Go is good but lack of AOP makes to difficult to create enterprise level system
Hmm... it is good enough for Uber, Docker, Twitch, Dropbox, or Netflix :D
@@awesome-coding they had to create a lot of libraries to make it enterprise level, ex. Uber has to create zap as go standard logger wasn't that good, jaeger for distributed tracing. I had to create my own tracer for printing the traces in logs. All these are autoconfigured in java
Just use Rust 🦀
I'm too dumb for that.
More Go pls
Noted!
Have you tried c#?
he did java for a long time, C# doesnt really offer anything game changing
@@ripple123 what game changing things does Go have which c# doesn’t?
@@ripple123C# is designed better compared to the cluster fuck of Go. I swear whoever designed Go did not put no thought into it.
@@diamondkingdiamond6289 Fully agree. I started to learn Go after C#. C# much more thought out lang than go. And It has channels too. The most ugly thing in the Go is the implicit interface implementation. Never knows what interfaces has the struct.
I was about to ask the same, all these features actually are present in C# with a better syntax and readability
What about Haskell?
Ah! There you were!
This is just a brain dump, not sure what I’m supposed to get from it 😢
After webdevcody's latest video I am sceptical about all that GO thing
I'm not familiar with his take on Go. Isn't he a fan?
He wasnt skeptical of go, but templ and htmx, both of which are very young and will improve a lot over the next few years. Also, he’s so deep in react, he couldnt justify it for himself.
@@hamm8934 Ah I got it. There is a big distinction between Templ / HTMX and Go. I'm thinking Go in broader terms, as a general purpose language, not just as a solution to build UIs.
@@hamm8934 also a "fullstack app stack" in go is not really beginner friendly since go is a "structure your project yourself" language, which propably scares of a lot of people.
myself, i build a "dev" command with wgo, which works great, but is pretty advanced. also templ lsp is a bit frustating, so i switched to Gomponents, with the downsides of no intellisense for tags and attributes and you cant copy paste stuff from other projects or components. kinda makes sense that people go back to js, since its easier and sometimes you just need to get stuff done quickly
@@awesome-coding100% agree with you
maybe it just me i just don't like golang syntax
it feels pretty great once you use it enough
@AnnasVirtual what's your background?
What you are talking about bro ? Go is the neat and clean language. Half of the community love go only for its simplicity, minimal and neat code.
And bonus is it has almost fastest compiler.
@@SirJagerYT it's probably just typing := which to be fair, i still hate typing to this day.
@@tokisuno So you must be loving typing
this in js/ts and probably in any other lang :-
try {
const res =await funcMightThrowErr(opts);
return res;
} catch (error) {
// handle error or return
}
than typing :=
res,err := mightThrowErr(opts)
if err != nil {
// handle error
return
}
Huh. I started with go and then Rust. But now moving to Elixir.
A lot of Elixir mentions in the comments - interesting.
@@awesome-coding I was skeptical because of its typing system. Now, after building, launching and maintaining 3 medium (100000LoC) to large (1_000_000 LoC) that Elixir covers more of the pain points of developing a server-side web app and web backend than go, and has tons of more useful, unique features that make the bug resolution easier than having a static type check. Also the memory profile of elixir is much more stable than go while still having the flexibility of using rust or zig for CPU-bound tasks. So putting it all together, I will choose Elixir for any server code rather than Go and Rust, given the chance. And the community and the documentation! Just amazing!
If you like, I can go on about it for the rest of the day. Just know that Elixir is probably the most underrated language I have seen.
Same
htmx, htmx, htmx
Why not F#? I find F# much more expressive, safer, and just as fast.
I’ll have to check it out
Great video ! Will you work with Rust ?
I played a little bit with Rust, but I'm not that confident in my Rust skills yet. The learning curve is pretty steep compared to Go.
@@awesome-coding Yeah, it true it's pretty steep unfortunately. THANK YOU for talking about the real purpose of OOP. I think Go and Rust are the true spiritual heirs of OOP
GO error messages are horrible
Only pain is error handling
It's a matter of getting used to it.
how, can you explain? To me it seems a lot better than using try-catch
@@log8746 In one function you just need one try catch block and in the catch block you can write logic to segregate the errors by its type. Now compare this with golang error handling where after every function call you need to add a if statement to check if the function is returning error
Thanks to The Primeagen Marketing 😂
I guess if you don't want to use generics, you don't have to use generics :)
Go is awesome because it doesn't have all the OOP bullshit
its not clean at all
Exactly.
pokemon GO??? pokemon Rust!!!
😂
Concurrency go deep dive
Will do!
Rust
You know, and I know that go sucks.
But let's pretend it does not
I'm actually really excited about it, and I am planning to integrate it in one of the projects I am working on.
But I am curious to find out why you don't like it.
* The most ugly thing in Go is the implicit interface implementation. Never knows what interfaces a struct implements
* Dependency injection in GO is very convoluted
* Handling dependencies (external packages versioning) in GO is more difficult than in C#.
* The way to handle attaching methods to pointers and values. They are different in behavior and polymorphism can be broken. Theres an example of that in the book - Go n Action.
Concurrency deep dive please
Will do!
Try elixir to see real message passing...
will do! thanks for the suggestion
@@awesome-coding unlike go, it has the best abstraction about OOP from Dr Alan. Go was also inspired by Erlang mailboxes
Elixir/Erlang just does it better
use a better lanague kids use c#
Why not Rust?
Better safer code align with Rust a lot
Rust is way more difficult, or maybe I’m just dumb 🥲
@@awesome-coding I’m dumb. You are practical I guess 🙂😅 but yeah, I agree rust is difficult. But it is so enjoyable to write backend in it. I used Axum. It is like you wrote it once and have no surprises in prod as with js. And just writing rest APIs, connecting to db is not that hard. Also sqlx in rust is so good
Which frontend to be combined with?
Any frontend works just fine.
Awesome, but it's still hard to find a job
I agree - Java and C# are still the best bets for comfy enterprise jobs
"Why I’m Switching To Go in 2024" because you are a healthy individual?
Once Go receives syntax for error handling I'm hopping into that bandwagon.
i tried using go to make websites but there is no good way of making auth and there is no ecosystem.. maybe in a few years
also i hate how the go docs site makes people not want to write actual documentation
🦀
the only thing golang needs in my opinion is try and catch block 🙏
Go error handling is awful
there is just nothing good about go
Go can’t run in browser like js
it can via WASM :)
@@awesome-coding hmm that’s true, didn’t think about it before. Thank you for the pointer
go compiled as one binary is killer, now I use ncc to compile my node.js app to make it single file
The number of comments complaining about having to consider and handle all errors is why we have so many bad libraries and crap code floating around.
If you want reliable messages passed between objects, you should learn Elixir, not Go.
Nah, Go is no fun, verbose as hell. It has just too many weird things going on too, like enforcing public or private methods by relying on case sensitivity. The community is also toxic as soon as you tell them to use anything but the stdlib. It's an awesome language if you don't want to have fun writing and want something worse than Java - in terms of being verbose.
I can't believe that someone actually thinks go is more verbose than java, like what are you talking about
@@flarebear5346 What I mean by that is that Golang, compared to Java, is more like C-low-level oriented. Because of this, you sometimes have to write a lot more boilerplate or reinvent the wheel in Golang compared to Java. It doesn’t offer the same level of abstraction that you get with Java’s ecosystem. E.g. write a transaction in Go vs write a transaction in Java with Spring.
@superakaike pretty sure that’s why a lot of people like Go - that you can actually do stuff from scratch without wanting to shoot yourself in the face.
@@0oShwavyo0 Yeah, you’re totally right, and for everyone who likes that, I also think Go is definitely an awesome language 👍
Go? in 2024? horrible little language that belongs in the bin. Sorry it's kills braincells.
i still think kotlin is the goat. Prove me wrong
Keep in mind that I am still mostly a Kotlin dev and Kotlin has amazing syntactic sugar.
Cons compared to Go:
- Long build times especially if you pair it with something like Spring which is pretty bad for microservices;
- The JVM setup;
- This might be subjective but Maven / Gradle are a nightmare to deal with.
@@awesome-coding Well, you said it all. Sometimes, when I’m planning to work on a new project, I wonder: “What programming language should I choose?” I often think of Kotlin, but then I remember that setting up a Kotlin project can be a nightmare, almost forcing you to use JetBrains’ IntelliJ IDEA to get it working. It’s such a shame for a modern language to have such poor tooling!
Just this is enough for me to not use
Kotlin.
A programming language should not require a factory to be used. A single file and a simple command to run it should be enough.
@@awesome-coding Well, you said it all. Sometimes, when I’m planning to work on a new project, I wonder: “What programming language should I choose?” I often think of Kotlin, but then I remember that setting up a Kotlin project can be a nightmare, almost forcing you to use JetBrains’ IntelliJ IDEA to get it working. It’s such a shame for a modern programming language to have such bad tooling/ecosystem!
A modern programming language should not require a factory to get started in..
Just this is enough for me to not use it.
@@awesome-coding Yeah the technology on top of which kotlin is based kind of sucks.
However I think you should focus on something that Go really got right that is duck-typing, this is really what makes a lot of things easier compared to other languages and it's a game changer because it's duck typing that allows you to not care anymore about inheritance and "implements" of interfaces aka traits.
If Kotlin ever decides to support it, I would forget about Go and invest time into Kotlin the day after, but I don't think they ever will.
@@awesome-coding The JVM setup!?!?!? I will say gradle and maven are terible and to just get a working jar can take weeks to figure out. Enjoy your time with go!!!!! Dont forget kotlin!!!!
Should of went rust 😂
I'm not smart enough for Rust 😅✌️
go is too radical in it's vision of simplicity. anything beyond a toy program ends up being more complex and verbose than languages that are less simple. at least with more features you can decide whether or not you would like to use them. go doesn't give you any choices. it's one of the worst experiences i've had with a language.
I feel like this verbosity is linked to error handling - am I right?
@@awesome-coding go doesn't have map, filter, reduce, iterators, linked lists, etc. you have to reinvent the wheel every time you use it. the error handling is bad but that's on the lower end of my criticisms. interfaces and concurrency can also be very verbose and difficult. the simplicity makes the language worse.
@@bear458ziif-s I understand. Our of curiosity - what's your preferred language?
@@awesome-coding my ideal language is gleam, but it's still in it's early stages and needs more time. my preferred language given all of the current options is rust. it has it's own set of drawbacks but the positives outweigh the negatives for me. i would prefer to use gleam for most things, but like i said it still needs more time.
@@bear458ziif-s Thanks for the details!
Rust is way better than Go in every aspect. 🎉
I believe you, but I’m too stupid to get Lifetimes and async / await in Rust
Great video! I'd love to listen to your takes on Gleam... I know it's new but it feels super promising
I am planning to explore the whole Erlang world sooner or later. I just need 3 free months for it :))
ohh the if err != nil language
how could they get everything right and ruin it with the worst error handling
The worst error handling is by far the one of TypeScript.
they didn't ruin anything, if err != nil is fine, better than try catch for sure
@@justintie exactly I don't get why people are malding over this. try-catch either leads to a nesting hell or forces you to write more code just to prevent nesting too much.