Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "project vs implementation"
-
I propose that the study of Rust and therefore the application of said programming language and all of the technology that compromises it should be made because the language is actually really fucking good. Reading and studying how it manages to manipulate and otherwise use memory without a garbage collector is something to be admired, illuminating in its own accord.
BUT going for it because it is a "beTter C++" should not constitute a basis for it's study.
Let me expand through anecdotal evidence, which is really not to be taken seriously, but at the same time what I am using for my reasoning behind this, please feel free to correct me if I am wrong, for I am a software engineer yes, I do have academic training through a B.S in Computer Science yes, BUT my professional life has been solely dedicated to web development, which admittedly I do not go on about technical details of it with you all because: I am not allowed to(1) and (2)it is better for me to bitch and shit over other petty development related details.
Anecdotal and otherwise non statistically supported evidence: I have seen many motherfuckers doing shit in both C and C++ that ADMIT not covering their mistakes through the use of a debugger. Mostly because (A) using a debugger and proper IDE is for pendejos and debugging is for putos GDB is too hard and the VS IDE is waaaaaa "I onlLy NeeD Vim" and (B) "If an error would have registered then it would not have compiled no?", thus giving me the idea that the most common occurrences of issues through the use of the C father/son languages come from user error, non formal training in the language and a nice cusp of "fuck it it runs" while leaving all sorts of issues that come from manipulating the realm of the Gods "memory".
EVERY manual, book, coming all the way back to the K&C book talks about memory and the way in which developers of these 2 languages are able to manipulate and work on it. EVERY new standard of the ISO implementation of these languages deals, through community effort or standard documentation about the new items excised through features concerning MODERN (meaning, no, the shit you learned 20 years ago won't fucking cut it) will not cut it.
THUS if your ass is not constantly checking what the scalpel of electrical/circuitry/computational representation of algorithms CONDONES in what you are doing then YOU are the fucking problem.
Rust is thus no different from the original ideas of the developers behind Go when stating that their developers are not efficient enough to deal with X language, Rust protects you, because it knows that you are a fucking moron, so the compiler, advanced, and well made as it is, will give you warnings of your own idiotic tendencies, which would not have been required have you not been.....well....a fucking idiot.
Rust is a good language, but I feel one that came out from the necessity of people writing system level software as a bunch of fucking morons.
This speaks a lot more of our academic endeavors and current documentation than anything else. But to me DEALING with the idea of adapting Rust as a better C++ should come from a different point of view.
Do I agree with Linus's point of view of C++? fuck no, I do not, he is a kernel engineer, a damn good one at that regardless of what Dr. Tanenbaum believes(ed) but not everyone writes kernels, and sometimes that everyone requires OOP and additions to the language that they use. Else I would be a fucking moron for dabbling in the dictionary of languages that I use professionally.
BUT in terms of C++ being unsafe and unsecured and a horrible alternative to Rust I personaly do not believe so. I see it as a powerful white canvas, in which you are able to paint software to the best of your ability WHICH then requires thorough scrutiny from the entire team. NOT a quick replacement for something that protects your from your own stupidity BY impending the use of what are otherwise unknown "safe" features.
To be clear: I am not diminishing Rust as the powerhouse of a language that it is, myself I am quite invested in the language. But instead do not feel the reason/need before articles claiming it as the C++ killer.
I am currently heavily invested in C++ since I am trying a lot of different things for a lot of projects, and have been able to discern multiple pain points and unsafe features. Mainly the reason for this is documentation (your mother knows C++) and tooling, ide support, debugging operations, plethora of resources come from it and I have been able to push out to my secret project a lot of good dealings. WHICH I will eventually replicate with Rust to see the main differences.
Online articles stating that one will delimit or otherwise kill the other is well....wrong to me. And not the proper approach.
Anyways, I like big tits and small waists.14 -
Old one but popped into my mind today,
during 3rd year project, when all computer science students were mixed together,
I wrote the design / implementation doc
had a lot of acronyms as it was a technical course
referenced VS IDE
Idiot on team came along and decided to expand these acronyms
IDE became Intercompany Data Exchange
I lost the plot as he submitted it before i proof read the thing!
*face palm -
I fucking hate spring boot. I can go unwind and nobody would hear this but boy, does it suck. Every single thing about it is a pita. I spend 98% of time I should have used for feature implementation in JAVA, struggling and battling MUNDANE functionality of the framework that ought to be nobrainers
Today started out with a project I inherited. I don't even know whether to blame its original author but he installed a couple of funny libraries for logging. The spring app doesn't build yet gradle build completes successfully. No errors are logged to the terminal, just reams and bundles of json. WHY IS THE APP NOT BUILDING??? You want me wrangling json through that pinhole console window?
I struggle with the yml settings, none works. Eventually get rid of the package (hint, it wasn't the slf4j one). I'm able to debug app not starting now, but now live reload doesn't work
I copy configs from a previous project where it worked into this. Nope, doesn't budge. Eventually enable an ide setting but now server restarts twice after file changes. The implication is that request argument annotation no longer works! So the server just restarts and has amnesia about argument type resolution
I've been sitting here for hours, without implementing a single new feature. Everything is a painstaking, avoidable aggravation VS the "framework". Never seen anything as horrendous. No line of java code yet. I just want to send a request, retrieve parameters and verify live reload is "up and running". You'd think something as low level as this shouldn't take more than two minutes. Alas, welcome to the incredible world of spring development6 -
I Used to scribble my thoughts on paper. It's haphazard yet handy. And even though I can't make corrections without crossing out or drawing arrows to transfer the reader to continuation of the thought on another page, I have this liberty to express myself and glance at a panoramic view before putting them in their final resting place –soft copy
Maybe my thought process became more efficient but I no longer need to flesh things out with ink. Database designs, implementation logic. Everything goes to a special file I create on every project for odds and ends
Until today
I have something to think about. I will miss connecting the dots if they appear in fancy fonts. I need to gradually build upon each outline, pursuing it in an exploratory manner until its possibilities are exhausted. I will draw a conclusion from their character arcs
For some reason, I see parallels between this scenario and sql vs nosql. This is one of those extreme cases where structured data storage is not sufficient. I sincerely doubt nosql should be used as a main database, but instead an intermediary for an aggregator to treat each row/record as a unique blob, extract necessary information into a sql for the actual system to work with
Sql is more sane and recommended for when you know the exact end goal but need help arriving there. Today, I'm confused and need to weigh options. I need to actually cross things out, not press the back button. It's a bit of a stretch but if this were data, it feels like what nosql would excel at2 -
OK. We've got this tiny little pet project of mine (work related)…
I rescued it from the git archive, simply put: someone hot glued an elasticsearch scroll + document processor (processing) together.
After a lot of refactoring, I had an simple, much improved (non-parallel) Akka Worker System without an Akka topology / hierarchy.
I left out the hierarchy at first, because I didn't know Akka at all.
I've worked with a lot of process workflows, and some systems that come very close to IPC, so I wasn't completely in the dark.
Topology requires knowledge / creation of a state machine / process workflow. And at that point of time I just had... Garbage. Partially working garbage.
I finished yesterday the rewrite into several actors... Compared to before, there are 8 actors vs 2... And round about 20 classes more. Mostly since I rewrote the Receive Methods of Akka as Command DTOs... And a lot of functions needed to be seperated into layers (which where non existent before)
Since that felt more natural than the previous chaos of passing strings or other primitive types around, or in the worst case just object....
(Yes: Previously an Actor was essentially a class with one or more functions "doEverything" and maybe a few additional functions which did everything - from Rest Client to Processing)).
Then I draw the actual state machine based on everything I've written in the last weeks and thought about how to create the actual topology and where / how parallelizing might make sense.
Innocent me stumbled in the Akka Docs on Akka Typed... (Didn't know it existed, since I'm very new to Java and Akka).
Hm, that sounds an a lot like what I did. In an different way, yes. But not so different that it might be VERY hard to port to.... And I need to change (for implementation of hierarchy) a few classes....
[I should have known at this stage that my curiosity would get the best of me, but yeah. Curiosity killed the cat.]
Actually the documentation is not bad. It's just that upon reading the first more complex examples, my brain decided to go into panic state.
The've essentially combined all classes in one class in all source code examples [which makes sense more sense later], where it is fscking hard for an chaotic brain like mine to extract information....
https://doc.akka.io/docs/akka/...
The thing is: It's not hard to understand… actually very simple.
It was just my brain throwing an fuck you tantrum.
So I've opened more examples in other tabs and cross referenced what happened there and why...
Few frustrated hours later I got that part.... And the part why it's called Akka Typed. It was pretty simple....
Open the gates of hell, bloody satan that was too easy for fucks sake.
Nooooow.... I just need to port my stuff to Akka Typed.
Cause. Challenge accepted, bitch - eh brain. You throw tantrum, you work overtime. -.-
I just cannot decide wether to go FP or OOP.
Now... I'm curious wether FP is that hard... Hadn't dealt with it at large before.
Can someone please stop me... I'm far too curious again. -.- *cries*6