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 - "yes yes most advanced"
-
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 -
I just got a bit into OpenCV and I am completely exited. I built a little ball tracker (Yes I know that the cross is on the other side, it's inverted so the cross is at the same position as the ball in front of the camera) and although it is not the most advanced project I think it's kinda cool.9
-
I saw this in a project proposal of a friend's job:
we build native apps using the most advanced mobile application
development platform on the market: React Native
I feel sorry for him :\3 -
TL;DR; do your best all you like, strive to be the #1 if you want to, but do not expect to be appreciated for walking an extra mile of excellence. You can get burned for that.
They say verbalising it makes it less painful. So I guess I'll try to do just that. Because it still hurts, even though it happened many years ago.
I was about to finish college. As usual, the last year we have to prepare a project and demonstrate it at the end of the year. I worked. I worked hard. Many sleepless nights, many nerves burned. I was making an android app - StudentBuddy. It was supposed to alleviate students' organizational problems: finding the right building (city plans, maps, bus schedules and options/suggestions), the right auditorium (I used pictures of building evac plans with classes indexed on them; drawing the red line as the path to go to find the right room), having the schedule in-app, notifications, push-notifications (e.g. teacher posts "will be 15 minutes late" or "15:30 moved to aud. 326"), homework, etc. Looots of info, loooots of features. Definitely lots of time spent and heaps of new info learned along the way.
The architecture was simple. It was a server-side REST webapp and an Android app as a client. Plenty of entities, as the system had to cover a broad spectrum of features. Consequently, I had to spin up a large number of webmethods, implement them, write clients for them and keep them in-sync. Eventually, I decided to build an annotation processor that generates webmethods and clients automatically - I just had to write a template and define what I want generated. That worked PERFECTLY.
In the end, I spun up and implemented hundreds of webmethods. Most of them were used in the Android app (client) - to access and upsert entities, transition states, etc. Some of them I left as TBD for the future - for when the app gets the ADMIN module created. I still used those webmethods to populate the DB.
The day came when I had to demonstrate my creation. As always, there was a commission: some high-level folks from the college, some guests from businesses.
My turn to speak. Everything went great, as reversed. I present the problem, demonstrate the app, demonstrate the notifications, plans, etc. Then I describe at high level what the implementation is like and future development plans. They ask me questions - I answer them all.
I was sure I was going to get a 10 - the highest score. This was by far the most advanced project of all presented that day!
Other people do their demos. I wait to the end patiently to hear the results. Commission leaves the room. 10 minutes later someone comes in and calls my name. She walks me to the room where the judgement is made. Uh-oh, what could've possibly gone wrong...?
The leader is reading through my project's docs and I don't like the look on his face. He opens the last 7 pages where all the webmethods are listed, points them to me and asks:
LEAD: What is this??? Are all of these implemented? Are they all being used in the app?
ME: Yes, I have implemented all of them. Most of them are used in the app, others are there for future development - for when the ADMIN module is created
LEAD: But why are there so many of them? You can't possibly need them all!
ME: The scope of the application is huge. There are lots of entities, and more than half of the methods are but extended CRUD calls
LEAD: But there are so many of them! And you say you are not using them in your app
ME: Yes, I was using them manually to perform admin tasks, like creating all the entities with all the relations in order to populate the DB (FTR: it was perfectly OK to not have the app completed 100%. We were encouraged to build an MVP and have plans for future development)
LEAD: <shakes his head in disapproval>
LEAD: Okay, That will be all. you can return to the auditorium
In the end, I was not given the highest score, while some other, less advanced projects, were. I was so upset and confused I could not force myself to ask WHY.
I still carry this sore with me and it still hurts to remember. Also, I have learned a painful life lesson: do your best all you like, strive to be the #1 if you want to, but do not expect to be appreciated for walking an extra mile of excellence. You can get burned for that.