4 ms·

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

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
      Essentially I am asking you to be that mentor (to your past self) and share the email you could write, specific to YOUR particular coding that you were doing. Think a mentor should include "why"? Then include why. Remember: I didn't ask for a shortcut, I asked for specific sentences that you could have sent back in time to prevent this: >months later I was still dealing with the consequences of early bad decisions. Your sentences can be literally anything, specific to your specific situation, that could have prevented those bad decisions. So, let's be clear. Your message to the past you reads: "Hi - I am you from the future. I was asked to send back a message in time listing specific things you can do right now, having just learned Go, based on my having to deal with your code, that can prevent your bad decisions which you will be dealing with months later. It is impossible to put this into English words. So, I have no advice for you of any kind. Fuck you, past-me. And also fuck me - I'll just have to deal with your lack of understanding. I hope you have found this mentoring by me to be as helpful as I have. I don't believe in mentoring." So, that's the new version of your message, based on your review of your own code and memory of your decisions and learning process at the time. Well, okay. I guess I accept your viewpoint. (Note: if there's some other reason you don't want to answer publicly, such as not talking about your codebase, you can email me at the email in my profile.) I am looking for specific architectural advice, using your experience as a case study.

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
    Essentially I am asking you to be that mentor (to your past self) and share the email you could write, specific to YOUR particular coding that you were doing. Think a mentor should include "why"? Then include why. Remember: I didn't ask for a shortcut, I asked for specific sentences that you could have sent back in time to prevent this: >months later I was still dealing with the consequences of early bad decisions. Your sentences can be literally anything, specific to your specific situation, that could have prevented those bad decisions. So, let's be clear. Your message to the past you reads: "Hi - I am you from the future. I was asked to send back a message in time listing specific things you can do right now, having just learned Go, based on my having to deal with your code, that can prevent your bad decisions which you will be dealing with months later. It is impossible to put this into English words. So, I have no advice for you of any kind. Fuck you, past-me. And also fuck me - I'll just have to deal with your lack of understanding. I hope you have found this mentoring by me to be as helpful as I have. I don't believe in mentoring." So, that's the new version of your message, based on your review of your own code and memory of your decisions and learning process at the time. Well, okay. I guess I accept your viewpoint. (Note: if there's some other reason you don't want to answer publicly, such as not talking about your codebase, you can email me at the email in my profile.) I am looking for specific architectural advice, using your experience as a case study.