|
Our brains get full. Would be nice to have selective memory erasure to free up some of it for other uses.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
|
that's too obvious.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Not enough anti-oxidants?
|
|
|
|
|
It's not your age, and it's not you in any other way. It's Rust. I read through some of the documentation once and didn't care for it. I decided to give it a second chance. That was enough to convince me that it was bizarre and that I wasn't interested. Another language whose designers either think they're your parents or have PTSD from bad pointer experiences.
|
|
|
|
|
why do you need to pick RUST?
diligent hands rule....
|
|
|
|
|
None of this is about need. And I'm pretty sure Rust isn't an acronym?
To err is human. Fortune favors the monsters.
|
|
|
|
|
Seems to me like you're likely already rather intimate with hardware and how things work in computers.
From a quick look at the code-samples, it felt like stepping back into about 1993 and Turbo Pascal.
Pointers are trivial. Memory safety and leaks aren't exactly the hardest things to keep track of either.
Certainly not the view held universally, but reasonably common all the same.
It feels like the language introduces unnecessary complexity in pursuit of the mission to dumb-it-down.
EXACTLY the same mistake so many HTML/JS frameworks force upon their users.
println!("Nah thanks. Keep yer oxidised rubbish Mozilla");
Oh... and here's yer bang back too ( ! )
FFS - it's an exclamation mark ya willies.
Rant aside - thanks for the impetus to finally have a look at it. That was 20 minutes of my life I'll sadly never get back. 
|
|
|
|
|
I'm glad I'm not the only one that feels that way!
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: I read somewhere that our intelligence and mental flexibility peaks in our late 20s?
Arthur C. Clarke's First Law:: When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
Clarke went on to define "elderly": In Mathematics and the physical sciences, anyone over 30. In biology, senile decay is at times postponed to the 40s.
Join the club... 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I thought witches used a lot of greasy chicken in their rituals. It's hard to rust when when greasy. Start using lean chicken, but your casting skill will suffer for it.
|
|
|
|
|
Too many letters in the name?
Surely, the shorter the name, the better the language.
|
|
|
|
|
I've been considering learning Rust for the challenge of it, but you know, there are plenty of challenges to choose from, so maybe I'll skip this one. It would only be an ego-boost for me personally, and from the sound of this 'review', perhaps not 
|
|
|
|
|
For me, I learn new languages by reading as much source code as I can.
This allows my brain to pickup the constructs/flows pretty quickly.
This works really well... UNTIL you get to heavily "decorated" languages.
.NET web code shocked my system.
Then some of it is about the language helping to change programming detail location.
I have some old code in my favorite language, where I was practicing some of this. It's
really cool. Everything is based on a base class that knows how to "process" something.
Then I inherited from that with 2-3 implementations based on filetypes, expectations.
One master controller loop that dealt with setting orders.
Every process was nice and tight/small. To this day, it's the hardest code for me to modify.
I have re-immerse myself in the code.
Unfortunately, I don't know RUST but my initial take is that the language contains a paradigm shift.
Either in Decorations for some level of control, or conceptually to organize the code. (If that makes sense).
Once you wrap your arms around it (like the transition to C++, which was BRUTAL because of all of these Object Rules),
things will likely fall in place.
But I still think it's easiest to start by reading someone elses code. And modify it! Get dirty.
Also, one other commenter mentioned getting older (or more mature), your definition of "knowing" something changes, and gets a lot of depth. When we were kids, writing 2 C++ programs meant we KNEW C++ (ROTFLMAO). Most people came from C, and could write C code in C++... A huge difference, and we "know" that at a deeper level now!
|
|
|
|
|
Kirk 10389821 wrote: Also, one other commenter mentioned getting older (or more mature), your definition of "knowing" something changes, and gets a lot of depth. When we were kids, writing 2 C++ programs meant we KNEW C++ (ROTFLMAO). Most people came from C, and could write C code in C++... A huge difference, and we "know" that at a deeper level now!
I think my problem might be a bit of imposter syndrome. Even now I don't think I can code very well in C++, if I'm being honest with myself. I fake my confidence, because I figure maybe I can fake it til I make it.
That said, intellectually I know I underestimate myself when I assess my abilities.
And most of my C++ code could not be written in C very readily. I use a lot of "advanced" C++ features like metaprogramming.
To err is human. Fortune favors the monsters.
modified 11-Jul-22 10:32am.
|
|
|
|
|
(I think you meant C vs. C++ in that last sentence in the 2nd reference of the 3).
Wow, honesty in assessing your abilities. That's awesome!
So, push through it. You will pick it up. At the end of the day, you will either make it run correctly, or you will fix it. Support that confidence.
For me, having over 40 programming languages (with over 5 variations of BASIC, 3-4 assembly) under my belt.
I know the KEY Skill is to solve the right problem first. The choice of language after that is syntactical.
Most people fail to properly solve the problem. Or shoehorn it into a construct they understand.
Language portion is well after I have solved the bigger problem. (And yes, sometimes the constructs used in the language and framework chosen are part of the problem, LOL)
Thanks for sharing... I enjoy the things you bring to the surface!
|
|
|
|
|
I'm 69.5 and I took on Rust this year. I approached it as a 30+ year C/C++/C# programmer. It does have quite the learning curve. Repetition was vital for me in my journey. I watched endless YouTube videos by different creators on a single aspect of Rust, say "borrowing," to understand it. I also used Manning courses for some. Some creators are better than others, of course. "Let's Get Rusty" on YouTube was my go-to for learning the rust-lang book in a structured fashion.
Slowly, it jelled. Five months in, I can use the language, but I'm nowhere near an expert. The r/rust community on Reddit has also been great for helping me get unstuck from some of the idioms of the language.
It was a lot of hours, but thinking back, learning C was as difficult. I'm glad I invested the time and suffered through the difficulties. It's a splendid language.
|
|
|
|
|
Sounds like me.
Retired C++ developer, but I like to keep fiddling with code.
Gave up on Rust (too hard) and have focused on Go for (windows) stuff and PHP for web stuff.
I like Go because of the nice ecosystem, c-style syntax, and cool concurrency.
|
|
|
|
|
Rust 'be hard'. Most of the syntax is similar to other languages like c, c++, c#, java, etc...
However, most modern languages have been built around hiding and managing memory for you (ex: c#). The thinking is if you don't have to worry about memory management then you can spend more time on the logic. This generally works pretty well. However, Rust was designed to be a "System's language" (i.e. something you could write an OS, or driver or other system component in ... or a web browser, which is basically a self-contained OS these days). While having a familiar syntax, Rust thwacks you in the head and sometimes kicks you in the ...um... "lower mid-section" when it comes to memory management. For years we've been training ourselves to ignore memory management, but Rust put's it front and center in an almost assembly level way. The paradigm is flipped. Get the memory management right and the logic will follow. It's less that you are getting old and more that you've been indoctrinated into ignoring memory management. It's like changing a door that has been 'push' for 20 years to a 'pull' door. Consider your 'container system strangeness'. What are you 'containing'? In Rust you really only have references to memory, and you have to be perpetually aware of the ownership of those references. In C# I can conceptually 'add an object to a List'. I can't really do that in Rust. First no objects, second I can only really transfer ownership or copy memory, sure there's syntax to make it look otherwise, but that veneer of syntax is very thin. ... at least that's been my experience
|
|
|
|
|
I primarily code embedded with C++.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I do believe it is a function of age, but not in the sense that your brain atrophies, but more in a sense that the older you get the more you realize the relative value of things. I recall when I was much younger, I would do stuff simply because I though it fun or interesting. As I get older I understand that there are tradeoffs. Do I enjoy a
You will learn Rust when you have a need to do so. Casually picking up a new language serves no purpose, and interest alone cannot carry the day. There has to be a purpose and intent, then you will learn it, otherwise you will not. I bet that if there was a wicked problem that captures your imagination, and you had to use Rust, you would learn it, and most probably enjoy learning it.
|
|
|
|
|
Rust does have a number of facets that aren't like the C++ equivalents. I did last year's advent of code in Rust and the main thing I struggled with was how iterators were used - unlike C++, where (before C++20) you use STL algorithms, you chain method invocations, layering iterator transforms.
The other things that are unfamiliar are traits (a bit like interfaces), which I knew from Haskell, where they're called type classes, and Rust enums, which are just 'sum types'. Also, everything in Rust is an expression - no statements. Seems weird, but can be very handy (e.g. returning values from if or match (think switch) expressions grows on you, an then you go back to C++ and wonder why you can't do it there...).
The memory management (well, lifetime) thing can be a pain, especially if you've got references flying round. But most of the time, you don't see it.
I wrote a little duplicate file finder in Rust, as something to give me experience with it.
As for tooling - either IntelliJ or CLion with Jetbrains Rust plugin or VSCode with the rust-analyzer extension. I use the second one - it gives me pretty much as good a VSCode experience as I get with C++.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Stuart Dootson wrote: Also, everything in Rust is an expression - no statements
Rust is a functional (vs imperative) language?
Am I reading you right?
Gosh I didn't even realize that.
To err is human. Fortune favors the monsters.
|
|
|
|
|
It has functional aspects, but it's still very much an imperative language. The way that it melds being an expression language with being an imperative one is that the semicolon separates and sequences expressions, much like the comma does in C.
What can make it useful, though, is cases like those Rust making bindings immutable by default. For example, in C++, I might write
int x;
switch(some_value) {
case 0:
x = 15;
break;
case 2:
x = 29;
break;
default:
x = some_function(some_value);
break;
}
I need to declare the variable separately from its initialisation, and then rely on it being mutable to do the initialisation (although I could do it all in one with an immediately invoked lambda expression...).
In Rust, this becomes:
let x =
match some_value {
0 => 15,
2 => 29,
v => some_function(v),
};
Rust requires all bindings to be initialised, so for complex cases, getting a value out of something like a match can be very useful.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Rust might be best described as taking the traditional coding paradigm and turning it on its head.
... then chucking it into a blender and setting it on puree.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
