3 ms·
It's not really about Go, I think. But it makes me productive, and I like that. I don't think it's a magic bullet at all. Lots of things annoy me about it. But
by markusw 2y ago
It's not really about Go, I think. But it makes me productive, and I like that. I don't think it's a magic bullet at all. Lots of things annoy me about it. But it's _good enough_ for quite a lot of things IMO.
But tying shoes with a chainsaw does sound kinda fun. :D
- omeid2 2y agoI completely understand, but the productivity is superficial in my opinion, once you need to dig your teeth deeper into anything not "cloud" and "system engineering" with Go, overall productivity plummets hard. This is from some 10 years of Go experience. But like you say, it is not really about Go; my point is about the illusion of productivity that familiarity brings; it is very deceptive and hurts productivity in the long term.
- markusw 2y agoI don't understand. How can it be an illusion of productivity when it actually produces something that's very easy to see?
- randomdata 2y agoHe is saying what is very easy to see in certain contexts is not transferrable to the abstract. Go can be shockingly productive at certain tasks, but it also falls flat on its face at others. If you take your limited experience with Go (or whatever; this applies to all tools) where you found it to be highly productive and then conclude that it is always productive and therefore a tool you can use in all situations, you are bound to encounter negative productivity when you have a different problem to solve. Need to write, say, a network service? Go can no doubt give just about anything else a productivity run for their money. Need to solve a machine learning problem? ... Good luck. It can be done, of course, but you're quite likely in for a whole lot of extra work not needed in other ecosystems, destroying any semblance of productivity. In other words, the comment is a thinly veiled "use the right tool for the job".
- omeid2 2y agoProductivity is the sum of the aggregate output not just getting started. If you're familiar with a tool, you might be able to "get something" a lot quicker with it than learn to use the correct tool, but on the long term, the correct tool pays off better.
- theshrike79 2y agoVery few languages are good at _everything_. But what I do 95% of the time is backend services with APIs and CLI tooling, for both it's amazing. For GUIs it's hit and miss. There are some attempts at tooling, but they all feel a bit off to me. But Rust the same issue, as does C#. We need a modern Visual Basic again =)
- aragilar 2y agoI think well-written and engineered Python can do this (given the scripting/easy to call other languages bit), but there are still going to be bits where you're going to be fighting uphill (whether that's because the area is actively pushing against their preferred option, or where a scripting tool is inappropriate).
- steve_adams_86 2y agoIf someone can't tie their shoes with a chainsaw, they just haven't dedicated appropriate time to their tools :) Side note, this reminds me of a local YouTuber who mostly films himself using a chainsaw and has a remarkably large following (516k followers right now!). He also loves axes. I present to you Buckin' Billy Ray: https://www.youtube.com/@BuckinBillyRaySmith https://www.youtube.com/@BuckinBillyRaySmith I'm pretty sure this guy ties his shoes with a chain saw
- markusw 2y agoHaha, sweet. :D