3 ms·

I agree. And may I add the ecosystem: which third party modules you should or shouldn't be looking at, and if you should rely on them or roll your own.

by wvh 9y ago

stouset 9y ago
Then months for best practices, idioms, and understanding the pitfalls around concurrency and channels, which are nowhere near as "batteries-included" as people would lead you to believe. This "hype" around go letting you be productive sooner is honestly just bullshit. I've been programming for 20 years, with C, C++, Ruby, Perl, Scheme, Haskell, Rust, Go, Java, and others I've surely forgot. Sure, I was able to start writing go within a day. But it was terrible go, and months later I was still dealing with the consequences of early bad decisions. This isn't unique to go by any means. But if you go in thinking you're going to write a project that does some sort of non-trivial task and be able to rely on that later, you're going to have a bad time.
- greenhouse_gas 9y ago
  But that's true with all those languages too. If you're an experienced Java programmer moving to Rust, you'll write Java in Rust. So it's 1 day of learning Go + 1 month of learning style vs 2 weeks of learning Rust + 1 month of learning style. [1] [1] Note, I think that Rust has the best community when it comes to getting beginners up to par, whether in #rust-beginners or on /r/rust. It just is a hard and not forgiving language.
  - stouset 9y ago
    > But that's true with all those languages too. That is exactly my point, and I said as much in my post. > So it's 1 day of learning Go + 1 month of learning style vs 2 weeks of learning Rust + 1 month of learning style. More like 1 day vs. 1 week, with six months of ramp-up before you're writing anything approximating production-quality code. At which point, does it really matter that you were able to write garbage in one day rather than seven?
    - logicallee 9y ago
      Hi. Could you (or anyone else here!) kindly answer this question: https://news.ycombinator.com/item?id=14934690 https://news.ycombinator.com/item?id=14934690 One way to get your correct answer is for me to propose a wrong or partial answer. How is this as a message to the past (i.e. I am guessing your answer to the above request): WRONG/FAKE ANSWER: "Note to past self: although you can write code that compiles on day 1 and day 2, before considering your code idiomatic and ready to build on top of (or even deploy to production), DO/LEARN THE FOLLOWING: 1) read and work through all of The Go Programming Language book. This teaches all idioms. 2) Practice and use Go's testing tools (built-in). Always use its reformat tool applied on every save from your IDE. 3) Begin using a better error and logging library than the built-in error passing idiom. Google this. 4) Use a debugger. Google this. 5) Security and versioning with go get is broken: Google this and learn vendoring with versions. Otherwise your code cannot go on production. 6) You control garbage collection frequency. Learn to set this. In emergencies disable it entirely to trade memory for latency to gain one or two milliseconds (approach hard realtime), for example when you are dropping requests. Then reenable when you can take the (very small) hit. Garbage collection is very efficient and low-latency. 7) Channels and concurrency (goroutines) do not work as described. Specifically: - This link will solve your problems with channels: https://stackoverflow.com/questions/41200505/whats-the-best-practice-to-synchronise-channels-and-wait-groups https://stackoverflow.com/questions/41200505/whats-the-best-... Adopt it. Then they work as described. For goroutines: Follow this document - https://gist.github.com/pzurek/6642797 https://gist.github.com/pzurek/6642797 After incorporating the above specific changes, you are ready to commit to production and build on top of what you want to build. " is the above message completely wrong and bullshit? Then please correct it. Your insight and experience are appreciated and I would love to read what you would write as a message to yourself in the past, to save those lost months. Thank you.
      - stouset 9y ago
        Those months weren't "lost". There's no shortcut to learning idioms, best practices, and — more importantly — understanding the most natural way to model a solution in whatever language you're working with. Sure, read books and blog posts. Test things. Learn debugging tools. But nothing really substitutes for actually working with a language. Having an experienced mentor helps, but only if they're advising you on why they chose a certain approach, or why a critiqued approach you chose was bad.
- logicallee 9y ago
  Hi! Thanks for replying with this useful information! (I'm just excited to have it - I don't work on Go or anything.) You refer to: >best practices, idioms, and understanding the pitfalls around concurrency and channels, which are nowhere near as "batteries-included" as people would lead you to believe. Could you summarize these? You wrote: >Sure, I was able to start writing go within a day If you could send back in time a brief note to yourself to prevent >months later I was still dealing with the consequences of early bad decisions. then what would you write? You can include links that the "day 1" version of you should have followed, or simply warnings. I would be highly interested in more information on the above, from you or anyone else here. Thanks so much!

