Go being "dumb" is its biggest upside. When you give programmers fancy tools to avoid problems, they will get themselves into subtle more dangerous problems. All styles of programming work at the small scale
It depends on what you're writing. If it's a 'normal' backend? Sure, a 20 K LOC Go backend will likely be easier to get into than something equivalent in C++ or even Rust, since the 'fancy' tools of these languages lead to more complex interactions. But at the same time, looking at e.g. Android etc (note that's made by Google, the company behind Go), then they actually use Rust, not Go. Because while these tools might make for some more complex interactions, they also allow you to assure some things that tend to be crucial in these environments, making it harder to write code that misuses components. That actually makes it easier to onboard devs to these projects.
@@9SMTM6i promise you the reason why Google uses rust or C++ for certain products is simply for performance and better low level access, not implementation restrictions
As mainly an Ops guy I agree. Developers also tend to try to use all those fancy tools all the time and screw up big time by implementing shit that should be handled elsewhere. It's a nightmare to troubleshoot. KISS.
@@9SMTM6 Android is a bunch of C and C++ with a huge glob of Java on top, only quite recently there's been a bit of a push to start replacing some parts with Rust. Either way it's horrible all the way from top to bottom and nothing about those horrible languages (C++, Rust) can help the architectural mess of complexity that is Android. These languages are only being used for performance reasons. If they could get away with it, they'd have no reason not to written the entire thing in Java. More against your point, Google enforces the use of a very strict subset of C++ which basically bans most of the inherently complex language / library features outright, plus they have access to (arguably) the best engineers out there, and they still end up with a mess.
Bro. So on point. I've been saying it for years. The worst part of python is the package / dependency management. You know it's bad when even JS wins by a large margin.
As a Rust dev, when you say "it will be a lil bit slow" when you cross compile your hello world, it kinda makes me cry that you consider 1.8s "slow" compiling :')
Go's best strength is how absolutely simple it is to learn, assuming you are generally familiar with programming. With no exaggeration, you can go from knowing absolutely nothing about it to writing complete and useful applications within the same day, just consulting some docs/examples for the syntax along the way. The tooling around it is just as simple, and everything you needs comes included.
Coming from python, I also miss things related to randomness. Pick a random element from an array, pick with weights, pick repeatedly, shuffle an array etc. All aren't too hard to implement yourself from the RNG in the standard library, but it's nice to have them built-in.
The Reader/Writer conventions in Go make it possible to write insanely testable code! I've written many pipelines which work on the file system, but are fully testable without touching the file system because the pipelines only work on io interfaces. It's incredibly useful! It's not as easy in TypeScript land for example, though some Web API stuff seems like it's gradually bringing it closer. You can also implement these interfaces yourself, but when the standard library does it all for you and the entire ecosystem works off of that library, it's SO MUCH work taken off of your plate.
I learned C++ in university and my first job after graduating was C++. Then, one day we were told that we're switching to Go. I absolutely *love* Go. I have never liked C++ and came to detest it after a while.
I did not call Go mid, I said Go is mid in many things. One example is in the type system, another is in the performance, the package system was also mid for a long time until modules happened. But Go is designed in such a way that these subsystems, even if they're not perfect in any one thing, can fit together perfectly to create something that is hard to beat. In other words, the Go experience is a sum of all its parts.
3 วันที่ผ่านมา
@@melodyogonna Well I agree. =) My point was more that there are so many languages out there that do things far worse than go. So I would say it is probably above mid when compared across the board.
Go is like that ex you can't help but keep coming back to - practical, reliable, and just works everywhere! 😅 Love how you broke down the three key strengths, especially the standard library part. As a Lambda developer, those cold start numbers are seriously impressive. Your love-hate relationship with Go is so relatable 😄
Go is really something where you love it's simplicity and hate it when you see something missing that's in every other language. Like removing an element from a slice. You have to write those functions yourself. Still, I really fell for it. It replaced my #1 language (PHP) because of it's static typing and I am trying to stay as far away from TypeScript as possible.
First six minute love affair with io.Reader is odd. Java has had InputStream and BufferedReader since 1995. Go’s standard lib is incredibly lacking. As another commenter said: no queues, sets, or heaps.
What an honest man. What I don’t get is why people keep apologizing for using it!
4 วันที่ผ่านมา
Go is so good for scripting as well. Btw, the ability to profile binaries was not mentioned here, a bit too deep perhaps, but that it can further increase the speed by profiling a running binary is also great.
I really like V which is heavily inspired by Go, but it has some syntatic sugar that is nicer and it just compiles down to C. It's still beta software so it have a long way to mature still. but I really like the simplicity of the language. I've gone through some of the tutorials for Go, but it just seems like a bit of an awdward language to write it. If I did it for work I would learn it a lot more.
GoLang it's fine, until you realize that the slice function of a list is sliced by reference. Also if you don't specify the go.version in go.mod, you will have weird behaviour and might use old golang code irrelevant of the go version that you are compiling and running your code. (hint: because it's explicitly implemented like that). And I completely not support such way of handling backward compatibility. At least, if, for the newer versions it is crucial to set the go.version in go.mod, fail early before someone finds some bug on production because of that faulty implementation.
It's not Go that's ensuring portability, other languages can do this as well. It's the standards independent of Go (mostly POSIX) that's ensuring portability.
DAX, in the post you mention “The sst dev CLI supports running your Go functions Live.” Does this implementation support breakpoints in go on V3? Great video, thanks, we continue to use Go on Lambdas and SST when we need performance optimizations
i think it's awesome you support Go now. Still I never faced a use case actually using it :( basically all my lambdas are i/o driven so node makes sense most of the time. When do you think does it make sense to use Go over Node? For cold-start related problems? I think those are problems for systems with no users, so what are actually good use cases? Would love to hear that
Go's concurrency model makes IO and networking so smooth, so to me, there at least even. I don't see what node does that's superior that you'd just discard any alternatives. But I'm guessing it's just your experience...
@@nesssel good answer. He may have gone a little extreme by saying Node is the best for I/O bound apps. But given that Node is very good with I/O bound apps, what then would be his motivation to rewrite his apps or use Go for newer ones? If you ask me, reducing cold-starts plus faster execution might be a reason. Saves money, no matter how small. It might not seem significant but given that Go is easy to learn, might worth it. As for me, I will stick to Rust for most personal usecases (for now), Golang for a team (most ppl don't like going deep 😃) and Node (TS) when I am forced to 😃.
Go would be my ideal language if it had (1) immutable by default variables (or val vs var like in Kotlin) (2) Result / Nullable types (3) a good convention/culture for variable names instead of the dumb single-letter variables. Seriously... those single-letter variables get warnings from so many linters in so many languages, but somehow became the default in go. Who let this happen?
There are indeed some strange naming conventions for variables, arguments, etc. in the stdlib, which by extension has become the convention for the entire ecosystem. I am mainly a Zig dev, which is all about making everything explicit and verbose to convey intent, and it is jarring when I make a switch to Go and everything is using single-letter names and abbreviations for words that are already short. I can get used to it, I pretty much always just follow conventions for whatever language I am writing ("when in Rome"), but it never feels nice using "r" to describe a "Reader" etc, especially when its is part of a public API.
@@ForeverZer0Zig is so verbose it turns me off. Casting shouldn’t be that verbose. IMoO zigs anytype is terrible to find out what implements an interface.
@@metaltyphoon I find that if I am ever explicitly using anyopaque, anytype or doing some form of inspection on a runtime value, then it is because I am going against the language paradigms, and trying to shoehorn what works in another language into it. With the exception of designing the internals of my own "interface" (no actual such thing in ZIg, just a design pattern), those aren't really something that should be used, that is what comptime is for: you get type-safety. You use comptime-functions that return types, which fulfill your interfaces, not test types at runtime. All that said, I understand peoples' dislike of the syntax: I myself procrastinated learning in-depth for over a year because I thought the syntax was terrible. After powering through it anyway and doing a deep-dive, it begins to make sense, and it has its own purpose, allowing you to do some really elegant things that are near-impossible in any other compiled language. Casting is overly verbose, no arguments there. It gets worse when the destination type cannot be inferred, and you have to start throwing in @as, @alignCast, and @ptrCast into a single cast. I understand is offers more precise control, but some shorthand cast built-ins would be very welcome.
Hi, didn't watch the video, but just stopped by for this comment because of the title. I don't know Go, but I do know Rust, and that's exactly how I feel about Rust!
So the reasons why you like Go are: - it's better than POSIX compliant, it's Plan9 compliant (no mistery there, it was developed by Rob Pike) - it creates binaries, almost like it was the only language that can do that (and no, those aren't standalone, pretty sure you still need libstd for it. Last time I checked, it doesn't use musl, so no) - it's easy to deploy.. Not! It's just that like many other languages, it can be shipped to AWS Lambda. That ain't a strictly Go thing, dude From a brief inventory... Not a solid foundation
@@gavinh7845 they are statically linked on systems that allows it. FreeBSD and macOS don’t. Besides anything with DNS most likely will link w libc so yeah…
@@thelambdafunctioni guess it depends on your goals. The binaries are larger, for me, it's never been a problem due to the low cost of bandwidth and high speeds available nowadays. I'm not a super duper smart intelligent programmer though, but I'm self made in plugins and a few fun internet games and tools I wrote in Go, which required automation of provisioning servers, pushing my software to them, and running it. Lamda functions aren't the only way to write software. I just keep writing monoliths (or basic structures, like distributed queues with workers).
Go doesn't require something like libstd. which is why you can compile for any OS, ARCH from whatever machine you are using. if you need something like CGO that may be different story.
go is too simple to a fault in my opinion. there's just so much more boilerplate and it's painful. for simple scripts and things like that it's nice, but to build a real application is just pain.
Can we please agree to stop using this type of clickbaity titles: X is great I hate it? Please I'm begging you, I can't afford to rage break stuffs any more
Yeah, I definitely hate Go as well. If I can't have braces on their own line, I consider that an error in the brain of whoever designed that language. The designers excuses for why are completely bogus too, especially given that you can add a superfluous brace at these points and have it on its own line and it will still work as normal. I'm thinking of writing my own Go compiler just so I can have braces on their own line.
@@FirstYokai And yet not once did I call any of them stupid. But I suppose reading comprehension is a skill and you'll only learn by me pointing out your mistake. To make it 100% clear, because you need the help, I'm not saying I didn't call them stupid because I didn't refer to any of them by name, I'm saying I didn't call them stupid because I wasn't calling anyone stupid with my comment.
I still don't see myself taking up Go anytime soon. They make a few... to me disturbing design choices. Primary being no type level handling for nullability, when this was already a solved problem when they designed Go, and when I can't see a good reason not to do that. Then we have their extremely weird enum replacement iota. Also they went for ages without any concept of generics, which has influenced their standard library design as well as popular packages. I don't say that they don't have their strengths. It's a simple language, they have pretty good concurrency design, and it's fast to compile. But the design choices above make me afraid of what other choices might be hidden in details, let alone the fallout from these desidn choices themselves.
Go has a lot of advantages that I like. The biggest disadvantage I see currently is the lack of community packages, JS ecosystem is just superior there.
Go is designed to discourage the use of third party packages. If it ain’t bringing substantial gains, don’t import it. YOU can do a better solution for YOUR specific problem.
@@AlexGarcia-ir7fl Every dead language/framework uses this excuse. Oh we don't have a lot of packages because we are all 120 IQ and are all solving brand new problems!
I hate being bipolar, it's AWESOME
I love hating this
ok kanye
I still dont know why dax doesnt have a yt channel.
bro's busy building actual stuff
Creating TH-cam videos is a lot of work. If you have a job it's hard
Thanks Dax, just convinced me to finally take the plunge and learn Go!
Yep. I could see myself using it as a direct result of this video.
I was expecting to open the comment and see a reply saying "already learnt it"
Go being "dumb" is its biggest upside. When you give programmers fancy tools to avoid problems, they will get themselves into subtle more dangerous problems.
All styles of programming work at the small scale
It depends on what you're writing. If it's a 'normal' backend? Sure, a 20 K LOC Go backend will likely be easier to get into than something equivalent in C++ or even Rust, since the 'fancy' tools of these languages lead to more complex interactions.
But at the same time, looking at e.g. Android etc (note that's made by Google, the company behind Go), then they actually use Rust, not Go. Because while these tools might make for some more complex interactions, they also allow you to assure some things that tend to be crucial in these environments, making it harder to write code that misuses components. That actually makes it easier to onboard devs to these projects.
@@9SMTM6i promise you the reason why Google uses rust or C++ for certain products is simply for performance and better low level access, not implementation restrictions
As mainly an Ops guy I agree. Developers also tend to try to use all those fancy tools all the time and screw up big time by implementing shit that should be handled elsewhere. It's a nightmare to troubleshoot.
KISS.
@@9SMTM6 Android is a bunch of C and C++ with a huge glob of Java on top, only quite recently there's been a bit of a push to start replacing some parts with Rust. Either way it's horrible all the way from top to bottom and nothing about those horrible languages (C++, Rust) can help the architectural mess of complexity that is Android. These languages are only being used for performance reasons. If they could get away with it, they'd have no reason not to written the entire thing in Java. More against your point, Google enforces the use of a very strict subset of C++ which basically bans most of the inherently complex language / library features outright, plus they have access to (arguably) the best engineers out there, and they still end up with a mess.
Bro. So on point. I've been saying it for years. The worst part of python is the package / dependency management. You know it's bad when even JS wins by a large margin.
Yep...totally in agreement.
As a Rust dev, when you say "it will be a lil bit slow" when you cross compile your hello world, it kinda makes me cry that you consider 1.8s "slow" compiling :')
Docker compiles in about 5 minutes on a regular dev pc. Quite crazy
He’s compiling hello world. Hello world in Rust compiles faster than Go. Try it lol
Go's best strength is how absolutely simple it is to learn, assuming you are generally familiar with programming.
With no exaggeration, you can go from knowing absolutely nothing about it to writing complete and useful applications within the same day, just consulting some docs/examples for the syntax along the way. The tooling around it is just as simple, and everything you needs comes included.
The Go standard library lacks FIFO queues, double-ended queues, priority queues, sorted maps and sets. I sorely miss them when I have to write Go.
Coming from python, I also miss things related to randomness. Pick a random element from an array, pick with weights, pick repeatedly, shuffle an array etc. All aren't too hard to implement yourself from the RNG in the standard library, but it's nice to have them built-in.
I only know 3 languages that have every data structures you mentioned in its STL, so it’s probably not a Go problems.
Channels act as first-in-first-out queues.
Don't you have external libraries for that?
@@StingSting844 Might as well write it in C at that point.
The Reader/Writer conventions in Go make it possible to write insanely testable code! I've written many pipelines which work on the file system, but are fully testable without touching the file system because the pipelines only work on io interfaces. It's incredibly useful! It's not as easy in TypeScript land for example, though some Web API stuff seems like it's gradually bringing it closer.
You can also implement these interfaces yourself, but when the standard library does it all for you and the entire ecosystem works off of that library, it's SO MUCH work taken off of your plate.
I learned C++ in university and my first job after graduating was C++. Then, one day we were told that we're switching to Go. I absolutely *love* Go. I have never liked C++ and came to detest it after a while.
Go is mid in many things, but when all these mid parts work together it is hard to beat.
I would never call Go mid, it is far above mid.
I did not call Go mid, I said Go is mid in many things. One example is in the type system, another is in the performance, the package system was also mid for a long time until modules happened.
But Go is designed in such a way that these subsystems, even if they're not perfect in any one thing, can fit together perfectly to create something that is hard to beat. In other words, the Go experience is a sum of all its parts.
@@melodyogonna Well I agree. =) My point was more that there are so many languages out there that do things far worse than go. So I would say it is probably above mid when compared across the board.
I need to get on playing with Go. I hear so many good things.
It’s just a programming language. The type system leaves a lot to be desired in practice.
@@ZiRo815 if err != nil all over the place, imperative, no sum types, no natural syntax for pattern matching. I don't see myself using it.
Go is fairly terse and that bothers some people. But I find it to be one it’s better qualities.
Go is like that ex you can't help but keep coming back to - practical, reliable, and just works everywhere! 😅 Love how you broke down the three key strengths, especially the standard library part. As a Lambda developer, those cold start numbers are seriously impressive. Your love-hate relationship with Go is so relatable 😄
You silly gopher, you love us.
Go is really something where you love it's simplicity and hate it when you see something missing that's in every other language. Like removing an element from a slice. You have to write those functions yourself. Still, I really fell for it. It replaced my #1 language (PHP) because of it's static typing and I am trying to stay as far away from TypeScript as possible.
For the Reader thing, other languages also do this, they just call it a Stream.
First six minute love affair with io.Reader is odd. Java has had InputStream and BufferedReader since 1995. Go’s standard lib is incredibly lacking. As another commenter said: no queues, sets, or heaps.
I was confused by this as well. This feels very obvious and commodity.
“We all saw the language balls flying around” literally the reason why I clicked the thumbnail looooool 💀
feels like the benefits you mentioned can be mapped to Zig (which Bun is built with)
What an honest man. What I don’t get is why people keep apologizing for using it!
Go is so good for scripting as well. Btw, the ability to profile binaries was not mentioned here, a bit too deep perhaps, but that it can further increase the speed by profiling a running binary is also great.
Well, I am mainly using my primary language for the backend, which is actually Go.
Go is our primary language. Mostly for data exchange, servers and processes, but also for GUI, frontend. We don't do anything in the cloud.
wait what? first time seeing someone go and not cloud
may i ask why ?
I really like V which is heavily inspired by Go, but it has some syntatic sugar that is nicer and it just compiles down to C. It's still beta software so it have a long way to mature still. but I really like the simplicity of the language.
I've gone through some of the tutorials for Go, but it just seems like a bit of an awdward language to write it. If I did it for work I would learn it a lot more.
@SST how to setup vim exactly that way like on video? :)
"There are only two kinds of languages: the ones people complain about and the ones nobody uses" (C) Bjarne Stroustrup
GoLang it's fine, until you realize that the slice function of a list is sliced by reference.
Also if you don't specify the go.version in go.mod, you will have weird behaviour and might use old golang code irrelevant of the go version that you are compiling and running your code. (hint: because it's explicitly implemented like that). And I completely not support such way of handling backward compatibility.
At least, if, for the newer versions it is crucial to set the go.version in go.mod, fail early before someone finds some bug on production because of that faulty implementation.
It's not Go that's ensuring portability, other languages can do this as well.
It's the standards independent of Go (mostly POSIX) that's ensuring portability.
DAX, in the post you mention “The sst dev CLI supports running your Go functions Live.” Does this implementation support breakpoints in go on V3? Great video, thanks, we continue to use Go on Lambdas and SST when we need performance optimizations
what is your primary lenguaje for backend?
Thank you for this! Cool video!
i think it's awesome you support Go now. Still I never faced a use case actually using it :( basically all my lambdas are i/o driven so node makes sense most of the time. When do you think does it make sense to use Go over Node? For cold-start related problems? I think those are problems for systems with no users, so what are actually good use cases? Would love to hear that
Why is Node better for IO-driven apps?
@@nessselbecause it is 😂. Can we get back to his question?
Go's concurrency model makes IO and networking so smooth, so to me, there at least even. I don't see what node does that's superior that you'd just discard any alternatives. But I'm guessing it's just your experience...
@@nesssel good answer. He may have gone a little extreme by saying Node is the best for I/O bound apps. But given that Node is very good with I/O bound apps, what then would be his motivation to rewrite his apps or use Go for newer ones?
If you ask me, reducing cold-starts plus faster execution might be a reason. Saves money, no matter how small. It might not seem significant but given that Go is easy to learn, might worth it.
As for me, I will stick to Rust for most personal usecases (for now), Golang for a team (most ppl don't like going deep 😃) and Node (TS) when I am forced to 😃.
I'm sure you know better, but this video kinda feels like you think Go is the only language that can be compiled and statically linked.
Dax I think you'll love V lang if you like these Go aspects!
Nice, I can finally switch one of my projects to sstv3 :D
This video made me learn Go
0:57 it's extreme good it's very large
Please make an equivalent video on Rust? I'm just curious what your thoughts are after years of using both Go and Rust.
Go would be my ideal language if it had (1) immutable by default variables (or val vs var like in Kotlin) (2) Result / Nullable types (3) a good convention/culture for variable names instead of the dumb single-letter variables.
Seriously... those single-letter variables get warnings from so many linters in so many languages, but somehow became the default in go. Who let this happen?
There are indeed some strange naming conventions for variables, arguments, etc. in the stdlib, which by extension has become the convention for the entire ecosystem. I am mainly a Zig dev, which is all about making everything explicit and verbose to convey intent, and it is jarring when I make a switch to Go and everything is using single-letter names and abbreviations for words that are already short. I can get used to it, I pretty much always just follow conventions for whatever language I am writing ("when in Rome"), but it never feels nice using "r" to describe a "Reader" etc, especially when its is part of a public API.
@@ForeverZer0Zig is so verbose it turns me off. Casting shouldn’t be that verbose. IMoO zigs anytype is terrible to find out what implements an interface.
@@metaltyphoon I find that if I am ever explicitly using anyopaque, anytype or doing some form of inspection on a runtime value, then it is because I am going against the language paradigms, and trying to shoehorn what works in another language into it. With the exception of designing the internals of my own "interface" (no actual such thing in ZIg, just a design pattern), those aren't really something that should be used, that is what comptime is for: you get type-safety.
You use comptime-functions that return types, which fulfill your interfaces, not test types at runtime.
All that said, I understand peoples' dislike of the syntax: I myself procrastinated learning in-depth for over a year because I thought the syntax was terrible. After powering through it anyway and doing a deep-dive, it begins to make sense, and it has its own purpose, allowing you to do some really elegant things that are near-impossible in any other compiled language.
Casting is overly verbose, no arguments there. It gets worse when the destination type cannot be inferred, and you have to start throwing in @as, @alignCast, and @ptrCast into a single cast. I understand is offers more precise control, but some shorthand cast built-ins would be very welcome.
Didn’t know Thierry Henry knew code 👀
Hi, didn't watch the video, but just stopped by for this comment because of the title. I don't know Go, but I do know Rust, and that's exactly how I feel about Rust!
Bro i just started writing a go worker because its just good
sst to support dsql when?
А, отсутствие занятости засчёт улучшения развития разработки вызывает дескать уныние,
А на го есть движки для разработки игр?)
I still dont know why dax doesnt have a OF channel.
Alright, alright, I will rewrite some stuff in golang
This is how I feel about PHP, except it sucks and go rules
Great video, really wanted to know you’re reasons for disliking Go
Go is too simple for me.
why can't I grow a beard like that?
So the reasons why you like Go are:
- it's better than POSIX compliant, it's Plan9 compliant (no mistery there, it was developed by Rob Pike)
- it creates binaries, almost like it was the only language that can do that (and no, those aren't standalone, pretty sure you still need libstd for it. Last time I checked, it doesn't use musl, so no)
- it's easy to deploy.. Not! It's just that like many other languages, it can be shipped to AWS Lambda. That ain't a strictly Go thing, dude
From a brief inventory... Not a solid foundation
Go binaries are statically linked by default, making it easy to deploy anywhere.
@@gavinh7845 I'll correct that for you: making them much more heavy than they should be
@@gavinh7845 they are statically linked on systems that allows it. FreeBSD and macOS don’t. Besides anything with DNS most likely will link w libc so yeah…
@@thelambdafunctioni guess it depends on your goals. The binaries are larger, for me, it's never been a problem due to the low cost of bandwidth and high speeds available nowadays. I'm not a super duper smart intelligent programmer though, but I'm self made in plugins and a few fun internet games and tools I wrote in Go, which required automation of provisioning servers, pushing my software to them, and running it. Lamda functions aren't the only way to write software. I just keep writing monoliths (or basic structures, like distributed queues with workers).
Go doesn't require something like libstd. which is why you can compile for any OS, ARCH from whatever machine you are using. if you need something like CGO that may be different story.
Goddamn man, your beard is 10/10
It brought you no joy, at all?
So why do you keep using it?
Thank you dax
DO MORE PLZ ❤
go is too simple to a fault in my opinion. there's just so much more boilerplate and it's painful. for simple scripts and things like that it's nice, but to build a real application is just pain.
Can we please agree to stop using this type of clickbaity titles: X is great I hate it? Please I'm begging you, I can't afford to rage break stuffs any more
Yeah, I definitely hate Go as well. If I can't have braces on their own line, I consider that an error in the brain of whoever designed that language. The designers excuses for why are completely bogus too, especially given that you can add a superfluous brace at these points and have it on its own line and it will still work as normal. I'm thinking of writing my own Go compiler just so I can have braces on their own line.
Please don't introduce ugly C bullsit to go. Just write C if you want to live your life that way.
@@morgengabe1 No, the ugliness is already there with uneven brace placement. They should line up.
Calling Robert Griesemer, Rob Pike, and Ken Thompson stupid is mind boggling
@@FirstYokai And yet not once did I call any of them stupid. But I suppose reading comprehension is a skill and you'll only learn by me pointing out your mistake. To make it 100% clear, because you need the help, I'm not saying I didn't call them stupid because I didn't refer to any of them by name, I'm saying I didn't call them stupid because I wasn't calling anyone stupid with my comment.
@@anon_y_mousse You said they have an error in their brain and that their excuses are bogus.
I still don't see myself taking up Go anytime soon.
They make a few... to me disturbing design choices. Primary being no type level handling for nullability, when this was already a solved problem when they designed Go, and when I can't see a good reason not to do that. Then we have their extremely weird enum replacement iota. Also they went for ages without any concept of generics, which has influenced their standard library design as well as popular packages.
I don't say that they don't have their strengths. It's a simple language, they have pretty good concurrency design, and it's fast to compile. But the design choices above make me afraid of what other choices might be hidden in details, let alone the fallout from these desidn choices themselves.
Just give me the exe bro
WAGMI :D
but theres basically no eco system i cant think of any use case where i would use go
Imagine complaining about something good. Humanity is cooked.
Go has a lot of advantages that I like.
The biggest disadvantage I see currently is the lack of community packages, JS ecosystem is just superior there.
Go is designed to discourage the use of third party packages. If it ain’t bringing substantial gains, don’t import it. YOU can do a better solution for YOUR specific problem.
@@AlexGarcia-ir7fl yes, but if your use case isn’t covered by the standard library then you are cooked
Cooked is a little strong considering you can still import packages.
@@AlexGarcia-ir7fl Every dead language/framework uses this excuse. Oh we don't have a lot of packages because we are all 120 IQ and are all solving brand new problems!
What packages are you missing?
just do Rust support
C3 is better
I can’t stop thinking about “are you happy with your indians” now that I’m watching this
LOL RUST ONE LOVE
Влад Тэн одобрил этот видео
poshel nahuy so svoim vladom ten
go is great, another great thing i love is next.js
LLRT support please