3 ms·

Eve more so in Go where the single standalone executable can: - run code - build code - format code - generate code - profile code including flame graphs

by hu3 3y ago

Eve more so in Go where the single standalone executable can: - run code - build code - format code - generate code - profile code including flame graphs - run tests and report performance down to allocations - benchmark code - manage packages - manage workspaces - scan and vet suspicious code It's amazing how much a 2 character command can do.

jchook 3y ago
And yet, the number of times 3rd party Go code has died on my macOS machine due to a segfault...
jrockway 3y ago
gofmt is actually a separate command.
- hu3 3y ago
  Indeed! And it can be called from go command too: go fmt main.go https://pkg.go.dev/cmd/go#hdr-Gofmt__reformat__package_sources https://pkg.go.dev/cmd/go#hdr-Gofmt__reformat__package_sourc...
hyperman1 3y ago
Since I started programming, I see every generation of programming languages slowly raise the bar. From the top of my head, in the order I encountered them. * C: make gave a standard way to compile/link a program. * Perl: CPAN as standard library/repository location. * Java: javadoc gave a standard format for low level documentation. Rules like 1 file=1 class, 1 folder=1 package gave a standard source tree layout. * Java/maven gave standard way to download, install and upgrade dependencys * Go: Built in formatter. * rust: cargo combines the strengths of Go standardization and Java/maven repositorys Every iteration provides extras that the previous tooling generation sees as trivial. They'll say you can add them to the mix yourself if you want to. Their company likes things in a different way, and are happy to have the option. But that's missing the point. The whole language ecosystems standardizes on a reasonable (but not 100% perfect) way of working. This has a lot of secondary benefits: * People move easily between organisations with minimal up-to-speed costs. * Somewhere in the ecosystem, someone still has your ancient tooling version, and the upgrade path is clear(er). * No discussion about in-house standards. (Try to get 2 C programmers agree on a coding style and watch the hours fly discussing what to take from ugly K&R vs ugly GNU.) * Real pain-points get solved, because someone feels your pain. I've seen the in-house stack developed by a Cobol company. It's finely tuned to that 1 company, yielding huge benefits. It's also a very non-trivial investment and maintenance cost.

by hu3 3y ago

jchook 3y ago

And yet, the number of times 3rd party Go code has died on my macOS machine due to a segfault...

jrockway 3y ago

gofmt is actually a separate command.

hu3 3y ago
Indeed! And it can be called from go command too: go fmt main.go https://pkg.go.dev/cmd/go#hdr-Gofmt__reformat__package_sources https://pkg.go.dev/cmd/go#hdr-Gofmt__reformat__package_sourc...

hyperman1 3y ago

Since I started programming, I see every generation of programming languages slowly raise the bar. From the top of my head, in the order I encountered them. * C: make gave a standard way to compile/link a program. * Perl: CPAN as standard library/repository location. * Java: javadoc gave a standard format for low level documentation. Rules like 1 file=1 class, 1 folder=1 package gave a standard source tree layout. * Java/maven gave standard way to download, install and upgrade dependencys * Go: Built in formatter. * rust: cargo combines the strengths of Go standardization and Java/maven repositorys Every iteration provides extras that the previous tooling generation sees as trivial. They'll say you can add them to the mix yourself if you want to. Their company likes things in a different way, and are happy to have the option. But that's missing the point. The whole language ecosystems standardizes on a reasonable (but not 100% perfect) way of working. This has a lot of secondary benefits: * People move easily between organisations with minimal up-to-speed costs. * Somewhere in the ecosystem, someone still has your ancient tooling version, and the upgrade path is clear(er). * No discussion about in-house standards. (Try to get 2 C programmers agree on a coding style and watch the hours fly discussing what to take from ugly K&R vs ugly GNU.) * Real pain-points get solved, because someone feels your pain. I've seen the in-house stack developed by a Cobol company. It's finely tuned to that 1 company, yielding huge benefits. It's also a very non-trivial investment and maintenance cost.