4 ms·

Rust's pedantic safety rules (enforced by the compiler) give you a hard time as somebody who expects to be productive quickly. It's as if you learn programming

Rust's pedantic safety rules (enforced by the compiler) give you a hard time as somebody who expects to be productive quickly. It's as if you learn programming a second time in your life, but this time with different focus. This is not an experience for everybody, to understand that you did dangerous things in the past and now are enforced to avoid them. It is much easier if you have a Mentor or a ively seek out for the helpful online community by the way. About Go, well if you are not tageting C-like performance and not looking for pedantic savety, maybe it might be a better option. Interesting is that the wise people behind both languages decided against inheritance and deal with it in their own ways. It's worth giving Rust and Go a chance imao. Especially as C/C++ developer you can learn a lot to get better when coming back with more sensibility about ownership, lifetime and composition. It will make you grow as a programmer, especially Rust if you ask me.

urthor 5y ago
It's not my area at all, but to my non-expert knowledge the differences between generics and class based inheritance can border on the semantics at times. The high-level concept I always use to think about it is "coupling." Highly coupled data structures, people applying the very complicated solutions from Gang of 4 where it isn't needed. That's the core problem, and Go solves for the problem of "programmers misapplying highly-coupled data structures and doing bad things with Gang of 4 patterns" by explicitly removing that language feature.
- Cryptonic 5y ago
  Yes and I like inheritance being removed in Rust too. I too think thight coupling is a core problem of many programs, not only introduced by inheritance, but also multiple mutual references, for example in global state based C architectures (most I have seen, the Linux Kernel is better in this regard, CIs used very responsible there). Dependency Inversion (by interface reference or generics or any other technique) is the one pattern that is missing in the Gang of 4 Book and should be the most remembered, not Singleton (the tightest coupling one can introduce in his OOP system is by introducing Singletons). With loose coupling you can run the very same application with a few switched out dependencies on your bare metal embedded device with SPI driven display, on PC with minifb, as a websevice and with mocks in unit tests. I think it's preferable to always aim for loose coupling to enable testing, easier developing and later change. In that respective "Agile Software Development, Principles, Patterns, and Practices" is a much better old school programming book than "Design Patterns" imao (given the latter one is a decade older and the Gang could not have known) Languages that make thight coupling harder definitely teach a good lesson to learners, even if they have then go back to their day job in another language. Thanks for pointing that out.
  - urthor 5y ago
    It's funny because I am so far from the OOP world right now, I'm barely qualified to even comment on this topic given how little OOP I've done in the last 3 years. I've literally never done this stuff, but the idea of "coupling causes problems" is hugely important in my domain. I simply think it's important to understand the actual root cause of concepts, and put it into words. Clearly defining your ideas in concrete terms like "coupling" and "K.I.S.S." is really critical to the big picture. Having them as "fuzzy ideas" in the back of your head isn't good enough. Plus coupling as an issue is REALLY clear if you have a good mental model of "every single object is actually a line of hexadecimal going into the evaluator," In which case "a huge bunch of pointers between hexadecimal blocks is bad" makes perfect sense. I guess the other high level concepts would be stuff like "naming things is hard," "pointers = bugs," "design by iterating on MVPs," "mock tests are never useless, write them every time because they *force* you into single responsibility functions." But I'm still figuring out my bank of these ideas.

urthor 5y ago

It's not my area at all, but to my non-expert knowledge the differences between generics and class based inheritance can border on the semantics at times. The high-level concept I always use to think about it is "coupling." Highly coupled data structures, people applying the very complicated solutions from Gang of 4 where it isn't needed. That's the core problem, and Go solves for the problem of "programmers misapplying highly-coupled data structures and doing bad things with Gang of 4 patterns" by explicitly removing that language feature.

Cryptonic 5y ago
Yes and I like inheritance being removed in Rust too. I too think thight coupling is a core problem of many programs, not only introduced by inheritance, but also multiple mutual references, for example in global state based C architectures (most I have seen, the Linux Kernel is better in this regard, CIs used very responsible there). Dependency Inversion (by interface reference or generics or any other technique) is the one pattern that is missing in the Gang of 4 Book and should be the most remembered, not Singleton (the tightest coupling one can introduce in his OOP system is by introducing Singletons). With loose coupling you can run the very same application with a few switched out dependencies on your bare metal embedded device with SPI driven display, on PC with minifb, as a websevice and with mocks in unit tests. I think it's preferable to always aim for loose coupling to enable testing, easier developing and later change. In that respective "Agile Software Development, Principles, Patterns, and Practices" is a much better old school programming book than "Design Patterns" imao (given the latter one is a decade older and the Gang could not have known) Languages that make thight coupling harder definitely teach a good lesson to learners, even if they have then go back to their day job in another language. Thanks for pointing that out.
- urthor 5y ago
  It's funny because I am so far from the OOP world right now, I'm barely qualified to even comment on this topic given how little OOP I've done in the last 3 years. I've literally never done this stuff, but the idea of "coupling causes problems" is hugely important in my domain. I simply think it's important to understand the actual root cause of concepts, and put it into words. Clearly defining your ideas in concrete terms like "coupling" and "K.I.S.S." is really critical to the big picture. Having them as "fuzzy ideas" in the back of your head isn't good enough. Plus coupling as an issue is REALLY clear if you have a good mental model of "every single object is actually a line of hexadecimal going into the evaluator," In which case "a huge bunch of pointers between hexadecimal blocks is bad" makes perfect sense. I guess the other high level concepts would be stuff like "naming things is hard," "pointers = bugs," "design by iterating on MVPs," "mock tests are never useless, write them every time because they *force* you into single responsibility functions." But I'm still figuring out my bank of these ideas.