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.
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.
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.
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.
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).
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.
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.
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?
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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).
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.
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.
10 minute build? The typescript project I'm currently working on takes 15-20 minutes to build the first time and my computer locks up while its building. Its so painful because its not even doing fancy optimizations or anything
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.👎
5:06 Elixir is better because it supports distributed processing and actor model out of the box. In go you would have to solve this problem yourself. I am sure there are libraries but still it is much better when language itself offers you the solution.
I fail to see how function coloring (async) is a problem, when 99% of what you're doing in Node is IO-bound? Like if you have a lot of CPU-bound operations, you shouldn't use Node
The vast majority of sites with heavy traffic use Node in some capacity, so the industry strongly disagrees. Are there advantages to using other languages in certain situations? Most definitely. You don't have to convince me that other languages can scale or perform better. But I almost guarantee that any other language will have a slower and/or less flexible JSON parser as well as less battle-tested tooling.
Also what’s with go and swift putting the case keyword for switch statements and expressions on the same indentations as the enclosing scope. It harms legibility, especially in nested switch expressions.
I can only think of one language where that isn’t the accepted style. That’s how switch has always worked. Because switch is the only keyword that does this it INCREASES readability.
@@ConernicusRex c# and Java invent before case in switch statements and the before the lines within switch expressions just like how they work in Kotlin’s when expressions
@@Bliss467 Yes and the syntax in proper Java or C# is that each case is on the same indentation as the opening of the switch itself. If you do it with cases indented you've been going against convention since you learned to switch.
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.
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.
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).
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.
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
Interesting, I'm learning Go as well and dislike the one letter variables a lot. I thought maybe I'm just dumb, or it's because new to real programming (I'm devops btw), it'll take me time to get used to it. Just makes things hard to read like have to keep scrolling up and seeing wtf was w again? I'm a fan of more descriptive variable names.
I don't like that production code ends up with so much autogenerated code. The fast compiler provides no benefit if that time is merely transferred to code generation.
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.
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.
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.
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.
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"
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.
That's what you get for advocating for abbr vars in a recent video. Now you get single letter variables. I'm not saying write "index", everybody knows what "i" is. But don't write "srv" either - is it "service" or "server" or "some random variable"?
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.
If you use a Promise/async-await in a function, you have to declare it as async/return a Promise aswell. In go you can convert it to blocking/sync function with ease. func DoSomething(arg int) int { res_c := make(chan int) go OtherStuff(res_c, arg) res
You would probably get better feel for what has been said if you have watched the talk instead reading article about the talk. Article blows out of the proportion mascot thing, that was basically just warm up in the talk
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
I would prefer go not to have Options/Optional/whatever, but to have mandatory not-nil pointers (aka references). So that I could pass pointer, never check it for nil myself and never fuck it up in runtime. Kinda a Kotlin-like behaviour.
![[UPDATE] Mojo Is Faster Than Rust - Mojo Explains More](/img/n.gif)
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.
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
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
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?
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.
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 really hoped there would be more about what they did wrong.
Or anything at all.
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.
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).
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.
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.
"You done messed up Balake!" we're never calling anyone Blake ever again 😂
Giving credit to the mascot is crazy; saying it has an intelligent demeanor just sent me.
The take on Go developer and one letter variables so so true just why 😂
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.
From now on, when I need the length of any array-like object, I'll just call it nn. What a good variable name!
Flip did not take Flip out
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
1:58 I'm fine with a writer named w. But I draw the line at `nn := len(p)`, that is just horrifying.
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"
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.
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.
Is there a Part 2 where he talks about the things Golang got wrong?
22:50 - I kind of agree that threads are not really the best model for concurrency. They're pretty hard to reason about.
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.
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.
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.
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.
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.
Booo only real language is MS PowerPoint
JDSL >>> MS PowerPoint
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
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.
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.
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.
Support for arbitrary-precision math doesn't mean that you can't enforce a specified precision, by the way.
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.
None of this explains why they had to make the syntax so fugly in Go.
2:10 they're minifying their Go code for faster shipping! :D
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. ;)
This guy’s entertaining and educational. well earned sub.
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
People that write one letter variables thinking they are saving time are too stupid to be writing code professionally.
Single letter names in a limited scope makes sense.
i love how prime's hair is also see through now xD
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.
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).
L take on the mascot. He’s just like “meeeeh let’s just get it done meeeeeh”
if only Go had learned the lessons that language developers already knew 30 years ago
Like?
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.
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.
10 minute build? The typescript project I'm currently working on takes 15-20 minutes to build the first time and my computer locks up while its building. Its so painful because its not even doing fancy optimizations or anything
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.👎
5:06 Elixir is better because it supports distributed processing and actor model out of the box. In go you would have to solve this problem yourself. I am sure there are libraries but still it is much better when language itself offers you the solution.
I wouldn't say Elixir, I would say Erlang/BEAM. Also Gleamlang is gonna best Elixir by a distance.
6:05 absolutely 100% agree. Best creations come out of inconveniences and annoyances
Can someone explain this to a senior C# dev? I don't see anything concrete mentioned in here
I abandoned Go because of the packaging system in the beginning.
I fail to see how function coloring (async) is a problem, when 99% of what you're doing in Node is IO-bound?
Like if you have a lot of CPU-bound operations, you shouldn't use Node
You shouldn’t use Node at all.
The vast majority of sites with heavy traffic use Node in some capacity, so the industry strongly disagrees.
Are there advantages to using other languages in certain situations? Most definitely. You don't have to convince me that other languages can scale or perform better.
But I almost guarantee that any other language will have a slower and/or less flexible JSON parser as well as less battle-tested tooling.
Also what’s with go and swift putting the case keyword for switch statements and expressions on the same indentations as the enclosing scope. It harms legibility, especially in nested switch expressions.
I can only think of one language where that isn’t the accepted style. That’s how switch has always worked. Because switch is the only keyword that does this it INCREASES readability.
@@ConernicusRex c# and Java invent before case in switch statements and the before the lines within switch expressions just like how they work in Kotlin’s when expressions
@@Bliss467 Yes and the syntax in proper Java or C# is that each case is on the same indentation as the opening of the switch itself. If you do it with cases indented you've been going against convention since you learned to switch.
13:48 Could this idea be used to solve the y2k bug?
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.
the lsp being to a similar level to copilot probably means most of your characters are boilerplate.
I came to Go for the concurrency and stayed for the Gopher
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.
Love his transparent hair style
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).
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.
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
"I don't want a mascot"
- 🦀
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
Interesting, I'm learning Go as well and dislike the one letter variables a lot. I thought maybe I'm just dumb, or it's because new to real programming (I'm devops btw), it'll take me time to get used to it. Just makes things hard to read like have to keep scrolling up and seeing wtf was w again? I'm a fan of more descriptive variable names.
~18:00 What's popular is rarely true, what's true is rarely popular!
100% agree with you about the one letter variables
The rust foundation is the biggest barrier to my own desire to go full send.
I actually love one letter vars for local variables. Naming often confabulates whereas you can just lookup a bit. It's honest.
I don't like that production code ends up with so much autogenerated code. The fast compiler provides no benefit if that time is merely transferred to code generation.
I prefer short variables so much, and keep the scope of the variables small
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.
6:36 cheese lovers be like
So even if they got anything wrong, they wouldn't tell us.
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.
before I was told it was a gopher, I was describing it as " the language with the beaver on crack"
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.
Anyone knows where the meme "cause of dark mode no one cares"?
Wait, if golang was going to have 2024 for itself, why are you using Zig instead @ThePrimeTime ?
wait was not 2024 supposed to be rust, you are playing on both sides ?
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.
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"
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.
That's what you get for advocating for abbr vars in a recent video. Now you get single letter variables.
I'm not saying write "index", everybody knows what "i" is. But don't write "srv" either - is it "service" or "server" or "some random variable"?
Erlang’s concurrency model, not Elixir’s.
And no, Go isn’t the greatest even Rob Pike says there is one superior to Go’s, ConcurrentML.
why would ConcurrentML be better than Erlang or Node.js?
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.
how are channels less leaky than promises?
If you use a Promise/async-await in a function, you have to declare it as async/return a Promise aswell. In go you can convert it to blocking/sync function with ease.
func DoSomething(arg int) int {
res_c := make(chan int)
go OtherStuff(res_c, arg)
res
It's wild, I was also wondering why the 1-2 letter variable names were so common in Go code... Makes no sense :|
Automatically handling integer overflow - Elixir mentioned
Go being 14 years old is crazy
You would probably get better feel for what has been said if you have watched the talk instead reading article about the talk. Article blows out of the proportion mascot thing, that was basically just warm up in the talk
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
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.
You could probably easily add auto integers as a new type, why not do that?
I would prefer go not to have Options/Optional/whatever, but to have mandatory not-nil pointers (aka references). So that I could pass pointer, never check it for nil myself and never fuck it up in runtime. Kinda a Kotlin-like behaviour.