This is a weekly roundup of awesome DEV comments that you may have missed. You are welcome and encouraged to boost posts and comments yourself using the #bestofdev tag.
Lots of great answers in the What common programming concept has the wrong name? , but none more well-loved than @ryancmcconnell's contribution:
Replying to Rust or Go for web development?, @oliverjumpertz offers some great thoughts about both languages:
What parts of web development do you want to get involved in? And should your choice of language lead to more job opportunities?
Go is still pretty hyped and popular because it is very easy to learn and easy to get results with. Its concurrency model is far easier to understand than traditional thread-based ones and the ecosystem exploded some time ago, with so many great libs and frameworks nowadays.
I/O in Go is async by default without you mostly noting it, because the runtime takes care of it for you.
I've been programming for nearly 20 years now (with only a fraction of it being professionally) so the following may not apply to you, but it took me only one day to learn Go and write my first piece of software in it, without it failing horribly at runtime.
The only issue I ran into was its exotic handling of dependencies ($GOPATH, etc.), which got better with the introduction of gomodules and still improves, that gave me a hard time.
The number of jobs listed for Go is pretty decent currently (please note: highly depending on where you live).
Rust on the other hand is difficult to learn but very easy to use once you actually understand it and successfully fought the compiler and borrow checker until you became very close friends (but this will take you way more time than learning Go).
I believe that it took me two weeks before I was able to write simple programs without the compiler complaining too much. But boy, once something in Rust compiles, you can be pretty sure that it'll just work!
What differentiates Rust from Go is that there's no runtime (which takes care of certain things for you). Thus you have way more control over the actual outcome of what you do.
Writing Rust code comes pretty close to how you write code in other popular languages. That's not that much new to learn, which comes in very handy, given, that you have to learn a lot of other concepts like borrowing, etc., you did not have to bother with while using memory managed languages.
Rust comes with Cargo, which, in contrast to Go's $GOPATH / gomodule system, is like heaven on earth. It makes handling of dependencies, building, etc. so easy and so much fun and doesn't get in your way.
Depending on where you live, the number of job postings that do not directly relate to blockchain may be far less than those for Go and this may limit your opportunities.
There's nothing one of these languages can achieve that the other doesn't, so no drawbacks there with either of them. Both can be used for pretty much anything. You can write REST-APIs with both, you could implement a new database, both compile to WASM, pretty much anything you could imagine.
That's only the tip of the iceberg but perhaps it helps you a little to decide.
Try out both, write a simple program, and then see what you have more fun with.
Github, Apple.com, Shopify all use Ruby. I am currently employed as a Ruby developer. It happens to be great language for learners, but in general, use whatever language brings you joy and gets you a paid gig, both of which happen for me.
Solo projects are fun because you can break all the rules if you'd like. In Git Workflow: Do you commit to master on your solo projects?, @gnsp jumps in with their flow:
Normally I work on the master branch in the initial phase. Once I reach a stable state with the most basic functionalities, I branch out. If there are more than one way of implementing something that I need to try out, then implementing them in separate branches makes more sense to me.
Like you mention, while working solo, one works on one feature at a time -- that's true for 9 cases out of 10. Even so I prefer working on a separate development branch. In any case, switching to a stable branch is always faster and easier than finding the stable commit and checking out to that commit.
See you next week for more great comments ✌