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.
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.
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.
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.
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.
@@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
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.
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.
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 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-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
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?
@@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.
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.
@@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.
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.
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 }
@@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 simply don't buying it. I can agree that GO is better than Java (btw, almost any modern language is better than Java) but I can't understand how it's better than Kotlin. There is nothing in video about it.
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
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.
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-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
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.
@@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
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 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
The only thing I do not like is the size of the binary, - especially on projects which include multiple libs. It's in the order of multiple megabytes, even for simple cmdline utils. That's not ideal.
why I hate Go: null pointer exception, error handling, poor type system, context (no typesafety) why I love Go: compile, huge std & nice ecosystem, performance, easy multithreading for me "nil" and context is most problem error handling could be fixed with new syntax. but it also requires upgrade type system
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! 😂😂😂😂😂
Concurrency deep dive!
Noted!
Yes, please.
Please!
Yes please!
yes pls!!!
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.
I love the ridiculously easy cross compiling of Go :-)
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
much love for go, especially the package manager saves me so many nerves
I switched from Python to Go for both internal CLIs and webwidgets last year at work and haven't regret it.
Greatest intro, I'd love to see more of Go from you
More to come! Thanks for the feedback!
Go is looking pretty good, might give it a spin instead of hammering everything in with TypeScript
I really like explanation. It's clear, concise, and insightful. Keep it up!
Thank you!
I took the Elixir pill and I'm really happy
How is it?
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.
@@hamm8934 Fork needed?
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
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!
Great video! Very insightful about OOP and objects.
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.
go is beautiful. my current favorite
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
Concurrency deep dive! Subscribed!
Thank you!
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
I was waiting for this🙏🏻
✌️
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
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
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
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.
Go is now actually simpler than Python.
Great video.
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.
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.
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?
what will you build with it tho?
Mostly backends / microservices
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.
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
Please make a deep dive tutorial on concurrency please.
Will do!
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?
Go is very based. It’s very popular but its user base is not vocal like Rusts. Which is a good thing!
Fact!
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 ...
Go ❤
Concurrent , but verbose, and generics being added late to the language, the libraries needs to adapt. Awesome standard library.
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
Can anyone recommend good data validation library for Golang?
Scary syntax
😅
More Go pls
Noted!
Concurrency deep dive please
Will do!
I find go hard to follow and read
Folks warning ! Unused variables is a error in go
Why is this a problem?
its annoying
Go's simplicity makes programs extremely verbose
But extremely obvious as to what is happening...
@@beachfeet6055 nah it make things very complicated at the end
If I have to build a api or service, sure I am using go.
Concurrency deep dive
What about Haskell?
Ah! There you were!
I wish you could use it in my job, but JavaScript frameworks like Next.js make everything move faster in development.
arent objects simply data structures + algorithms (methods) ? if so then GO handles objects, but operations like inheritance are not implemented
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.
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
Which frontend to be combined with?
Any frontend works just fine.
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.
Why not F#? I find F# much more expressive, safer, and just as fast.
I’ll have to check it out
This is just a brain dump, not sure what I’m supposed to get from it 😢
why not Rust?
I'm not smart enough for Rust 😅
Thanks to The Primeagen Marketing 😂
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
}
You should try the new Java
Concurrency go deep dive
Will do!
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
go compiled as one binary is killer, now I use ncc to compile my node.js app to make it single file
I simply don't buying it. I can agree that GO is better than Java (btw, almost any modern language is better than Java) but I can't understand how it's better than Kotlin. There is nothing in video about it.
Go error handling is awful
Rust
Kinda modern C 😍
Yep!
go is my favourite language
Real
htmx, htmx, htmx
its not clean at all
Exactly.
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
Awesome, but it's still hard to find a job
I agree - Java and C# are still the best bets for comfy enterprise jobs
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!
pokemon GO??? pokemon 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 :))
I guess if you don't want to use generics, you don't have to use generics :)
Eh, pretty convincing but I'm gonna sleep on it til 2025.
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
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
🦀
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
GO to C#
Much better and more modern in every aspect you can imagine.
Exactly.
I endorse this message
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
Why in the cloud? Why not woke rust?
Once Go receives syntax for error handling I'm hopping into that bandwagon.
"Why I’m Switching To Go in 2024" because you are a healthy individual?
I think i will GO
away from GO
you GO ahead and do that!
@@awesome-coding 😂
GO error messages are horrible
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.
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
Go is awesome because it doesn't have all the OOP bullshit
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
The only thing I do not like is the size of the binary, - especially on projects which include multiple libs. It's in the order of multiple megabytes, even for simple cmdline utils. That's not ideal.
It uses statically linked libc, so this is to be expected.
why I hate Go: null pointer exception, error handling, poor type system, context (no typesafety)
why I love Go: compile, huge std & nice ecosystem, performance, easy multithreading
for me "nil" and context is most problem
error handling could be fixed with new syntax. but it also requires upgrade type system
Fair enough!
Man stop with this monotonic intonation pattern you sound like AI, very uncanny
I would like to be able to change this, but sadly this is the way I speak :))
The syntax is too weird for me, I keep Typescript. Maybe Rust one day if I need better performances.
Fair. I find Rust's syntax more difficult than Go's btw.
Just use Rust 🦀
I'm too dumb for that.