"I found learning Rust MUCH more satisfying than learning Go."
Really? I took a short look at the Rust syntax and got instantly headache :D I came from java to php to javascript to typescript. So i would say i love type safety and object oriented programming,
I didn't say OO, I said FP hehe ;-) although Rust supports OO as well.
Well yes like I said, Rust has a steep learning curve so I can imagine your initial reaction. You need to put in some time and effort to overcome that initial hurdle.
But I can promise you, until they add generics to Golang you will just be doing lots of old fashioned procedural programming there, coding for loops until you see blue in the face. No more map/filter/reduce for you, like you used to be able to use in Javascript ... that was probably my biggest disappointment about Golang.
Are you a VSCode user? I think VSCode works with Rust ... I've used Jetbrains products before but I've switched completely to VSCode, except for some occasional (now rare) Java work for which I use Eclipse ...
Software Engineer and full-time Rustacean. While Rust is my primary language, I am also fluent in Python and Typescript. I'm also currently making a game with Godot using C#.
The Rust plugin for IntelliJ is fantastic, and does some things better than VS Code, such as automatic imports (my favourite feature!). VS Code is very good too however and I do like the progress on rust-analyzer.
That said, the Go plugin for IntelliJ is also really nice too.
Yes, in the beginning this sort of stuff leaves you horribly confused, this is exactly what Rust's infamous "learning curve" is about. I had to read the Rust documentation pages 2 or 3 times before it all clicked, "String" vs "str" was a brain twister initially.
To me it feels like Go was cobbled together, Rust seems to be more methodically designed. And what intrigues me is the idea that Rust could be the first "mainstream" language to introduce FP (functional programming) concepts other than the obligatory map/filter/reduce to the masses, although it isn't a pure FP language by any means ... Haskell, Scala, Clojure etc are just too "niche".
I think go was not a language that was "planed" with the ulterior motives to be for the public and has to be "good". In the first, it was planned to solve google internal problems which other langs could not solve in the way that google needs it to bes solved. Compared to Rust i think was more a "planned" language for the public.
Well-versed in the technical side of things thanks to extensive Software Engineering experience. Enthusiastic about Statistical Inference, Machine Learning and Visualizations. He/him.
So i would say i love type safety and object oriented programming
Then you're very likely to have very hard time with Rust.
While Rust do promote type safety to very large degree it's different type-safety than Java's or TypeScript's. More akin to Haskell type-safety. It's somewhat hard to wrap one's had around that.
And to large degree Rust does not provide or support OOP. Programming with structs and traits is significantly different from class-and-interface-based OOP, usual designs and patterns do not apply. Even if you do emulate OOP in Rust (which is somewhat awkward but possible) you will have hard time integrating your design with borrow-checker, libraries and frameworks (especially async ones).
It doesn't mean you won't be able to learn Rust or you shouldn't learn Rust. It just means it might require much more time and effort that it seams because you're likely will need to "unlearn" a lot of stuff.
Spot on, I forgot to mention how much Rust reminded me of Haskell ...
Yes, type safety in Rust is more based on abstract/algebraic data types, much like Haskell. It really raises the abstraction level and allows one (if used well) to write succinct and "correct" software (the amount of static analysis the compiler can do to check if your code is 'correct' is amazing).
Compare that with the banal type checks of other languages, whether you're passing in a string or an integer, and you can see that it's on a completely different level. It's elegant and powerful.
And yes, OO (especially the "classic" variant with inheritance and so on) feels indeed like a second class citizen in Rust ...
I'd argue that that's almost a good thing, I haven't used classical conventional inheritance for ages ... programming with interfaces and abstract types (and generics and so on), yes by all means, it's supported, but forget "classic" OO with its emphasis on inheritance.
Well-versed in the technical side of things thanks to extensive Software Engineering experience. Enthusiastic about Statistical Inference, Machine Learning and Visualizations. He/him.
Well, I'd say "plain old" Abstract Data Types and Algebraic Data Types are about the same level as an "ordinary" Java/C# type-checking (and hence type-safety). The thing is Rust doesn't stop there (not even mentioning Haskell): huge chunk of expressiveness and safety comes from advanced "type-level programming" with generics and some neat (and hard-to-wrap-your-head-around) tricks with (opaque) lifetime parameters. That's indeed far beyond the experience of a "normal" OO-developer as most OO languages lack such facilities. It's similar to what half of Scala developers do with their type-level programming (and for that the other half of Scala developers hates them).
And we still haven't even mentioned two kinds of Rust macros...
OO inheritance just don't play along with all that features. That's why one has to forget about it to fit into the ecosystem of libraries and frameworks. But then you have to learn to program (and think) without inheritance...
Yeah to me the safety and performance benefits one can reap off Rust are totally worth the troubles. But I knew Haskell when I started learning Rust so I knew how to program without OOP (and some type-level "magic" too). For someone coming from Java that might not be worth the trouble.
Though I know some people who learned Rust after just Python or as the first language and totally love it. :D
Amen to all that! Ah yes the macros, that's another powerful one ...
I definitely think it is worth the trouble for a Java programmer to learn that there's another way, expressiveness over verbose "patterns" and a 10 level deep class hierarchy ...
Having studied Haskell before Rust was definitely a good thing because I recognized so much on a conceptual level, seeing those concepts and approached pop up again in a different language was an eye opener.
And I'd argue that Rust is at the same time still more accessible to the "mainstream" programmer than Haskell or Scala.
Well-versed in the technical side of things thanks to extensive Software Engineering experience. Enthusiastic about Statistical Inference, Machine Learning and Visualizations. He/him.
I definitely think it is worth the trouble for a Java programmer to learn that there's another way, expressiveness over verbose "patterns" and a 10 level deep class hierarchy ...
One does not need to learn a new language, ah sure, even the newest versions of Java have some FP-style stuff like filter/map/reduce and so on ... it's just that a language like Haskell (or Rust, to a lesser extent) "forces" you more into that style.
Nice article, well yes if your level of design thinking allows you to break away from "controller" style procedural thinking and towards splitting it into objects (or functions, for that matter) with clearly defined responsibilities which "do one thing" then you're also prepared to go the FP way ... that's what you were trying to say or not?
Well-versed in the technical side of things thanks to extensive Software Engineering experience. Enthusiastic about Statistical Inference, Machine Learning and Visualizations. He/him.
I guess what I'm trying to say is that FP is not a silver bullet. What really matters is clear understanding of the problem and the solution, and good modular and composable design.
Pure FP languages like Haskell do nudge you in that direction first, because pure functions are the most composable thing in our arsenal, second through culture and mechanisms of algebraic design. But all of that takes you only this far. If you really want to go an extra mile and produce even better designs for your programs you have to go beyond and above just language mechanisms and learn and think in more abstract terms.
But at that level particular language and even paradigm doesn't matter that much. With clear understanding of both problem and solution, and good design skills and experience one can produce excellent OO design as well as FP design or even just "structural" design in the sense of good 'ol structural programming.
I'm nowhere near that level of qualification but there are great examples of clever and clean design in all that paradigms in all kinds of languages. So if you want to become a better programmer you can do it regardless what language you use.
Though learning a new programming language in unfamiliar paradigm might be eye-opening and mind-bending experience that really helps in becoming a better developer, so I wholly approve! :D
Ah right, yes I totally agree ... yes ultimately the quality of a system is based on the quality of the analysis and design you do - and based on that analysis and design you can decide on the language, tech stack or tools you want to use - whether that's FP, OO or whatever - I'm sure that there are systems or requirements where FP would NOT be the best option, for instance a static website having hardly any or no business logic ... but yes intellectually learning another language or paradigm can be refreshing and an eye opener.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"I found learning Rust MUCH more satisfying than learning Go."
Really? I took a short look at the Rust syntax and got instantly headache :D I came from java to php to javascript to typescript. So i would say i love type safety and object oriented programming,
I didn't say OO, I said FP hehe ;-) although Rust supports OO as well.
Well yes like I said, Rust has a steep learning curve so I can imagine your initial reaction. You need to put in some time and effort to overcome that initial hurdle.
But I can promise you, until they add generics to Golang you will just be doing lots of old fashioned procedural programming there, coding for loops until you see blue in the face. No more map/filter/reduce for you, like you used to be able to use in Javascript ... that was probably my biggest disappointment about Golang.
Would love to see a Jetbrains dedicated IDE for Rust as they did it for Golang with "Goland".
Are you a VSCode user? I think VSCode works with Rust ... I've used Jetbrains products before but I've switched completely to VSCode, except for some occasional (now rare) Java work for which I use Eclipse ...
The Rust plugin for IntelliJ is fantastic, and does some things better than VS Code, such as automatic imports (my favourite feature!). VS Code is very good too however and I do like the progress on rust-analyzer.
That said, the Go plugin for IntelliJ is also really nice too.
P.S. just came across this dev.to article about "String" and "str" in Rust: dev.to/ssivakumar77/rust-string-vs...
Yes, in the beginning this sort of stuff leaves you horribly confused, this is exactly what Rust's infamous "learning curve" is about. I had to read the Rust documentation pages 2 or 3 times before it all clicked, "String" vs "str" was a brain twister initially.
I did the same when I first looked at Go. Coming from C# it seemed very un-intuitive. Somehow Rust makes more sense to me but not sure why really...
To me it feels like Go was cobbled together, Rust seems to be more methodically designed. And what intrigues me is the idea that Rust could be the first "mainstream" language to introduce FP (functional programming) concepts other than the obligatory map/filter/reduce to the masses, although it isn't a pure FP language by any means ... Haskell, Scala, Clojure etc are just too "niche".
I think go was not a language that was "planed" with the ulterior motives to be for the public and has to be "good". In the first, it was planned to solve google internal problems which other langs could not solve in the way that google needs it to bes solved. Compared to Rust i think was more a "planned" language for the public.
Then you're very likely to have very hard time with Rust.
While Rust do promote type safety to very large degree it's different type-safety than Java's or TypeScript's. More akin to Haskell type-safety. It's somewhat hard to wrap one's had around that.
And to large degree Rust does not provide or support OOP. Programming with structs and traits is significantly different from class-and-interface-based OOP, usual designs and patterns do not apply. Even if you do emulate OOP in Rust (which is somewhat awkward but possible) you will have hard time integrating your design with borrow-checker, libraries and frameworks (especially async ones).
It doesn't mean you won't be able to learn Rust or you shouldn't learn Rust. It just means it might require much more time and effort that it seams because you're likely will need to "unlearn" a lot of stuff.
Spot on, I forgot to mention how much Rust reminded me of Haskell ...
Yes, type safety in Rust is more based on abstract/algebraic data types, much like Haskell. It really raises the abstraction level and allows one (if used well) to write succinct and "correct" software (the amount of static analysis the compiler can do to check if your code is 'correct' is amazing).
Compare that with the banal type checks of other languages, whether you're passing in a string or an integer, and you can see that it's on a completely different level. It's elegant and powerful.
And yes, OO (especially the "classic" variant with inheritance and so on) feels indeed like a second class citizen in Rust ...
I'd argue that that's almost a good thing, I haven't used classical conventional inheritance for ages ... programming with interfaces and abstract types (and generics and so on), yes by all means, it's supported, but forget "classic" OO with its emphasis on inheritance.
Well, I'd say "plain old" Abstract Data Types and Algebraic Data Types are about the same level as an "ordinary" Java/C# type-checking (and hence type-safety). The thing is Rust doesn't stop there (not even mentioning Haskell): huge chunk of expressiveness and safety comes from advanced "type-level programming" with generics and some neat (and hard-to-wrap-your-head-around) tricks with (opaque) lifetime parameters. That's indeed far beyond the experience of a "normal" OO-developer as most OO languages lack such facilities. It's similar to what half of Scala developers do with their type-level programming (and for that the other half of Scala developers hates them).
And we still haven't even mentioned two kinds of Rust macros...
OO inheritance just don't play along with all that features. That's why one has to forget about it to fit into the ecosystem of libraries and frameworks. But then you have to learn to program (and think) without inheritance...
Yeah to me the safety and performance benefits one can reap off Rust are totally worth the troubles. But I knew Haskell when I started learning Rust so I knew how to program without OOP (and some type-level "magic" too). For someone coming from Java that might not be worth the trouble.
Though I know some people who learned Rust after just Python or as the first language and totally love it. :D
Amen to all that! Ah yes the macros, that's another powerful one ...
I definitely think it is worth the trouble for a Java programmer to learn that there's another way, expressiveness over verbose "patterns" and a 10 level deep class hierarchy ...
Having studied Haskell before Rust was definitely a good thing because I recognized so much on a conceptual level, seeing those concepts and approached pop up again in a different language was an eye opener.
And I'd argue that Rust is at the same time still more accessible to the "mainstream" programmer than Haskell or Scala.
Yes but one doesn't even need to learn a new language for that! 😂
carlopescio.com/2012/03/life-witho...
One does not need to learn a new language, ah sure, even the newest versions of Java have some FP-style stuff like filter/map/reduce and so on ... it's just that a language like Haskell (or Rust, to a lesser extent) "forces" you more into that style.
Nice article, well yes if your level of design thinking allows you to break away from "controller" style procedural thinking and towards splitting it into objects (or functions, for that matter) with clearly defined responsibilities which "do one thing" then you're also prepared to go the FP way ... that's what you were trying to say or not?
I guess what I'm trying to say is that FP is not a silver bullet. What really matters is clear understanding of the problem and the solution, and good modular and composable design.
Pure FP languages like Haskell do nudge you in that direction first, because pure functions are the most composable thing in our arsenal, second through culture and mechanisms of algebraic design. But all of that takes you only this far. If you really want to go an extra mile and produce even better designs for your programs you have to go beyond and above just language mechanisms and learn and think in more abstract terms.
But at that level particular language and even paradigm doesn't matter that much. With clear understanding of both problem and solution, and good design skills and experience one can produce excellent OO design as well as FP design or even just "structural" design in the sense of good 'ol structural programming.
I'm nowhere near that level of qualification but there are great examples of clever and clean design in all that paradigms in all kinds of languages. So if you want to become a better programmer you can do it regardless what language you use.
Though learning a new programming language in unfamiliar paradigm might be eye-opening and mind-bending experience that really helps in becoming a better developer, so I wholly approve! :D
Ah right, yes I totally agree ... yes ultimately the quality of a system is based on the quality of the analysis and design you do - and based on that analysis and design you can decide on the language, tech stack or tools you want to use - whether that's FP, OO or whatever - I'm sure that there are systems or requirements where FP would NOT be the best option, for instance a static website having hardly any or no business logic ... but yes intellectually learning another language or paradigm can be refreshing and an eye opener.