I agree. And may I add the ecosystem: which third party modules you should or shouldn't be looking at, and if you should rely on them or roll your own.

by wvh 9y ago

I agree. And may I add the ecosystem: which third party modules you should or shouldn't be looking at, and if you should rely on them or roll your own.

stouset 9y ago

Then months for best practices, idioms, and understanding the pitfalls around concurrency and channels, which are nowhere near as "batteries-included" as people would lead you to believe. This "hype" around go letting you be productive sooner is honestly just bullshit. I've been programming for 20 years, with C, C++, Ruby, Perl, Scheme, Haskell, Rust, Go, Java, and others I've surely forgot. Sure, I was able to start writing go within a day. But it was terrible go, and months later I was still dealing with the consequences of early bad decisions. This isn't unique to go by any means. But if you go in thinking you're going to write a project that does some sort of non-trivial task and be able to rely on that later, you're going to have a bad time.

greenhouse_gas 9y ago
But that's true with all those languages too. If you're an experienced Java programmer moving to Rust, you'll write Java in Rust. So it's 1 day of learning Go + 1 month of learning style vs 2 weeks of learning Rust + 1 month of learning style. [1] [1] Note, I think that Rust has the best community when it comes to getting beginners up to par, whether in #rust-beginners or on /r/rust. It just is a hard and not forgiving language.
- stouset 9y ago
  > But that's true with all those languages too. That is exactly my point, and I said as much in my post. > So it's 1 day of learning Go + 1 month of learning style vs 2 weeks of learning Rust + 1 month of learning style. More like 1 day vs. 1 week, with six months of ramp-up before you're writing anything approximating production-quality code. At which point, does it really matter that you were able to write garbage in one day rather than seven?
  - logicallee 9y ago
    Hi. Could you (or anyone else here!) kindly answer this question: https://news.ycombinator.com/item?id=14934690 https://news.ycombinator.com/item?id=14934690 One way to get your correct answer is for me to propose a wrong or partial answer. How is this as a message to the past (i.e. I am guessing your answer to the above request): WRONG/FAKE ANSWER: "Note to past self: although you can write code that compiles on day 1 and day 2, before considering your code idiomatic and ready to build on top of (or even deploy to production), DO/LEARN THE FOLLOWING: 1) read and work through all of The Go Programming Language book. This teaches all idioms. 2) Practice and use Go's testing tools (built-in). Always use its reformat tool applied on every save from your IDE. 3) Begin using a better error and logging library than the built-in error passing idiom. Google this. 4) Use a debugger. Google this. 5) Security and versioning with go get is broken: Google this and learn vendoring with versions. Otherwise your code cannot go on production. 6) You control garbage collection frequency. Learn to set this. In emergencies disable it entirely to trade memory for latency to gain one or two milliseconds (approach hard realtime), for example when you are dropping requests. Then reenable when you can take the (very small) hit. Garbage collection is very efficient and low-latency. 7) Channels and concurrency (goroutines) do not work as described. Specifically: - This link will solve your problems with channels: https://stackoverflow.com/questions/41200505/whats-the-best-practice-to-synchronise-channels-and-wait-groups https://stackoverflow.com/questions/41200505/whats-the-best-... Adopt it. Then they work as described. For goroutines: Follow this document - https://gist.github.com/pzurek/6642797 https://gist.github.com/pzurek/6642797 After incorporating the above specific changes, you are ready to commit to production and build on top of what you want to build. " is the above message completely wrong and bullshit? Then please correct it. Your insight and experience are appreciated and I would love to read what you would write as a message to yourself in the past, to save those lost months. Thank you.
    - stouset 9y ago
      Those months weren't "lost". There's no shortcut to learning idioms, best practices, and — more importantly — understanding the most natural way to model a solution in whatever language you're working with. Sure, read books and blog posts. Test things. Learn debugging tools. But nothing really substitutes for actually working with a language. Having an experienced mentor helps, but only if they're advising you on why they chose a certain approach, or why a critiqued approach you chose was bad.
logicallee 9y ago
Hi! Thanks for replying with this useful information! (I'm just excited to have it - I don't work on Go or anything.) You refer to: >best practices, idioms, and understanding the pitfalls around concurrency and channels, which are nowhere near as "batteries-included" as people would lead you to believe. Could you summarize these? You wrote: >Sure, I was able to start writing go within a day If you could send back in time a brief note to yourself to prevent >months later I was still dealing with the consequences of early bad decisions. then what would you write? You can include links that the "day 1" version of you should have followed, or simply warnings. I would be highly interested in more information on the above, from you or anyone else here. Thanks so much!