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.
HI @nyagah243 ,Is it possible if you can guide me in the future related to the journey, Cuz I've learnt python and now thinking to move on to Go. (I Will Wait For Your Reply)
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.
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.
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.
I like Go overall, however after trying it for a week now I can say the thing I dislike the most is... The visual noise of Go code. When you write Go there is often indentation that is unavoidable and it breaks the visual flow of things. Like the most common example is the classic: if err != nil {} pattern. While explicit error handling is superior to the try/catch alternative I really wish there was a syntax that didn't require nesting and didn't break the visual flow. Aside from that I don't percieve any problems yet.
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.
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.
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.
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
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.
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?
What do you think is better to learn from scratch at the moment, Go or Java? I have some basic experience with C++ and a foundation in computer science since I’m studying in this field, but I don’t have any commercial experience yet. Could you please advise if it’s not too much trouble?
These are difficult times, and it's hard to find a job. In this context I would definitely learn Java just to increase the odds of being hired. There are far more jobs in Java than in Go. In any other scenario, I would pick Go for all the reasons mentioned in the video.
@@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.
@@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
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 switched from java to go after many years of experience using java. And I think backend is backend. What exact tool are you using to build backend is not that important to be honest.
@@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.
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.
Idk i love js simplicity and flexibility, and looking for another form of java but not exactly like java and i feel like go fits it its more simple and still have the principle, and a little more flexability. Java has too many tools and i find it really hard to find what to learn and i hate the fact that im nearly forced too use frameworks. I wanna have option but not forced into it if you know what i mean. Dont come at me too hard still pretty new just my thoughts.
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
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.
@@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
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.
@@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
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.
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
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.
@@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 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.
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 }
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
@@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
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.
HI @nyagah243 ,Is it possible if you can guide me in the future related to the journey, Cuz I've learnt python and now thinking to move on to Go. (I Will Wait For Your Reply)
Concurrency deep dive!
Noted!
Yes, please.
Please!
Yes please!
yes pls!!!
I switched from Python to Go for both internal CLIs and webwidgets last year at work and haven't regret it.
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
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 love the ridiculously easy cross compiling of Go :-)
Go is looking pretty good, might give it a spin instead of hammering everything in with TypeScript
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?
Greatest intro, I'd love to see more of Go from you
More to come! Thanks for the feedback!
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 like Go overall, however after trying it for a week now I can say the thing I dislike the most is...
The visual noise of Go code.
When you write Go there is often indentation that is unavoidable and it breaks the visual flow of things.
Like the most common example is the classic:
if err != nil {}
pattern.
While explicit error handling is superior to the try/catch alternative I really wish there was a syntax that didn't require nesting and didn't break the visual flow.
Aside from that I don't percieve any problems yet.
Fair enough.
I took the Elixir pill and I'm really happy
How is it?
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!
I really like explanation. It's clear, concise, and insightful. Keep it up!
Thank you!
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
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 - ruclips.net/video/v8-yeWXCsi4/видео.html
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 was waiting for this🙏🏻
✌️
go is beautiful. my current favorite
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 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.
I started with Go last year, but then tried Rust and then got in love with it.
Same
Which one do you like better and is easier to maintain?
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
Go is very based. It’s very popular but its user base is not vocal like Rusts. Which is a good thing!
Fact!
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?
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!
how does it compare to c++?
Go is now actually simpler than Python.
Concurrency deep dive! Subscribed!
Thank you!
Please make a deep dive tutorial on concurrency please.
Will do!
Concurrent , but verbose, and generics being added late to the language, the libraries needs to adapt. Awesome standard library.
what will you build with it tho?
Mostly backends / microservices
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?
What do you think is better to learn from scratch at the moment, Go or Java? I have some basic experience with C++ and a foundation in computer science since I’m studying in this field, but I don’t have any commercial experience yet. Could you please advise if it’s not too much trouble?
These are difficult times, and it's hard to find a job. In this context I would definitely learn Java just to increase the odds of being hired.
There are far more jobs in Java than in Go.
In any other scenario, I would pick Go for all the reasons mentioned in the video.
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 compiled as one binary is killer, now I use ncc to compile my node.js app to make it single file
What about Haskell?
Ah! There you were!
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
arent objects simply data structures + algorithms (methods) ? if so then GO handles objects, but operations like inheritance are not implemented
Can anyone recommend good data validation library for Golang?
Great video.
I find go hard to follow and read
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
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.
Go ❤
Concurrency deep dive please
Will do!
Folks warning ! Unused variables is a error in go
its annoying
I wish you could use it in my job, but JavaScript frameworks like Next.js make everything move faster in development.
I switched from java to go after many years of experience using java. And I think backend is backend. What exact tool are you using to build backend is not that important to be honest.
That's fair.
Which frontend to be combined with?
Any frontend works just fine.
If I have to build a api or service, sure I am using go.
Why not F#? I find F# much more expressive, safer, and just as fast.
I’ll have to check it out
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
why not Rust?
I'm not smart enough for Rust 😅
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.
Idk i love js simplicity and flexibility, and looking for another form of java but not exactly like java and i feel like go fits it its more simple and still have the principle, and a little more flexability. Java has too many tools and i find it really hard to find what to learn and i hate the fact that im nearly forced too use frameworks. I wanna have option but not forced into it if you know what i mean. Dont come at me too hard still pretty new just my thoughts.
More Go pls
Noted!
Scary syntax
😅
Concurrency deep dive
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
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
go is my favourite language
Real
You should try the new 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.
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
htmx, htmx, htmx
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 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
This is just a brain dump, not sure what I’m supposed to get from it 😢
Concurrency go deep dive
Will do!
Awesome, but it's still hard to find a job
I agree - Java and C# are still the best bets for comfy enterprise jobs
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 to C#
Much better and more modern in every aspect you can imagine.
Exactly.
I endorse this message
Thanks to The Primeagen Marketing 😂
Zig.
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
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.
Kinda modern C 😍
Yep!
its not clean at all
Exactly.
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
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
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
}
Why in the cloud? Why not woke rust?
I guess if you don't want to use generics, you don't have to use generics :)
Ah, you switch from Java/Kotlin to Go.
I am trying :D
Eh, pretty convincing but I'm gonna sleep on it til 2025.
"Why I’m Switching To Go in 2024" because you are a healthy individual?
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
🦀
Rust
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 :))
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.
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!
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
the only thing golang needs in my opinion is try and catch block 🙏
I swapped from Go to Ada with no regrets.
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