3 ms·

My original discussion was of that I thought Go was very hidden under the hood. I gave an example and got mobbed for it. I replied with emotion and misunderstan

My original discussion was of that I thought Go was very hidden under the hood. I gave an example and got mobbed for it. I replied with emotion and misunderstanding and here we are. The main thing I was going on is "Here's a GitHub link, add it to your code and you have an instant logger thing". Magic in my eyes and this blinding light throws me off. Unlike Perl where the code is in a .pm file in front of you. That was what I was trying portray. I'm going to leave this discussion to rest as it's all went wrong anyway. Tomorrow will be tomorrow and this will all be forgotten in a day. Thank you for your responses and have a good evening.

hnlmorg 6y ago
But the point is Go and Perl behave exactly the same way with regards to all the points you argued where they differ. Literally every point you've raised people have proven false. The problem here isn't that Go has some hidden magic, it's that you've never bothered to spend even 10 seconds checking if the packages were downloaded; instead inventing some wild, made up, theories about how things might work. This lead you to make some pretty daft claims like the Go compiler can build code that doesn't exist on disk (even as a non-developer sysadmin you must realise that's a pretty stupid claim to make?) To be honest, I wonder if you're even using Perl correctly because if you're installing CPAN modules correctly then the .pm file is stashed away in an alternative directory that's looked up via an environmental variable -- just like with Go. The Perl module shouldn't be present in your projects workspace (and actually Go makes things easier than Perl here by allowing modules to be "vendored"). Go and Perl are very similar in a great many ways: + Both languages order modules/packages by directory hierarchies + Both languages look up module/package paths via special environmental variables + Both have CLI tooling to download and install modules/packages + Both have CLI tooling to read module/package documentation + Both are very much command line orientated + Both are imperative languages who's object systems feel like a half-arsed after thought and thus both really feel more at home writing functional code than OOP. + Both allow functions to return multiple parameters (a trait that's not too common outside of Perl and Go) + Both are strictly typed, support duck typing, and have a fairly limited type system. + Both treat arrays/slices and hash/maps as special types where the runtime has to have special code for handling them (ie you couldn't create a custom data type like a array/slice nor hash/map using Perl/Go's own standard library). In fact the very reason I warmed to Go was because it felt like a nice hybrid between Perl and C. This was why I was so baffled when you said Go had some hidden behaviours under the hood when in fact managing a Go project is actually very similar to managing a Perl project.

hnlmorg 6y ago

But the point is Go and Perl behave exactly the same way with regards to all the points you argued where they differ. Literally every point you've raised people have proven false. The problem here isn't that Go has some hidden magic, it's that you've never bothered to spend even 10 seconds checking if the packages were downloaded; instead inventing some wild, made up, theories about how things might work. This lead you to make some pretty daft claims like the Go compiler can build code that doesn't exist on disk (even as a non-developer sysadmin you must realise that's a pretty stupid claim to make?) To be honest, I wonder if you're even using Perl correctly because if you're installing CPAN modules correctly then the .pm file is stashed away in an alternative directory that's looked up via an environmental variable -- just like with Go. The Perl module shouldn't be present in your projects workspace (and actually Go makes things easier than Perl here by allowing modules to be "vendored"). Go and Perl are very similar in a great many ways: + Both languages order modules/packages by directory hierarchies + Both languages look up module/package paths via special environmental variables + Both have CLI tooling to download and install modules/packages + Both have CLI tooling to read module/package documentation + Both are very much command line orientated + Both are imperative languages who's object systems feel like a half-arsed after thought and thus both really feel more at home writing functional code than OOP. + Both allow functions to return multiple parameters (a trait that's not too common outside of Perl and Go) + Both are strictly typed, support duck typing, and have a fairly limited type system. + Both treat arrays/slices and hash/maps as special types where the runtime has to have special code for handling them (ie you couldn't create a custom data type like a array/slice nor hash/map using Perl/Go's own standard library). In fact the very reason I warmed to Go was because it felt like a nice hybrid between Perl and C. This was why I was so baffled when you said Go had some hidden behaviours under the hood when in fact managing a Go project is actually very similar to managing a Perl project.