Thanks for talking about this talk. Rob is no longer a Go core team member (he's retired now), and explicitly mentions this a few times during the talk, but he sees it as one of his more successful children, and he loves where it's at now. The talk is 100% opinion based content from one of the inventors of the language. It wasn't vetted or approved by anyone from Google, and I don't think he'd conform to anything they would have pushed or suggested for this talk. It's remarkably candid. He also happens to be one of the people who have been around for so long, and invented so much stuff (UTF8 anyone?) that I regard his opinions as worth considering for longer than average. I had the privilege of being one of the MCs at this conference. I introduced this particular talk, and was running madly around the theater with a mic during Q&A. Rob is a lovely guy, and if you ever have the chance to talk to him he's a fountain of knowledge and stories.
when i worked in automotive, the project took almost 1 hour to compile from scratch, one Engineer took a couple of months to switch the build system from a collection of make files to cmake+ninja and the new compilation time from scratch was 20 min, we all rejoice.
We had a case where where we switched FROM CMake to Meson (+Ninja on Linux/VS2022 on Windows), where we went from ~5mins ninja generation to near instantaneous. Cut our total build time from 15 to 10 minutes on Linux.
I always felt like the Go gopher looked like a simple, well-meaning idiot implying that the Go language is meant to be a fun, simple tool that does what you tell it to do exactly because it can’t do anything else.
Yes! And I don't know how true this is but when it came out, "mascots" weren't a thing for programming languages. It was both endearing and exciting at the same time. The other effect that the mascot had IMO, was that it somehow set a friendlier tone within the community especially when communication on google groups at that time were often terse and impersonal. At least that's what it felt like for me.
FWIW, all those single-letter variables are conventions within the Go community. In Go code, 'c' stands for 'channel', 'w' is 'writer'. If you've read enough code in the standard library, which is like the go-to advise for looking at idiomatic go code for people new to go, and many popular Go libraries, you'll see this convention abound. I don't know what 'nn' is though. I had the same reaction he did when I first encountered them too.
On the one letter variable name thing, I work with a fork of nginx and the core modules are nightmarish to follow because of this. I dread debugging the upstream module a seeing a pointer called c and not sure if it is a pointer to the connection, cache node, cache module, config or what else. Then you jump into a function call and you have another pointer call c which is something else, and you better remember that when you go up the stack again that c no longer means what it meant before. It hurts me physically.
Funny thing is that I perfectly remember what the single letter variables are used for. HOWEVER when I have to share my code, the lions share of time is spent explaining what the single letter variables do and in the end I end up refactoring the names while explaining.
The one-letter thing is aka "Rob Code". He comes from a time when screens were monochrome and space was limited. You can find the same fun in Plan 9 and the Limbo language. And... well... that made it into Go, I suppose.
One of my professors recounted a story where he interned for an automotive company in detroit, and the mechanical engineers had this software to ensure a component could be manufactured and it took almost 17 hours to complete. He wrote a tool that did the same thing and it only took 6 minutes and the engineers were mad at him
14:48 - Python does exactly this. At least, as of Python 3. There is no integer overflow in Python. The integer just gets bigger. They smoothly scale the representation under the hood. Of course, in Python, nobody is expecting anything to be blazingly fast and so that works. But I think he's right, and I also think that could be made not ridiculously expensive. I'm going to think about making an integer type in C++ that can do this. Though, in C++ the performance degradation involved is going to concern many more people. It can probably still be made pretty efficient, and would be really helpful when dealing with data from untrusted sources.
In C++, they could use the type system to only impose it on some integer, like std::size_t. Generally, as Prime said, you don't want overflow for size computation but it is OK for others integer.
At the lowest level, Elixir and Go concurrency are very similar - both use light weight user space tasks managed by a scheduler per core. Both use preemptive multitasking to achieve high throughput when 1000s or 1000000s of processes are spawned. Differences are in the details: go bakes in preemptive interrupt checks into the compiled binary, Elixir runs on a VM where VM opcode handling does that. Go has a shared global heap, Elixir has a separate heap per process. Go has global GC that sometimes needs to stop the world, Elixir has per process GC that allows everything to keep running always.
BEAM does have a global heap for entities that escape the local GC and it can pause to clean them up. Go’s stop-the-world gc pauses are nearly entirely single-digit millisecond last time I checked. It still annoys me that it exists but it’s not a really legitimate criticism any more unless you need soft realtime or better.
Having divergent eyes is a sign of being a prey animal. It allows the creature to look in multiple directions to see danger coming and hopefully turn that early warning into an escape.
@@binaryum The gopher mascot. Prime said his eyes don't look intelligent. But I'm saying they look like an intelligence of a different kind--escape intelligence rather than targeting intelligence.
word, I use that library daily bro, thank you. Please implement an "IsClosed" boolean on the socket instance. Would help us all. RabbitMQ connections have IsClosed. It would be a huge benefit to the entire world and future generations to come.
any reasoning behind the single letter variable names? I can't think of any good reason to do it like shown - but I'd be interested in hearing from the gorilla devs on why.
@@pieterrossouw8596 It's a standard goism which the original maintainers kept. Pretty common from my understanding with C code too. The current maint prefer descriptive variables so this will change as the project ages.
Promises was around 2002-2006, it got in to jQuery, we got a lot of versions of Promises, but the one that win the Race was A+ the then/catch verstion. any object that got then and/or catch as methods is a promise.
How dare you expect self explaining variables, how else will that one goated programmer make sure that no one else but him can decipher his spaghetti code?
I think it's important to note that Erlang is a functional programming language, and async is significantly easier in those languages. Go is a multi-paradigm language, and it came with an async model in the language where it's possible to write code in mostly the same style as one would in C.
The fact that Go launched without generics baked in was a huge misstep. It is a language feature that is kind of de facto required for any statically typed modern language. It's cool that it's finally in the language now, even though its implementation is not pretty.
These days am liking Swift - they’re making an earnest effort to get it to be a multi-platform language (not just for the ghetto of MacOS and iOS), and the subset of the language, embedded Swift looks most interesting - have my Pi Pico in hand to give that a spin. But my main focus will be Swift as for Linux/BSD programming. Swift started out with more things - like generics - thought out up front. The enum of Swift is arguably its best feature - given the manner of programming it gives rise to. And I like that struct and class are very distinct. Anything based on class will always be dynamically allocated on the heap and lifetime tracked using ref counting. It is intended for an object-oriented programming approach. Whereas struct is a value type and a structure instance can be on the call stack. Protocols are analogous somewhat to, say, interface in Java. But the intersection of enum, generics, protocol, struct, class is where all the special sauce comes into play. With version 6, Swift is a language worth giving some attention to.
Though I agree with your 1-letter naming take in general, for struct methods it's feels very ok to name struct variable with just one letter, it even feels better than i for index when looping through array.
1:00 As a dev who's comping from the engineering math side of things who has seen a lot of fortran and c code that looks like it's coming from a physics or analysis math book, I disagree that single letter variables are always a bad thing - especially when each of them are confined to clear local scopes & you happen to have to deal with a lot of them at the same time. if you don't know: using single letter names in math, physics & engineering for local or bounded scoped variables, constants or expression is not just a -decades- centuries old way of writing things, it's also more readable when you get more complicated expression. But granted, the stuff that this go-programmer wrote isn't anywhere near that kind of complexity (nor are most things programmers write).
About naming receiver function variable, I heard a story from my friend that their team use "this" for every receiver function (former java team). It's definitely a cursed but also kinda make sense at the same time, waiting for "self" for former rust/python devs doe hahaha
21:20 The issue of the CC-by license of the Go mascot is that sharing it without attribution is copyright infringement. The CC0 license is ideal for something like that. Ferris, the unofficial Rust mascot is under CC0.
I love the feature of Go using "errors" versus a try catch method. It is simple and easier to use. Fairly new to Go but I love the Go philosophy and I love the Go standard library.
Go errors are worse than exceptions in everything except performance. Go errors are dynamically typed, thus it is entirely possible to have a dependency introduce a new kind of error, and your code will still compile, but crash or do something bad in runtime. The optional error chaining is laughable as well. To sum it up, the Golang way of error handling has all the problems of exceptions without any of the benefits.
@@youtubeenjoyer1743 Really ?? Don't tell me that. Just started learning Go and at the moment creating my first cli. I did a couple of test runs with the error method and it seemed to do the job. Then again I never used Go for anything complicated at the beginning stages. Haven't tried it yet but are you allowed to use try catch in Go?
I'm currently learning Go as well and the error handling feels kinda weird to me. While it doesn't break control flow like Exceptions, which great, it still feels like a step down from using Result or Option in Rust.
@@DevlogBillDon’t listen to that comment lmfao. Golang’s errors are primitive but still top tier when compared to exceptions. Function definitions allow you to tell when a function can error which you don’t get in exceptions. Values are returned along side errors so you don’t have scope issues like you do with exceptions. With errors being returned directly from a function you have fine grain error handling that let’s you place error handling logic directly next the function that errored which is also not a thing with exceptions. And just because error is an interface, doesn’t make it dynamically typed, it’s still strongly typed. If a dependency introduces a new error type, you still have an error interface. If that dependency has a custom error type you can match it with errors.Is and errors.As, which is completely type safe. Overall that person doesn’t know what they’re talking about and is most likely a JavaScript Bill.
@@ArgoIo I am on day 3 of learning Go and I found using the error method easy to use. The only thing I noticed was you can find yourself with nested errors if you aren't careful. I decided on GO because it feels so much like C and I like C. Also, I know the basics of React which is the useState and useEffect and how to create props. So I am learning more about React and at the moment only learning about how to create a restful api with GO. Later I will learn more about Go after I get a decent understanding of creating a crud app with React and Go.
What golang has definatelly got right is the errors as values concept. I swear, when I applied it to my JS projects, I got suspiciously few unhandled or wrongly handled errors. I wonder how 🤔
I also want to try that, my hesitation is that now I have to handle both throwing from external lib and my error-as-value from my own function which feel kinda confusing, maybe I have to do some wrapping ig
@@OnFireByte Yup, that is the tradeoff, something can always throw and you must forever be paranoid about it; to feel safe you will have to implement one to one wrappers for every entry point into any external module. I had similar pain trying to introduce an option type to my typescript projects, if you're truly committed to not allowing null/undefined sneaking into your code you have to wrap every single thing and have mappers for anything that returns an object to 'optionify' whatever fields inside that can be null or undefined. Better hope they've documented all that. It becomes tedious at best and just absolutely miserable at worst but in a smaller projects it can be manageable.
When things take 45 min to build, the cost of fixing that problem might be 4.5 million, which is why long build times are a reality for many devs working on legacy monolithic applications.
I have done golang at my job for about 5 years, and the convention of one letter variables is horrible. It's a compiled language. Give it some actual names. The only place I do it is the receiver variable because it's the same across every function.
one letter variables are a long standing tradition in C, any C developer knows it. And is amazing, it is the way of doing it. Don't tell me you are one of those that likes sentences as variable names.
I first learned about Go in 2014. I went to a conference and another dev told me about it. Went home and tried it and I thought it was awful. I was a guy who thought he was a genius and loved abstraction. And I thought Go was trrrible because like “where was inheritance”. In 2016 I had a simple project and didn’t want to use Java and didn’t wan to use Python because I hated shipping an interpreter. So I went with Go only because it compiled to binary. And I fell in love. Been using go professionally for 8 years and have no looked back It too me awhile to get away from my Java brainwashing. But I’m glad I think about writing software differently now
Old C++ dev, then C#, then Java (ick), then management, now learning Go for a side project. I like it so far, I hope i never have to touch Java again. I just want something that gets the job done without a bunch of overcomplication.
I definitely remember a dislike of multi-threading, especially within game development. It basically boiled down to "skill issue" and "we don't REAALLLLY NEEEEDD ITTTTT"
It takes 30-40 minutes to build our C++ from scratch and it is easily the worst part of the language so I will write most of my feature without compiling to avoid this.
Single letter variables as a convention is weird to me given that 90% of the go team came from the Plan 9 group at bell labs, and the source for Plan 9 is incredibly readable even for someone like me who know very little in terms of its library and dialect of C
yeah man, i really hate the single variable convention in GO, besides that golang is the perfect balance between performance and simplicity, i love that
Go was "against the grain" at the time because we had single core processors, and they weren't the best, and so the whole "threads are bad" thing that lasted a few years was right before dual core cpus dropped, and we started writing code to take advantage of multiple cores. Then IPC got better, memory got faster, and threads weren't such a bad thing anymore. Plus languages like Go helped us realize the power of thread pools underneath, and scheduling chunks of code on those threads to achieve higher concurrency.
You're not wrong about the gopher. The first time I saw it I thought it was advertising a language for newbies similar to the way high schools used to use Pascal, not a language for experienced developers.
1:45 I agree with Pike and Kernighan: "Use descriptive names for globals, short names for locals" (The practice of programming, 1999). If the entire function is 2-3 lines long, I can tolerate one character parameters, but a full single word is usually better. There's exceptions. E.g. "n" is often used very consistently in some standard functions but IMO most programmers wouldn't get the convention if you just use it as a variable; it's not that hard to use "pLengh" in "WriteString" function (2:14). And "i" is standard: no one should challenge it's use if there's no inner similar loop.
At university, I used a C/C++ language extension for concurrency and parallelism called Cilk+ made/maintained by Intel which was exactly like Go's routines but using the keywords spawn or cilk_spawn instead and with many other features. It came well before Go. Go's approach is not novel and didn't revolutionatise anything. I'm not sure if it spawnned an OS thread or if it had a lightweight thread run-time like go, but that is just an optimization.
Unit testing can be such a pain because anything you want to mock must already be built with interfaces and dependency injection in mind. Golang markets itself as a simple language to write good code easily, but if you actually write "simple" code, it's not testable.👎
by the way... I totally remember the "threads are bad and scary" times... It sortof depends on what ecosystem you are in on how averse or not you are to them... To be fair... I find people either go way too far to one extreme or the other... (ie people are either, "concurrency is easy, what's the big deal" or they are "concurrency is the 9th ring of hell and will eat your immortal soul")... To be fair I only trust the programmers who are in the 9th ring of hell camp but are willing to do it anyway... I trust the "concurrency is easy" camp the least... they only think that because they don't understand it yet. Fun fact... fearless concurrency is what got me interested in rust, (and I still regard as one of it's many killer features).
13:41 On desktop computing, even back in the early 2000s, arbitrary precision integers should be the default type for what you intuit as “it’s an integer number”. Using fixed-size integer types should be reserved to the following cases: 1. It’s part of an algorithm (e.g. hashing) or standard (e.g. IPv4 or IPv6 addresses are exactly 32 and 128 bit). 2. It’s an optimization you implemented (of course, after profiled profiling revealed its value). For a customer’s age, use a BigInt, unless you profiled and it curbs the app’s performance.
The advantage of BigInt is that all arithmetic integer operations are mathematically valid (within the bounds of the machine), with one exception only that is division by zero. For that, you’d need NaN values in your BigInt type, which depending on your use-case might be fantastic or annoying. Zig is probably right in making overflow on fixed-size integers undefined. In 99% of cases, when something overflows, it’s not the result you wanted anyways. And if overflow is on my mind, in C++, I’ll put a comment right there, which in Zig, I don’t need to because Zig as a dedicated operator screaming that this arithmetic operation is mod 2³² in your face.
So, which do I learn first? Golang or Rust? Rust seemed to be C with easier memory management (because I recognize the & which denotes reference from the C days).
Go development tools enforce the single letter shit for functions attached to structs. They also use significant whitespace for efficient compilation or something. Kind of weird, but you get used to it.
Their concurrency model is a "wrong". What GoLang has is way better than your average language in that space but compared to languages that focus on concurrency it was sad to see them recreate something that effectively ignored 20+ years of research in the space (see actor models and Erlang.) While it does move the needle forward in some respects it also holds back the industry because better ways of solving the problem are sidelined. This is why Docker was bad for the industry. It was built by people who were ignorant of the space and built a tool seriously lacking as a result. Its popularity sucked the air out of better alternatives. Less bad != good.
C# has too many of the same problems as Java because of the way it was designed to be familiar to it, this is the biggest issue I have with it. Microsoft is adding more functional features - but until I have options/results, first class functions, and namespaces that dump everything that’s public into wherever you use them - I don’t think the language is different enough from Java. Go removing the heavy boilerplate that OOP languages were using is a great strength that it has and encouraged other languages to follow.
For the smart ones who read between the lines: "If it didn't take 45 mins to build the binary I was working on at the time, Go wouldn't have happened."
I'm a pretty big fan of golang. Error handling I think could be a bit better. imo errors should come with a stack trace by default, and that 'try' syntax from zig looks so good
Agree. I don't think the that error handling is "bad", I really like error values, but I do wish that there was some language-level "try" mechanism as you suggested to make it less verbose. Proper enums would also be appreciated.
I love how Flip litereally never does anything Prime asks it's pretty funny.
Always the opposite
from now on: FLIP, dont do "this/this/this and this"
FLIP: Does it!
I don't think flip exists
Why do you think they're called flip
I think he keeps it because it’s just funny lol
Thanks for talking about this talk. Rob is no longer a Go core team member (he's retired now), and explicitly mentions this a few times during the talk, but he sees it as one of his more successful children, and he loves where it's at now. The talk is 100% opinion based content from one of the inventors of the language. It wasn't vetted or approved by anyone from Google, and I don't think he'd conform to anything they would have pushed or suggested for this talk. It's remarkably candid. He also happens to be one of the people who have been around for so long, and invented so much stuff (UTF8 anyone?) that I regard his opinions as worth considering for longer than average.
I had the privilege of being one of the MCs at this conference. I introduced this particular talk, and was running madly around the theater with a mic during Q&A. Rob is a lovely guy, and if you ever have the chance to talk to him he's a fountain of knowledge and stories.
when i worked in automotive, the project took almost 1 hour to compile from scratch, one Engineer took a couple of months to switch the build system from a collection of make files to cmake+ninja and the new compilation time from scratch was 20 min, we all rejoice.
cmake is bad, but the alternative is autotools which is brain damage
@@monad_tcp meson is the way
@@monad_tcp SO TRUEE
We had a case where where we switched FROM CMake to Meson (+Ninja on Linux/VS2022 on Windows), where we went from ~5mins ninja generation to near instantaneous. Cut our total build time from 15 to 10 minutes on Linux.
So you're saying you all lost 40 min of break time?
I really hoped there would be more about what they did wrong.
Or anything at all.
I like the joke that they wrote Go while waiting for their C to compile.
C++ more specifically, all that template sugar is not free. ;)
In what world is C compilation slow?
As to variable naming, the programming language of The Ancestors - FORTRAN - taught us once and forever how to properly name variables.
I always felt like the Go gopher looked like a simple, well-meaning idiot implying that the Go language is meant to be a fun, simple tool that does what you tell it to do exactly because it can’t do anything else.
I think it was widely known that Go is supposed to be a simple language, but the way you broke it down and reached to the conclusion is hilarious XD
Yes! And I don't know how true this is but when it came out, "mascots" weren't a thing for programming languages. It was both endearing and exciting at the same time. The other effect that the mascot had IMO, was that it somehow set a friendlier tone within the community especially when communication on google groups at that time were often terse and impersonal. At least that's what it felt like for me.
Simple enough to be done by a stupid critter.. opposite of intelligent
FWIW, all those single-letter variables are conventions within the Go community. In Go code, 'c' stands for 'channel', 'w' is 'writer'. If you've read enough code in the standard library, which is like the go-to advise for looking at idiomatic go code for people new to go, and many popular Go libraries, you'll see this convention abound. I don't know what 'nn' is though.
I had the same reaction he did when I first encountered them too.
c stands for Context sometimes
On the one letter variable name thing, I work with a fork of nginx and the core modules are nightmarish to follow because of this. I dread debugging the upstream module a seeing a pointer called c and not sure if it is a pointer to the connection, cache node, cache module, config or what else. Then you jump into a function call and you have another pointer call c which is something else, and you better remember that when you go up the stack again that c no longer means what it meant before. It hurts me physically.
Those single letter variables remind me of when I was first writing code.
"I'll surely, remember what this is for"
I hate it sooo much. My mental model doesn't work without decently named variables
Classic compression strategy for people who don’t understand what happens when you compile. Less letters = lower memory usage duuuh
Had this today with makefiles at work. Wanted to chuck my computer trying to dissect it.
It's so hard while doing code reviews
Funny thing is that I perfectly remember what the single letter variables are used for. HOWEVER when I have to share my code, the lions share of time is spent explaining what the single letter variables do and in the end I end up refactoring the names while explaining.
The one-letter thing is aka "Rob Code". He comes from a time when screens were monochrome and space was limited. You can find the same fun in Plan 9 and the Limbo language.
And... well... that made it into Go, I suppose.
From now on, when I need the length of any array-like object, I'll just call it nn. What a good variable name!
The take on Go developer and one letter variables so so true just why 😂
Giving credit to the mascot is crazy; saying it has an intelligent demeanor just sent me.
One of my professors recounted a story where he interned for an automotive company in detroit, and the mechanical engineers had this software to ensure a component could be manufactured and it took almost 17 hours to complete. He wrote a tool that did the same thing and it only took 6 minutes and the engineers were mad at him
"You done messed up Balake!" we're never calling anyone Blake ever again 😂
14:48 - Python does exactly this. At least, as of Python 3. There is no integer overflow in Python. The integer just gets bigger. They smoothly scale the representation under the hood. Of course, in Python, nobody is expecting anything to be blazingly fast and so that works. But I think he's right, and I also think that could be made not ridiculously expensive.
I'm going to think about making an integer type in C++ that can do this. Though, in C++ the performance degradation involved is going to concern many more people. It can probably still be made pretty efficient, and would be really helpful when dealing with data from untrusted sources.
In C++, they could use the type system to only impose it on some integer, like std::size_t.
Generally, as Prime said, you don't want overflow for size computation but it is OK for others integer.
At the lowest level, Elixir and Go concurrency are very similar - both use light weight user space tasks managed by a scheduler per core. Both use preemptive multitasking to achieve high throughput when 1000s or 1000000s of processes are spawned.
Differences are in the details: go bakes in preemptive interrupt checks into the compiled binary, Elixir runs on a VM where VM opcode handling does that. Go has a shared global heap, Elixir has a separate heap per process. Go has global GC that sometimes needs to stop the world, Elixir has per process GC that allows everything to keep running always.
gleamlang
BEAM is the best piece of software to ever exist; I will die on this hill. Go is pretty cool though.
Both are based on CSP (Tony Hoare, look up the paper.)
BEAM does have a global heap for entities that escape the local GC and it can pause to clean them up. Go’s stop-the-world gc pauses are nearly entirely single-digit millisecond last time I checked. It still annoys me that it exists but it’s not a really legitimate criticism any more unless you need soft realtime or better.
@@binary132 I mean, sure, but that heap has to be a small fraction the size of all the heaps in each erlang "process"
Having divergent eyes is a sign of being a prey animal. It allows the creature to look in multiple directions to see danger coming and hopefully turn that early warning into an escape.
what are you talking about bro
@@binaryum
The gopher mascot. Prime said his eyes don't look intelligent. But I'm saying they look like an intelligence of a different kind--escape intelligence rather than targeting intelligence.
As one of the maintainers of Gorilla Websockets, I feel your pain.
word, I use that library daily bro, thank you. Please implement an "IsClosed" boolean on the socket instance. Would help us all. RabbitMQ connections have IsClosed. It would be a huge benefit to the entire world and future generations to come.
any reasoning behind the single letter variable names? I can't think of any good reason to do it like shown - but I'd be interested in hearing from the gorilla devs on why.
@@pieterrossouw8596 It's a standard goism which the original maintainers kept. Pretty common from my understanding with C code too. The current maint prefer descriptive variables so this will change as the project ages.
Promises was around 2002-2006, it got in to jQuery, we got a lot of versions of Promises, but the one that win the Race was A+ the then/catch verstion.
any object that got then and/or catch as methods is a promise.
Booo only real language is MS PowerPoint
JDSL >>> MS PowerPoint
Flip did not take Flip out
How dare you expect self explaining variables, how else will that one goated programmer make sure that no one else but him can decipher his spaghetti code?
Definitely written by Tom!
true programmers use only APL
Go variables were fine imo. The context around them was enough.
@@digital_hoboz no
@@davidspagnolo4870 he literally read the code and understood it. It means it was fine.
Is there a Part 2 where he talks about the things Golang got wrong?
1:58 I'm fine with a writer named w. But I draw the line at `nn := len(p)`, that is just horrifying.
22:50 - I kind of agree that threads are not really the best model for concurrency. They're pretty hard to reason about.
Prime: "Go has the greatest async model I have ever seen."
Erlang: "Am I a joke to you?"
Erlang is better than Go. Checkout Gleamlang.
As he mentioned earlier, he hasn't used Erlang/Elixir much so Golang may indeed be the best async model he has seen
I think it's important to note that Erlang is a functional programming language, and async is significantly easier in those languages. Go is a multi-paradigm language, and it came with an async model in the language where it's possible to write code in mostly the same style as one would in C.
The fact that Go launched without generics baked in was a huge misstep. It is a language feature that is kind of de facto required for any statically typed modern language. It's cool that it's finally in the language now, even though its implementation is not pretty.
Same mistake in Java, same outcome. But by 2012, no excuse.
These days am liking Swift - they’re making an earnest effort to get it to be a multi-platform language (not just for the ghetto of MacOS and iOS), and the subset of the language, embedded Swift looks most interesting - have my Pi Pico in hand to give that a spin. But my main focus will be Swift as for Linux/BSD programming.
Swift started out with more things - like generics - thought out up front. The enum of Swift is arguably its best feature - given the manner of programming it gives rise to.
And I like that struct and class are very distinct. Anything based on class will always be dynamically allocated on the heap and lifetime tracked using ref counting. It is intended for an object-oriented programming approach. Whereas struct is a value type and a structure instance can be on the call stack.
Protocols are analogous somewhat to, say, interface in Java. But the intersection of enum, generics, protocol, struct, class is where all the special sauce comes into play.
With version 6, Swift is a language worth giving some attention to.
Though I agree with your 1-letter naming take in general, for struct methods it's feels very ok to name struct variable with just one letter, it even feels better than i for index when looping through array.
1:00 As a dev who's comping from the engineering math side of things who has seen a lot of fortran and c code that looks like it's coming from a physics or analysis math book, I disagree that single letter variables are always a bad thing - especially when each of them are confined to clear local scopes & you happen to have to deal with a lot of them at the same time.
if you don't know: using single letter names in math, physics & engineering for local or bounded scoped variables, constants or expression is not just a -decades- centuries old way of writing things, it's also more readable when you get more complicated expression. But granted, the stuff that this go-programmer wrote isn't anywhere near that kind of complexity (nor are most things programmers write).
2:10 they're minifying their Go code for faster shipping! :D
if only Go had learned the lessons that language developers already knew 30 years ago
About naming receiver function variable, I heard a story from my friend that their team use "this" for every receiver function (former java team). It's definitely a cursed but also kinda make sense at the same time, waiting for "self" for former rust/python devs doe hahaha
It honestly makes sense. That's exactly what it is.
i love how prime's hair is also see through now xD
Support for arbitrary-precision math doesn't mean that you can't enforce a specified precision, by the way.
Single letter names in a limited scope makes sense.
21:20 The issue of the CC-by license of the Go mascot is that sharing it without attribution is copyright infringement. The CC0 license is ideal for something like that. Ferris, the unofficial Rust mascot is under CC0.
This guy’s entertaining and educational. well earned sub.
I love the feature of Go using "errors" versus a try catch method. It is simple and easier to use. Fairly new to Go but I love the Go philosophy and I love the Go standard library.
Go errors are worse than exceptions in everything except performance. Go errors are dynamically typed, thus it is entirely possible to have a dependency introduce a new kind of error, and your code will still compile, but crash or do something bad in runtime. The optional error chaining is laughable as well.
To sum it up, the Golang way of error handling has all the problems of exceptions without any of the benefits.
@@youtubeenjoyer1743 Really ?? Don't tell me that. Just started learning Go and at the moment creating my first cli. I did a couple of test runs with the error method and it seemed to do the job. Then again I never used Go for anything complicated at the beginning stages. Haven't tried it yet but are you allowed to use try catch in Go?
I'm currently learning Go as well and the error handling feels kinda weird to me. While it doesn't break control flow like Exceptions, which great, it still feels like a step down from using Result or Option in Rust.
@@DevlogBillDon’t listen to that comment lmfao. Golang’s errors are primitive but still top tier when compared to exceptions. Function definitions allow you to tell when a function can error which you don’t get in exceptions. Values are returned along side errors so you don’t have scope issues like you do with exceptions. With errors being returned directly from a function you have fine grain error handling that let’s you place error handling logic directly next the function that errored which is also not a thing with exceptions. And just because error is an interface, doesn’t make it dynamically typed, it’s still strongly typed. If a dependency introduces a new error type, you still have an error interface. If that dependency has a custom error type you can match it with errors.Is and errors.As, which is completely type safe. Overall that person doesn’t know what they’re talking about and is most likely a JavaScript Bill.
@@ArgoIo I am on day 3 of learning Go and I found using the error method easy to use. The only thing I noticed was you can find yourself with nested errors if you aren't careful. I decided on GO because it feels so much like C and I like C. Also, I know the basics of React which is the useState and useEffect and how to create props. So I am learning more about React and at the moment only learning about how to create a restful api with GO. Later I will learn more about Go after I get a decent understanding of creating a crud app with React and Go.
Love his transparent hair style
What golang has definatelly got right is the errors as values concept.
I swear, when I applied it to my JS projects, I got suspiciously few unhandled or wrongly handled errors.
I wonder how 🤔
I also want to try that, my hesitation is that now I have to handle both throwing from external lib and my error-as-value from my own function which feel kinda confusing, maybe I have to do some wrapping ig
@@OnFireByte Yup, that is the tradeoff, something can always throw and you must forever be paranoid about it; to feel safe you will have to implement one to one wrappers for every entry point into any external module. I had similar pain trying to introduce an option type to my typescript projects, if you're truly committed to not allowing null/undefined sneaking into your code you have to wrap every single thing and have mappers for anything that returns an object to 'optionify' whatever fields inside that can be null or undefined. Better hope they've documented all that. It becomes tedious at best and just absolutely miserable at worst but in a smaller projects it can be manageable.
Because JS isn’t structured for errors as values.
USE A REAL LANGUAGE.
When things take 45 min to build, the cost of fixing that problem might be 4.5 million, which is why long build times are a reality for many devs working on legacy monolithic applications.
I have done golang at my job for about 5 years, and the convention of one letter variables is horrible. It's a compiled language. Give it some actual names. The only place I do it is the receiver variable because it's the same across every function.
L take on the mascot. He’s just like “meeeeh let’s just get it done meeeeeh”
None of this explains why they had to make the syntax so fugly in Go.
I actually love one letter vars for local variables. Naming often confabulates whereas you can just lookup a bit. It's honest.
6:05 absolutely 100% agree. Best creations come out of inconveniences and annoyances
6:36 cheese lovers be like
I came to Go for the concurrency and stayed for the Gopher
I abandoned Go because of the packaging system in the beginning.
the lsp being to a similar level to copilot probably means most of your characters are boilerplate.
one letter variables are a long standing tradition in C, any C developer knows it. And is amazing, it is the way of doing it. Don't tell me you are one of those that likes sentences as variable names.
You don't need to know who drew Ferris because the artist released it as public domain. So the artist is irrelevant by her choice. ;)
The rust foundation is the biggest barrier to my own desire to go full send.
I agree with that. The variables with one letter are more difficult to read for the developer. Not following the rule of clarity from Unix Philosophy.
I first learned about Go in 2014. I went to a conference and another dev told me about it. Went home and tried it and I thought it was awful. I was a guy who thought he was a genius and loved abstraction. And I thought Go was trrrible because like “where was inheritance”.
In 2016 I had a simple project and didn’t want to use Java and didn’t wan to use Python because I hated shipping an interpreter. So I went with Go only because it compiled to binary. And I fell in love. Been using go professionally for 8 years and have no looked back
It too me awhile to get away from my Java brainwashing. But I’m glad I think about writing software differently now
Old C++ dev, then C#, then Java (ick), then management, now learning Go for a side project. I like it so far, I hope i never have to touch Java again.
I just want something that gets the job done without a bunch of overcomplication.
I definitely remember a dislike of multi-threading, especially within game development. It basically boiled down to "skill issue" and "we don't REAALLLLY NEEEEDD ITTTTT"
100% agree with you about the one letter variables
It takes 30-40 minutes to build our C++ from scratch and it is easily the worst part of the language so I will write most of my feature without compiling to avoid this.
Single letter variables as a convention is weird to me given that 90% of the go team came from the Plan 9 group at bell labs, and the source for Plan 9 is incredibly readable even for someone like me who know very little in terms of its library and dialect of C
yeah man, i really hate the single variable convention in GO, besides that golang is the perfect balance between performance and simplicity, i love that
Go was "against the grain" at the time because we had single core processors, and they weren't the best, and so the whole "threads are bad" thing that lasted a few years was right before dual core cpus dropped, and we started writing code to take advantage of multiple cores. Then IPC got better, memory got faster, and threads weren't such a bad thing anymore. Plus languages like Go helped us realize the power of thread pools underneath, and scheduling chunks of code on those threads to achieve higher concurrency.
You're not wrong about the gopher. The first time I saw it I thought it was advertising a language for newbies similar to the way high schools used to use Pascal, not a language for experienced developers.
So even if they got anything wrong, they wouldn't tell us.
1:45 I agree with Pike and Kernighan: "Use descriptive names for globals, short names for locals" (The practice of programming, 1999). If the entire function is 2-3 lines long, I can tolerate one character parameters, but a full single word is usually better. There's exceptions. E.g. "n" is often used very consistently in some standard functions but IMO most programmers wouldn't get the convention if you just use it as a variable; it's not that hard to use "pLengh" in "WriteString" function (2:14). And "i" is standard: no one should challenge it's use if there's no inner similar loop.
Ngl I love Gos mascot. Doesn’t matter how spesh it looks it’s still quite endearing
Automatically handling integer overflow - Elixir mentioned
"I don't want a mascot"
- 🦀
At university, I used a C/C++ language extension for concurrency and parallelism called Cilk+ made/maintained by Intel which was exactly like Go's routines but using the keywords spawn or cilk_spawn instead and with many other features. It came well before Go. Go's approach is not novel and didn't revolutionatise anything. I'm not sure if it spawnned an OS thread or if it had a lightweight thread run-time like go, but that is just an optimization.
People that write one letter variables thinking they are saving time are too stupid to be writing code professionally.
Unit testing can be such a pain because anything you want to mock must already be built with interfaces and dependency injection in mind. Golang markets itself as a simple language to write good code easily, but if you actually write "simple" code, it's not testable.👎
As an Elixir fanboy and practitioner, and a former Golang engineer… Golang’s concurrency is alright! ;)
by the way... I totally remember the "threads are bad and scary" times... It sortof depends on what ecosystem you are in on how averse or not you are to them... To be fair... I find people either go way too far to one extreme or the other... (ie people are either, "concurrency is easy, what's the big deal" or they are "concurrency is the 9th ring of hell and will eat your immortal soul")... To be fair I only trust the programmers who are in the 9th ring of hell camp but are willing to do it anyway... I trust the "concurrency is easy" camp the least... they only think that because they don't understand it yet.
Fun fact... fearless concurrency is what got me interested in rust, (and I still regard as one of it's many killer features).
13:41 On desktop computing, even back in the early 2000s, arbitrary precision integers should be the default type for what you intuit as “it’s an integer number”. Using fixed-size integer types should be reserved to the following cases:
1. It’s part of an algorithm (e.g. hashing) or standard (e.g. IPv4 or IPv6 addresses are exactly 32 and 128 bit).
2. It’s an optimization you implemented (of course, after profiled profiling revealed its value).
For a customer’s age, use a BigInt, unless you profiled and it curbs the app’s performance.
The advantage of BigInt is that all arithmetic integer operations are mathematically valid (within the bounds of the machine), with one exception only that is division by zero. For that, you’d need NaN values in your BigInt type, which depending on your use-case might be fantastic or annoying.
Zig is probably right in making overflow on fixed-size integers undefined. In 99% of cases, when something overflows, it’s not the result you wanted anyways. And if overflow is on my mind, in C++, I’ll put a comment right there, which in Zig, I don’t need to because Zig as a dedicated operator screaming that this arithmetic operation is mod 2³² in your face.
before I was told it was a gopher, I was describing it as " the language with the beaver on crack"
Go being 14 years old is crazy
~18:00 What's popular is rarely true, what's true is rarely popular!
I feel like good PR is underestimated in software and for that reason I am happy the gopher was included
The only thing I find myself wishing it had is enums
With typeset interfaces they are getting close, unfortunately they can only be used as generic constraints
So, which do I learn first? Golang or Rust? Rust seemed to be C with easier memory management (because I recognize the & which denotes reference from the C days).
Go development tools enforce the single letter shit for functions attached to structs. They also use significant whitespace for efficient compilation or something. Kind of weird, but you get used to it.
It's wild, I was also wondering why the 1-2 letter variable names were so common in Go code... Makes no sense :|
allTheGoodVariableNamesAreTaken
28:58 need to tweet that as well. "To successfully build Java you need a degree in maven"
I prefer short variables so much, and keep the scope of the variables small
i think im falling in love with htmx
Their concurrency model is a "wrong". What GoLang has is way better than your average language in that space but compared to languages that focus on concurrency it was sad to see them recreate something that effectively ignored 20+ years of research in the space (see actor models and Erlang.) While it does move the needle forward in some respects it also holds back the industry because better ways of solving the problem are sidelined. This is why Docker was bad for the industry. It was built by people who were ignorant of the space and built a tool seriously lacking as a result. Its popularity sucked the air out of better alternatives.
Less bad != good.
I didn't even know 'Go' had a mascot.
Back in the old days in Cuba they would call Primo “lector de tabaqueria”😂
Can someone explain this to a senior C# dev? I don't see anything concrete mentioned in here
The stunning lack of features I can rationalize; the 1 letter variable was the death knell.
Mascot is a turnoff😂
C# has too many of the same problems as Java because of the way it was designed to be familiar to it, this is the biggest issue I have with it. Microsoft is adding more functional features - but until I have options/results, first class functions, and namespaces that dump everything that’s public into wherever you use them - I don’t think the language is different enough from Java.
Go removing the heavy boilerplate that OOP languages were using is a great strength that it has and encouraged other languages to follow.
w is basically always a writer of some kind One letter variables are fine in a five line scope
For the smart ones who read between the lines: "If it didn't take 45 mins to build the binary I was working on at the time, Go wouldn't have happened."
13:48 Could this idea be used to solve the y2k bug?
I think there is good wisdom in not telling Ken Fucking Thompson the best way to write a compiler.
wait was not 2024 supposed to be rust, you are playing on both sides ?
I'm a pretty big fan of golang. Error handling I think could be a bit better. imo errors should come with a stack trace by default, and that 'try' syntax from zig looks so good
Agree. I don't think the that error handling is "bad", I really like error values, but I do wish that there was some language-level "try" mechanism as you suggested to make it less verbose. Proper enums would also be appreciated.