You don't need to do what he did. TeeJ shows the line count for his neovim config with the tokei package, which is one command and it gives out nicer output.
@@harshitpant07 what? Because that's in the example? I don't care about counting lines of code, I was refering to a few pipes, command line parameters and a glueing things together. Nothing to do with counting lines of code.
go is so good for code reading for learning all thing other than coding. you can learn encrpytion, TCP , pacakge matching , media, h264 , FFT ...etc. , all those thing are way easier to read than all other language( yes, for code reading, It easier than python and JS) And because it so easy to read and have decent performance, you can see it can make a team project very easy. for me, go is always a good lenguage, not beacuse it easy to write, it because it easy to read.
I think with errors, there are three types: user errors (user enters an incorrect input), programmer errors (your algorithm is wrong) and enviroment errors (lost internet connection). I think only the user and possibly the enviroment errors have to be handled nicely, programmer errors should result in a crash
I agree, implicit interfaces in go really encapsulate some of the the sludge feeling in java and c#. This is such a goated feature in go. It makes scaling an app so much easier. Avoids so much frustrating refactoring when requirements change
@@gusryan actually you can quite easily do that Just assign instance of your struct to _ variable of that particular interface type. The program won't compile if you don't implement the interface
@@gusryan i used to think this until i really used go and completely inverted my stance. Its just as safe, faster, and more flexible than explicit interface implementations. Have you tried using it?
@@adambickford8720 In the context of fully dynamic languages, you are correct. That said, the terms "structural typing" and "duck typing" are interchangeable in Go parlance, and the latter has been used more commonly in my experience. That said - if you mean to say that Go does duck typing stuff at runtime, that's false. All "quacks like a duck" checks occur at compile time, and at runtime only vtable lookups occur.
@@bitmasked Duck typing is run time, structural subtyping is at compile time. Conflating them is wrong. en.wikipedia.org/wiki/Duck_typing#:~:text=Duck%20typing%20is%20similar%20to,that%20is%20accessed%20during%20runtime.
@@adambickford8720 I agree with you on the original meaning. Doesn't change the fact that the term has been borrowed, somewhat incorrectly, and is well understood to mean what is effectively structural typing. Good day.
U really start to appreciate a structural static type system if u want to test all of that stuff. It makes it much more enjoyable to test if u just hand in snippets instead of producing the mock-mess in a nominal static type system.
Really glad you are enjoying GO. I have been using it since 1.0 release. It is a great language, especially implied interfaces (kind of duck typing). Enjoy your channel. Thanks for the great content.
You should watch Mat Ryers talk titled "How I write HTTP Web Services after Eight Years"... he shows some really elegant idiomatic go code. and yes - duck typing interfaces (especially in tandem with struct embedding, which leads to inheriting its interface implementations) are game changers edit: the bit about the handlerfunc and idiomatic middleware chaining technique is mindboggling!
I find it funny but I'm happy that last year prime poke fun at go and had sort of attitude "why would you do go when there's better options in everything" and now I've seen him do go every time I've opened the stream. I suppose it goes to show that every language has a reason it exists to begin with and sometimes you only realise it by diving deep enough. Or do a project different from your usual projects. Obviously some languages are just part of histort now or never really succeeded in why they were trying to do so there's also just better options for the same thing.
Go is the Toyota Corolla of programming languages. It gets the job done, but leaves me wanting for more. Still, it gets the job done. It's easy and fast. I like that aspect of it.
I didn’t know about structured typing, that’s actually really cool… that’s starting to feel a little bit like multiple dispatch in my Julia-brain. Definitely less powerful, but in practice I bet it’s almost equivalent.
In BEAM world defining your “error kernel” (the subset of you application where you simply have to be correct or crash) is a big part of application design 😌
You should rarely ever panic/crash, especially if you're a library or a goroutine, because if you're running a service that will kill the whole service. You really want to get into the habit of just returning proper errors.
@@Heater-v1.0.0 Oh my God, I can relate to assembler, at least with assembler you *know* that you have really cross your T's and dot your I's. I get a lot of hate for disliking C++. I think C++ was a squandered opportunity.
Python also has Protocols for structural/duck typing. The main difference is that you have to wrap each Protocol in runtime_checkable to be able to enforce it at run time, which kind of sucks.
The funny thing is I started learning go because of your videos on how performant it was like three years ago but now you're saying you thought it was s**t. Maybe i misread the room, regardless I found it to be a good fit for me and am now a Go engineer.
Your philosophy on crashing is valid but I don't think it's as universal as you might think. I used to work in aerospace and we had recovery plans within recovery plans within recovery plans. The final destination of which was an "totalizing system recovery", if you will. Your mentality has to change about these things when human lives are on the line...
I really want to like GoLang. I really do. My issue with it was I was trying to create an API that did some light computing on the data that it received and I kept running out of core memory for the application. No matter how I increased the memory for the stack, it would not behave after running the computation. Writing a similar API endpoint in nodejs with express was: 1. Computed faster, 2. Could be rerun without issues, 3. Used less memory. I understand that I could've been doing something completely wrong with the ingested data (I was creating new objects for all 10k items in a JSON array) and I was doing this blind.
I'm a mostly Data driven programmer, but also very involved in text based languages. It's a very lonely place , because how prevalent text languages are and biased of text based developers. I honestly think you'd enjoy data driven languages too. It is utterly different paradigm and imo handles many development architects better. My opinion.😊
Go is such a great language, you really need to be nitpicky and have a lot of experience with it to actually point out its weak points. Every other language I tried I needed 2 hours with it to find something that annoys me or makes me anxious.
That's what rust does to ya. Your program is better but experience of making the program is a lot worse. Sometimes you just want to chill when you code.
The problem with Go for me is that it's very repetitive and its interface features are not really that great. You also don't get pattern matching or tagged unions and the error handling paradigm is kinda bad. There are just a lot of small things about it that don't really do it for me. Google's involvement in the project is not reassuring. While no language is perfect, I think it might be interesting if we had a language that's basically Rust, but garbage collected and maybe with a more extensive type system. You could argue that's Haskell or Ocamle but those languages just don't value reproducibility and backwards compatibility enough. If they had more of a backing from industry they would be a lot more enticing.
I've never thought go interfaces as being structural typing 🤔 I can see it but i associate that term so tightly with TypeScript it makes me feel weird lol
10:45 In face the guidance is that you should panic when the entire program is in an invalid state. Go panics if you try to access element 21 of a 5 element slice. That is an invalid operation and the assumption is that your logic is wrong. Likewise, as you say... when you unreachables have been reached then something is very wrong and very likely the best thing is to just dump the current state to a log and bail out. Essentially what Windows does with a BSOD. No time to figure out if this is somehow legit. This should not happen so pull the plug.
the tendency to do duck typing leads to an object doing all of the things. it leads to functions that are hundreds of lines that have a ton of side effects. the only advantage is that composition leads to excellent flexibility when refactoring. go's creators emphasizing that interfaces should be small is excellent architecture, but you can do that in most if not all strongly typed languages. strongly typed interfaces lead to your realizing that incorporating too many interfaces means the object is doing too much. of course if you're more senior you're going to have a lot of this worked out and you won't make as many of the above pitfalls, but when the possibility exists to "oh just one more thing" it will happen
I try Go as my new language for pet project and its fun and horrible, just because I write GO in JS-style. And I think major criticize post about Go actually about Java-Go code. All you need - write Go Go code, its perfect.
I have been programming Go since before 1.0 and I never seen any issues with the structural typing interfaces. There are a bunch of things things in Go that potentially could be problematic (like null references) but in practise I very rarely see any null access panics reach production environments. I can probably count the number of times that has happened on one hand in the programs I have worked on.
question: what are your editor text colors and whats the background color? i feel the contrast is just right without everything looking like a rainbow. please let me try them :P
I believe it's Rose Pine with the background color removed. For the background color of the terminal, I suggest you take out the color picker and grab it from the video. It looks pretty similar to what I've ended up using for years (#141414).
Having done a couple of years in go I have to say, there being no way to declare that a struct should implement an interface is up there with no enums as the most annoying traits of Go. Fixing it wouldn't even have to be a breaking change just give us a way to pin a struct to an interface for goodness sake. Even if it was just some absolute hack like using comments inside the string that would be better than nothing.
totally agree. Not having enums and union type is a bummer. the duck type for structs and interface is quite confusing too, and can get quite messed up if you split the implementation in multiple files. Rust is perfect in the way it addresses both things
What he described as a reason structural subtyping is good doesn't make sense to me. He literally copied the definition of the interface so he wouldn't get it wrong; would it hurt so much to declare explicitly that you're trying to implement the interface/trait/whatever so the compiler helps you?
This unironically happened to me with Java. Yes, it's very boilerplatey but using the right libraries the experience is great, OOP definitely has its upsides.
This might be my ignorance speaking but how is the structural typing in Go different from C++/Java interfaces? It's basically the same thing, right? Except maybe you don't have to explicitly declare what implements XYZ?
The answer is: there probably is no reason. I do the same when my ADHD brain thinks about something and I use my keyboard or editor as some kind of fiddle toy. I also often unnecessarily save while editing and coding during mental pauses. It would be perfectly reasonable to save once you completed some kind of function implementation etc., but I just perma :w. I mean, when you watch the way he codes, it's all just immediate conversion of thoughts into texts so that he probably also saves in this reactionary way.
crashing works great in a container/orchestrator environment. but when it hits baremetal/VMs, then the IT/ops overhead starts to take its toll. then you need monitoring set in place, logging setup (or deployed, depending on how much your employer is willing to spend on it), etc. Crashing would then suck in prod, but it would make the noc team take their job more seriously... or rather they will no longer be bored at seeing a green board majority of the time XD
@@Leeway4434 linux with systemd, sure... but what about the rest, like the sysv enjoyers, freebased lovers and the point-and-click adventurers aka windows admins? hence, my remark about the IT/ops overhead (meaning scripting involved to recover it automatically) ;)
structual typing is super hard to debug and refactor in a large codebase, it is such a pain to track down all the implement when it's effectively anonymous
11:28 i got a example about why you don't kill your app, or the "Java way of coding", why can't any one really use kdenlive, because if just the smallest of error happen, they kill the app, and the user lose all the work, and in the process of making a 1 hour video, you use 12 hours because it kill it self all the time. you can just print that and that feature have problems in a window and let the user try again,(and save) and in many cases stuff can work any way, so try to give the user the UX. and just killing the app is not that.
please let me know what golang doing bettern then c# or rust, there is no reason to use this pice of shiet. I work as a golang developer over 5 years and trust me i relly do not wont to change golang to different lang, and i want to be good one but this is just poor language without any pros over this two before.
Here is my opinion, c# is Microsoft's shit and I will take google's shit over MS's shit any day, plus I don't want to see classes everywhere. As for rust, it is a different perspective to programming and I don't need the hustle that comes with it, Odin or Zig are way better IMO, plus go isn't trying to replace rust (it has a GC). Also rust is becoming the JS/TS of the system programming languages, with huge dependencies and long compilation times everywhere.
"In Go, the zero value is the default value assigned to a variable of a given type when it is declared without an explicit initialization. The zero value depends on the type of the variable. For reference types, like pointers, slices, maps, channels, and interfaces, the zero value is nil" - That is why it's called nil and not null, because it's essentially the zero value.
This isn’t how this works, you can’t compare a struct instance to nil in the first place it won’t compile, but even if you changed it to &Weather{}, t==nil would be false.
When he started to talk in terminal commands I was really scared
Skill Issue
@@microburn nil issue
You don't need to do what he did. TeeJ shows the line count for his neovim config with the tokei package, which is one command and it gives out nicer output.
@@opposite342it’s not that hard to understand tho. Also that will work for everything, your config needs to be setup etc
@@Spelaren7254fair point
I feel like every primeagen video is just a showcase/flex of cmd line wizardry for us mere mortals ...
Really?
I think that's just normal average usage? How else do you do that stuff?
@@MartinMarcher I count the lines of each file...
@@MartinMarcher why do you need to count no. of lines in the first place
@@harshitpant07 what? Because that's in the example? I don't care about counting lines of code, I was refering to a few pipes, command line parameters and a glueing things together. Nothing to do with counting lines of code.
go is so good for code reading for learning all thing other than coding.
you can learn encrpytion, TCP , pacakge matching , media, h264 , FFT ...etc. , all those thing are way easier to read than all other language( yes, for code reading, It easier than python and JS)
And because it so easy to read and have decent performance, you can see it can make a team project very easy.
for me, go is always a good lenguage, not beacuse it easy to write, it because it easy to read.
I think with errors, there are three types: user errors (user enters an incorrect input), programmer errors (your algorithm is wrong) and enviroment errors (lost internet connection). I think only the user and possibly the enviroment errors have to be handled nicely, programmer errors should result in a crash
My mentality about writing code changed the day I discovered the power of golang interface
Go mentioned
Traits are way better
@@rez188 in what way?
@@carlosmspkin every way. They allow polymorphism but with proper type safety and no overhead of runtime dispatch
@@natescode but go lang's interfaces are also type safe. The check is performed before you run the code if I'm not mistaken
I agree, implicit interfaces in go really encapsulate some of the the sludge feeling in java and c#. This is such a goated feature in go. It makes scaling an app so much easier. Avoids so much frustrating refactoring when requirements change
I still wish you could do something like 'implements' just to make sure you're implementing all the methods you need
@@gusryan actually you can quite easily do that
Just assign instance of your struct to _ variable of that particular interface type. The program won't compile if you don't implement the interface
@@gusryan if a function takes an interface and youre missing a method defined on the interface, it wont compile
@@hamm8934 It's way nicer to see it when you're actually writing the struct
@@gusryan i used to think this until i really used go and completely inverted my stance. Its just as safe, faster, and more flexible than explicit interface implementations. Have you tried using it?
In Go we call it "duck typing". It it looks like a duck and quacks like a duck, it's a duck.
no it's not duck typing, it's structural typing.
Incorrect. Duck typing is a runtime construct, not compile time.
@@adambickford8720 In the context of fully dynamic languages, you are correct. That said, the terms "structural typing" and "duck typing" are interchangeable in Go parlance, and the latter has been used more commonly in my experience.
That said - if you mean to say that Go does duck typing stuff at runtime, that's false. All "quacks like a duck" checks occur at compile time, and at runtime only vtable lookups occur.
@@bitmasked Duck typing is run time, structural subtyping is at compile time.
Conflating them is wrong.
en.wikipedia.org/wiki/Duck_typing#:~:text=Duck%20typing%20is%20similar%20to,that%20is%20accessed%20during%20runtime.
@@adambickford8720 I agree with you on the original meaning. Doesn't change the fact that the term has been borrowed, somewhat incorrectly, and is well understood to mean what is effectively structural typing. Good day.
Hi! I really enjoy Go programming and all your videos, not just the ones about Go. I appreciate your talks. Cheers!
Its the same for me with C. Such a simple language, yet you can do a lot with it.
Dude, you are such a huge inspiration for me to get better and learn new stuff. Keep up the good work!
These are great points that all make me grateful I chose Swift.
Protocols, optionals and final class solve so many problems for me
bruh I have been grinding, learning coding, built projects in go. and I still have literally 0 idea wtf he is saying
Those Bell Labs people were something else.
They are true engineers
Yet it's a deadend
U really start to appreciate a structural static type system if u want to test all of that stuff.
It makes it much more enjoyable to test if u just hand in snippets instead of producing the mock-mess in a nominal static type system.
He's so goddamn right about structural typing
Really glad you are enjoying GO. I have been using it since 1.0 release. It is a great language, especially implied interfaces (kind of duck typing). Enjoy your channel. Thanks for the great content.
You should watch Mat Ryers talk titled "How I write HTTP Web Services after Eight Years"...
he shows some really elegant idiomatic go code.
and yes - duck typing interfaces (especially in tandem with struct embedding, which leads to inheriting its interface implementations) are game changers
edit: the bit about the handlerfunc and idiomatic middleware chaining technique is mindboggling!
The title makes a good impresson
only the real ones remember the old title
impresson
@@TheRealMangoDev it's not a misspelling, he just says that word with a spanish accent
I'm 10x this level dyslexic so I won't notice the defense
It still says "impresson". Was there a correctly-spelled title before?
no i just thought itd change
I find it funny but I'm happy that last year prime poke fun at go and had sort of attitude "why would you do go when there's better options in everything" and now I've seen him do go every time I've opened the stream.
I suppose it goes to show that every language has a reason it exists to begin with and sometimes you only realise it by diving deep enough. Or do a project different from your usual projects. Obviously some languages are just part of histort now or never really succeeded in why they were trying to do so there's also just better options for the same thing.
Go is the Toyota Corolla of programming languages. It gets the job done, but leaves me wanting for more.
Still, it gets the job done. It's easy and fast. I like that aspect of it.
I didn’t know about structured typing, that’s actually really cool… that’s starting to feel a little bit like multiple dispatch in my Julia-brain. Definitely less powerful, but in practice I bet it’s almost equivalent.
In BEAM world defining your “error kernel” (the subset of you application where you simply have to be correct or crash) is a big part of application design 😌
I'm going to give go a go... Just say I'm going to give go a go.
You should rarely ever panic/crash, especially if you're a library or a goroutine, because if you're running a service that will kill the whole service. You really want to get into the habit of just returning proper errors.
Very interesting you felt that way about Go's structural type system. TypeScript would like a word.
I agree, structural typing is amazing.
After programming in C++ professionally, I think Go is a Godsend.
A GOdsend?
@@i-am-linja Precisely
It's really funny how people might say "structural typing is so good omg less than three" but then dunk on c++ in the same breath.
After programming in C++ professionally I find almost anything a Godsend. Assembler is good. Rust is better. I'm sure Go is great where it is usable.
@@Heater-v1.0.0 Oh my God, I can relate to assembler, at least with assembler you *know* that you have really cross your T's and dot your I's. I get a lot of hate for disliking C++. I think C++ was a squandered opportunity.
I thought it was called duck typing? Looks like a duck quacks like a duck... it must be a dog acting like a duck
Same
Python also has Protocols for structural/duck typing. The main difference is that you have to wrap each Protocol in runtime_checkable to be able to enforce it at run time, which kind of sucks.
Structural sub-typing is pretty freaking useful for scaling teams.
The funny thing is I started learning go because of your videos on how performant it was like three years ago but now you're saying you thought it was s**t. Maybe i misread the room, regardless I found it to be a good fit for me and am now a Go engineer.
Do u use golang in ur job ?
Just asking
@@rajumondal4283 yeah
Love Go, love Prime, love the uploads 🤌🏻🤌🏻
Your philosophy on crashing is valid but I don't think it's as universal as you might think. I used to work in aerospace and we had recovery plans within recovery plans within recovery plans. The final destination of which was an "totalizing system recovery", if you will. Your mentality has to change about these things when human lives are on the line...
Congrats on finally using a good language! 🎉 Go is crazy underrated. Has all but replaced Python for me, except for little REPL one liners.
I was hoping he was gonna say "and now iv been using go for 5 7 months, and I know it's shit"
typescript is a gateway drug to golang
You're going to give go a real... go!
I really want to like GoLang. I really do.
My issue with it was I was trying to create an API that did some light computing on the data that it received and I kept running out of core memory for the application. No matter how I increased the memory for the stack, it would not behave after running the computation.
Writing a similar API endpoint in nodejs with express was:
1. Computed faster,
2. Could be rerun without issues,
3. Used less memory.
I understand that I could've been doing something completely wrong with the ingested data (I was creating new objects for all 10k items in a JSON array) and I was doing this blind.
skill issue
Skill issue
I'm a mostly Data driven programmer, but also very involved in text based languages.
It's a very lonely place , because how prevalent text languages are and biased of text based developers.
I honestly think you'd enjoy data driven languages too. It is utterly different paradigm and imo handles many development architects better. My opinion.😊
Were you overdoing Arc as well?
Go is such a great language, you really need to be nitpicky and have a lot of experience with it to actually point out its weak points. Every other language I tried I needed 2 hours with it to find something that annoys me or makes me anxious.
bro have known about implicit structural subtyping and the iterator pattern
After learning Rust, I really miss using C and am really happy with python and go
That's what rust does to ya. Your program is better but experience of making the program is a lot worse. Sometimes you just want to chill when you code.
The problem with Go for me is that it's very repetitive and its interface features are not really that great. You also don't get pattern matching or tagged unions and the error handling paradigm is kinda bad. There are just a lot of small things about it that don't really do it for me. Google's involvement in the project is not reassuring.
While no language is perfect, I think it might be interesting if we had a language that's basically Rust, but garbage collected and maybe with a more extensive type system. You could argue that's Haskell or Ocamle but those languages just don't value reproducibility and backwards compatibility enough. If they had more of a backing from industry they would be a lot more enticing.
have you taken a look at Vlang? it's exactly what you're looking for, but still in alpha release.
Vlang is maybe what you're looking for
You don't need those features.
The Stringer interfaces is BA.
My uni taught us C. Then i started learning go, it feels so good
Dang, I should come back to this video after a good understanding of go
I've never thought go interfaces as being structural typing 🤔 I can see it but i associate that term so tightly with TypeScript it makes me feel weird lol
Structural typing good but it is also why we can’t have generic receiver method 😢
10:45 In face the guidance is that you should panic when the entire program is in an invalid state. Go panics if you try to access element 21 of a 5 element slice. That is an invalid operation and the assumption is that your logic is wrong. Likewise, as you say... when you unreachables have been reached then something is very wrong and very likely the best thing is to just dump the current state to a log and bail out. Essentially what Windows does with a BSOD. No time to figure out if this is somehow legit. This should not happen so pull the plug.
the tendency to do duck typing leads to an object doing all of the things. it leads to functions that are hundreds of lines that have a ton of side effects. the only advantage is that composition leads to excellent flexibility when refactoring. go's creators emphasizing that interfaces should be small is excellent architecture, but you can do that in most if not all strongly typed languages. strongly typed interfaces lead to your realizing that incorporating too many interfaces means the object is doing too much. of course if you're more senior you're going to have a lot of this worked out and you won't make as many of the above pitfalls, but when the possibility exists to "oh just one more thing" it will happen
Sounds right for me.
Came for the go, stayed for the fluent xargs
I try Go as my new language for pet project and its fun and horrible, just because I write GO in JS-style. And I think major criticize post about Go actually about Java-Go code. All you need - write Go Go code, its perfect.
"Loosey Goosey" lmfao
Bro how many channels you have?
Go is great.
I have been programming Go since before 1.0 and I never seen any issues with the structural typing interfaces.
There are a bunch of things things in Go that potentially could be problematic (like null references) but in practise I very rarely see any null access panics reach production environments. I can probably count the number of times that has happened on one hand in the programs I have worked on.
This is so syntax heavy i won’t Go near it
Only 25 keywords my man
question: what are your editor text colors and whats the background color? i feel the contrast is just right without everything looking like a rainbow. please let me try them :P
I believe it's Rose Pine with the background color removed. For the background color of the terminal, I suggest you take out the color picker and grab it from the video. It looks pretty similar to what I've ended up using for years (#141414).
Having done a couple of years in go I have to say, there being no way to declare that a struct should implement an interface is up there with no enums as the most annoying traits of Go. Fixing it wouldn't even have to be a breaking change just give us a way to pin a struct to an interface for goodness sake. Even if it was just some absolute hack like using comments inside the string that would be better than nothing.
totally agree. Not having enums and union type is a bummer. the duck type for structs and interface is quite confusing too, and can get quite messed up if you split the implementation in multiple files. Rust is perfect in the way it addresses both things
What he described as a reason structural subtyping is good doesn't make sense to me. He literally copied the definition of the interface so he wouldn't get it wrong; would it hurt so much to declare explicitly that you're trying to implement the interface/trait/whatever so the compiler helps you?
This unironically happened to me with Java. Yes, it's very boilerplatey but using the right libraries the experience is great, OOP definitely has its upsides.
This might be my ignorance speaking but how is the structural typing in Go different from C++/Java interfaces? It's basically the same thing, right? Except maybe you don't have to explicitly declare what implements XYZ?
Why does Prime save files (:w) unchanged at 05:12, 05:14, 05:25?
The answer is: there probably is no reason.
I do the same when my ADHD brain thinks about something and I use my keyboard or editor as some kind of fiddle toy. I also often unnecessarily save while editing and coding during mental pauses.
It would be perfectly reasonable to save once you completed some kind of function implementation etc., but I just perma :w.
I mean, when you watch the way he codes, it's all just immediate conversion of thoughts into texts so that he probably also saves in this reactionary way.
Impresoooon Jsoooon
and now Zig
Does he have published the code on GH?
He has tons of code on there. So, maybe
crashing works great in a container/orchestrator environment. but when it hits baremetal/VMs, then the IT/ops overhead starts to take its toll. then you need monitoring set in place, logging setup (or deployed, depending on how much your employer is willing to spend on it), etc. Crashing would then suck in prod, but it would make the noc team take their job more seriously... or rather they will no longer be bored at seeing a green board majority of the time XD
or you just have a daemon restart it?
@@Leeway4434 linux with systemd, sure... but what about the rest, like the sysv enjoyers, freebased lovers and the point-and-click adventurers aka windows admins? hence, my remark about the IT/ops overhead (meaning scripting involved to recover it automatically) ;)
structual typing is super hard to debug and refactor in a large codebase, it is such a pain to track down all the implement when it's effectively anonymous
Go Go Go!!
MRyogurt on the video
Impressón
11:28 i got a example about why you don't kill your app, or the "Java way of coding", why can't any one really use kdenlive, because if just the smallest of error happen, they kill the app, and the user lose all the work, and in the process of making a 1 hour video, you use 12 hours because it kill it self all the time.
you can just print that and that feature have problems in a window and let the user try again,(and save) and in many cases stuff can work any way, so try to give the user the UX. and just killing the app is not that.
Empressión
let’s gooo
Keep selling
Is it cause of go? Or cause you left Netflix and just do what you like? )
😦😦😦
Duck typing is one of those things i don't like about go honestly
Tired this go love when the example programs are trivial
Ur a cutie
7K lines of a complex project like this? The guy is improving. Started as a JS kid and he's becoming a serious coder.
He should work at faang, netflix or something.
@@frknue Netflix doesn't say anything on how good a developer is. Especially at international scale.
please let me know what golang doing bettern then c# or rust, there is no reason to use this pice of shiet. I work as a golang developer over 5 years and trust me i relly do not wont to change golang to different lang, and i want to be good one but this is just poor language without any pros over this two before.
Here is my opinion, c# is Microsoft's shit and I will take google's shit over MS's shit any day, plus I don't want to see classes everywhere.
As for rust, it is a different perspective to programming and I don't need the hustle that comes with it, Odin or Zig are way better IMO, plus go isn't trying to replace rust (it has a GC). Also rust is becoming the JS/TS of the system programming languages, with huge dependencies and long compilation times everywhere.
Way too many abbreviations and shortened words. Too hard to read.
Personally I think Go is the ugliest language.
415 in 14 min.
TheVimeagen fell off
Stop using languages associated with Big Tech, i.e. Go, Java, C#
So, clojure. Got it thanks
x, err := so.annoying()
type Wether struct{
Temp int32
}
Var t *Weather
t==nil // True
New temperature of 0 degrees
t.Temp = 0
t==nil // True (what??!!!??)
"In Go, the zero value is the default value assigned to a variable of a given type when it is declared without an explicit initialization. The zero value depends on the type of the variable. For reference types, like pointers, slices, maps, channels, and interfaces, the zero value is nil" - That is why it's called nil and not null, because it's essentially the zero value.
This isn’t how this works, you can’t compare a struct instance to nil in the first place it won’t compile, but even if you changed it to &Weather{}, t==nil would be false.
@@massy-3961 that's not the point just do
var t *Weather , again you missed the point
@@diego.almeida not looking for an explanation I know all of that, bad language design leads you to this mess
@@KhaledKimboo4 well you'e comparing nil to nil why are you so surprised?