Slashdot Mirror
Ask Slashdot: Is it Practical To Replace C With Rust?
interval1066 writes: I've heard of rust from various sources around the net for a few years and never paid it much mind, there are so many new languages out now since my early days doing C programming, which what I've stuck to and made me my career. Now I'm heading a project that uses a RoR application to control a large series of sensors and controls in a manufacturing process. Naturally I want to talk to the hardware using a GEM extension written in C, as I've done before.
But another engineer who is not a fan of C (seems few younger engineers are) said he could write the extensions needed easily in Rust. Seems like this is a thing. I took a closer look at rust and it looks to me like another attempt at "C" without pointers, except rust does have a kind of pointer, it appears. I like its ranking on a list of fastest languages, and it seems pretty simple with an initial tool footprint that is quite small.
But what are the trade offs? Another language, and one that few engineers know (much like Vala, which I like very much but has the same small user base). What if I need another engineer to work on the code? I pretty much know what I can expect from C/C++, rust is a huge unknown, what if I run onto a roadblock? The engineer pushing for rust is emphatic, should I bulldoze him or take the plunge?
But another engineer who is not a fan of C (seems few younger engineers are) said he could write the extensions needed easily in Rust. Seems like this is a thing. I took a closer look at rust and it looks to me like another attempt at "C" without pointers, except rust does have a kind of pointer, it appears. I like its ranking on a list of fastest languages, and it seems pretty simple with an initial tool footprint that is quite small.
But what are the trade offs? Another language, and one that few engineers know (much like Vala, which I like very much but has the same small user base). What if I need another engineer to work on the code? I pretty much know what I can expect from C/C++, rust is a huge unknown, what if I run onto a roadblock? The engineer pushing for rust is emphatic, should I bulldoze him or take the plunge?
No one ever got fired for using C.
Im just 2 cubicles away from you, sad i read about it here
You should definitely investigate rust. It's very well designed. It has great support to call into C code and C libraries. It compiles fast. The standard library is much more convenient than C/C++. You have complete memory safety by default, without garbage collection. It has great support for safe multithreading. Over time, your speed will increase because you won't be spending weeks tracking a heisenbug due to memory corruption. There is some learning overhead, but it's worth it.
The biggest issue is that you won't have as big of an ecosystem around rust. You won't find good support for all of the libraries that you might want to use. But those problems aren't insurmountable.
The whole point of C is to be close to the hardware. The hardware has pointers. Why obfuscate?
C is pretty rusty.
Support my political activism on Patreon.
No.
They don't like C because they haven't been taught it properly and instead go for things that are just trying to re-invent the wheel. Tell this guy to STFU, read a copy of the K&R book, and then get back to work using the native language of *nix.
Where I am they chose SpineJS a few years ago, looked like a great language, easy, etc. After a few years, one thing we noticed was the lack of online help when you run into issues. It's just not that widely used. Rust is ranked 49th on Tiobe. Maybe it will be the next best thing, but if it isn't, you'll be stuck with something that has little community support.
... that determines its success or not in a non-nieche segment.
It's the mass of developers that already know it, it's the accumulated code base (both locally and globally) and most importantly: the eco system of tools surrounding it: the compilers, the IDEs, the debuggers, the static/dynamic code analysis, build systems, code generators, mock tools, coverage tools etc.
The new kids on the block have a lot of catching up to do in areas which are not directly language related.
According to wikipedia
https://en.wikipedia.org/wiki/...
"Rust 1.0, the first stable release, was released on May 15, 2015."
So it's five months old.
If you're ever going to be porting it to another platform, then do it in C; there are C compilers available for almost every piece of hardware out there. If you're certain it only needs to run on a single, unchanging platform for the lifetime of the code, then using Rust might be a good idea.
I've abandoned my search for truth; now I'm just looking for some useful delusions.
How many other engineers are going to be expected to know and maintain this? Ones you have on staff? Are you making sure to hire for folks who know Rust? If you have one, is your ops team up to supporting applications written in Rust, familiar with the errors and can handle it? What's the life expectancy of the app? Ever going to need to port it in the future?
Don't forget to factor in the bus factor, when you lose a whole engineer.
Lots of folks end up missing these and you end up with mysterious legacy code the business completely depends on for day to day ops that no one knows or understands. Heck, the other day, I was asked to unlock a windows NT laptop because it was the only known repository of source code for an app that was written over a decade ago - hopefully.
The problem with languages like Rust is that, in addition to addressing important issues in the languages they intend to replace, their designers also go off on an ego-trip, introducing numerous gratuitous syntactic changes, overlooking important features in their predecessor language they didn't understand, and adding features few people actually need. It's possible that a language like Rust will eventually replace C, but I wouldn't put my money on any particular one.
More likely, ideas from Rust will simply make it into a future C release. For example, C may end up having both "safe" and "unsafe" modules, with "safe" modules having more Rust-like semantics and restrictions, and "unsafe" modules supporting full traditional C. Fortran managed such a transition from Fortran-77 to Fortran-90 pretty successfully.
Of course, the other threat to Rust-like languages (as well as future extensions to C) is that whatever they come up with can probably be emulated fairly well in C++ anyway. In fact, looking down the list of Rust features, they are pretty much identical to what C++ offers people already today, and C++ has tons more libraries and compilers, interoperates better with C, and has a huge community of programmers.
Show him this story to indicate your attention to him and use C instead of this new-fangled and still-evolving language anyway.
You'll get better debugging tools, more productivity (since you know C better) and a wider pool of replacement developers should the need arise.
Stupidity is an equal opportunity striker.
Fellow slashdotter Bill Dog
What if I need another engineer to work on the code? ...mI would guess such an engeneer is in the wrong profession, no? Implying he can not cope with Rust, as I understood you.
If we are talking about 'C-like' languages, Rust, D, Java, C#
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
It might be exciting to be a pioneer. But just remember, pioneers sometimes got their wagons burned.
If Rust, the compiler and everything is written in Rust, then I would trust it.
It looks like it's written in big parts in C and C++.
Don't know if it's glue to the rest of the system or that Rust wasn't good enough.
Maybe someone can elaborate?
A lot depends on where and how you want to talk to the hardware. Last time I checked, the kernel (or kernel driver) is the only thing directly writing to memory space mapped to actual hardware and the kernel is the only space where you are catching CPU interrupts. Depending on your platform, the kernel is very likely going to be written in C.
If you are making calls to the kernel drivers from userspace via kernel file interface, ioctls, or some other user-to-kernel API, then you can do that in just about any language that you want.
Maybe I am missing something here.
Someone you trust is one of us.
C may be old, but it's a known entity, you can get plenty of help, it will around in 10 years whereas Rust may not be in use then. The level of C knowledge out there is very high, and should you need help with anything, you can get that help. Not so with Rust.
I constantly fight the "newer is better" crowd at work, and I refuse to budge. If it works, it doesn't need fixing. I dislike change for the sake of change. I refuse, for example, to ever use Windows Server when my Linux machines work. I refuse to use IIS for anything. Compared to nginx, it sucks, and there is nothing to gain by my going there. DItto Python over Perl, when I have stuff that is working under Perl, there is little point in writing it in Python just because it's more modern.
C has warts, but its track record is impressive. I refuse to use something that doesn't have years of a good track record. I need to be able to see the mistakes others have made, their fixes, their ideas, what worked for them. Talk with them if possible. Cannot do this with new stuff.
Most problems you need to solve already have libraries to make it easy. So figure out what your specific problem is, find the right library and language combination that best supports you. If you really care about performance, or some other specific metric, then you might need to use another language, but in general, I'd say use the your favorite language that supports the library you need to achieve your goal. I am currently using C#, javascript, java, C++, shellscript, and a couple other languages. And for each additional feature, I ask myself what is the best tool for the job. There are many ways for different languages to inter-operate, so don't feel that you are confined for just one language. If you think that rust is the best language for a particular task, use it and integrate it with the rest of your code. And if later you decide that another language is better at doing that task, someone can port that one task without having to rewrite your whole stack.
You're writing software for the embedded/industrial market. Someone will have to deal with your pile of poo in 10 years. Will Rust be around in 10 years?
I am struggling to understand how the 'listen backlog size for a TCP socket' could be a feature of a 'C like' language.
Are TCP sockets a fundamental variable type in Rust?
Now I'm heading a project that uses a RoR application...
To quote an old Irishman I knew once, "Oh boy, now yez' inna helluva fix!" :)
But seriously, as for what language to use, that would be one that you know and are familiar with that can do what you need it to do.
In other words, I have no idea because there wasn't really enough specific info in your post for me to take a good guess. Sometimes it's best to work backwards and figure out what tools or languages won't work or aren't suited to the task. That can often help narrow down the list of possible choices, of which there are many.
Just cruising through this digital world at 33 1/3 rpm...
said he could write the extensions needed easily in Rust.
This is probably true but its also aggressively stupid. Ruby, Matz Ruby anyway, is a C program, Rubinius is a C++ program, JRuby is Java. The point of writing Ruby extensions obviously is so that you can leverage the expressive power of the high level interpreted language to get stuff done fast and safely while interfacing whatever it is you need to interface.
Your extensions should not be complex. They really should allocate a little memory to store what needs to be stored, and do some type conversions from Ruby's more primitive types to whatever you interface needs to see and not much more. The thinking should happen in Ruby. If you are writing all kinds of smarts and logic into extension itself you are probably doing it wrong.
So why would you introduce a third language technology to the stack? A C extension should be quick to audit and verify. There are also lots and lots of people familiar with writing ruby extensions in C, few in Rust.
I think Rust is cool but this isn't a Job for Rust. Now implementing RRuby might be!
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
You can't.
I believe that point 3 is what humans call humor.
A Pirate and a Puritan look the same on a balance sheet.
But it's still immature. I wouldn't personally use it for anything important.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
I've heard Rust mentioned a few times so I decided to give the manual a once over to see what it is all about. First impression is that it is a very C like language, except that the memory model is highly regulated. This is good in some ways, it should be nearly impossible to screw up your memory handling with normal code making it safer by default. However, in my brief glance over I can't see any way to allocate a block of memory at runtime, which seems like a significant drawback. The language appears to have "C Programmers Disease" baked into the specification. There is a brief mention in the vector section that they are growable and live on the heap, but doesn't give the syntax for this (nor the syntax to shrink them later!). The docs also make a huge dance around "borrowing" that smells a lot like someone avoiding the dreaded "P word".
It looks like a neat language and I'm willing to give it a shot but I don't see this exploding in popularity anytime soon. There is always the chicken and egg problem with new languages that people don't want to learn it until it has a decent ecosystem, but it won't grow an ecosystem until people start using it.
I read the internet for the articles.
If your code has to suspend itself for a specified period of time, then I would not recommend using Rust. Remember...
Rust never sleeps.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Alternatively you could try using a modern language like Nim that'll give you the same sorts of benefits as Rust, but allows compilation into C so you have the same expectations and performance as you would with C.
The engineer pushing for rust is emphatic, should I bulldoze him or take the plunge?
Take yourself out of the loop. Give it to the engineer. He/she wants to push it. Let him/her. Make the engineer responsible for pushing it, training people, documenting the procedures. Provide room to enable it to happen.
This is how the engineer grows and an engineer and how you grow as a manager, learning to trust the technical opinion of those doing to technical work.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
If your embedded system can't be allowed to crash, you shouldn't be calling malloc(). At least, not once you've booted up and started running the main code.
The embedded software I work with typically has fixed-size arrays allocated at startup, and explicitly handles cases where it doesn't have enough space in the array.
I'm a C hardware programmer and I have no idea what a GEM extension is. I tried to look it up, but it seems to be a term relevant to the Ruby world. So, I'm interested in this thread, but I have no idea what Rust or Gem are.
Non-Linux Penguins ?
Isn't humor supposed to be funny?
A good software engineer should be able to learn a new language in a week or so. If there is something inherent in the language which makes this not possible, e.g. pointers, generics, functional v. procedural, etc., then the software engineer has a gaping hole in his/her knowledge and may need some additional training.
That point aside, I think the discussion here makes the decision C, mostly because of unknown future support for Rust--it is too new to know.
Unless C has an easily describable deficiency which will be covered by a different language, there is no argument here.
An engineer not being willing/able to learn C does not count as a deficiency in C. The same is true for Rust.
Also, if one particular engineer has a strong preference for Rust, for the preference to be an informed decision, the engineer must already be familiar with C, so there should be no problem for that engineer to work in C if the decision goes that way.
Omne ignotum pro magnifico.
No. But std::net in the standard library implements socket support. Presumably it is assumed that the user who needs a socket is going to use this, although of course calls to a C socket libraries could be made if std::net is not sufficiently flexible.
it is not the C language that is the problem, it is the programmers who are using it that are the problem. they are not educated in good programming practices. most people who want to be programmers should never be allowed to become programmers. unfortunately right now lots of narcissistic nerds want to become programmers because they think it's glamorous somehow.
That's more dogmatic than I would accept. I worked on a highly successful system that was full of malloc and free calls, which had to work autonomously for greater than one month submerged in the ocean with only brief surfacings with very low bandwidth RF connection. We had a lot of discipline and applied a lot of care and testing. There were times that in-service instances did crash, reboot, and continue operating, but these were rare. We did forensics to identify what happened and correct the error. I was highly impressed by the operation.
Sounds more like a library issue to me. It is a hallmark of a badly designed library though. Making common things easy is good, making common things easy while making uncommon things impossible is bad.
The default TCP settings may be perfect for 99% of the time. For the remaining 1%, this library is useless.
If you think this may be fine, let me ask you this; have you ever created a program which didn't have atleast one uncommon "1%" thing in it?
A programmer who believes there is no possible way some particular feature would ever need to be used, is a programmer who is too unexperienced and entirely unqualified for his job.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
If it is just for fun, go ahead and play with Rust. You can write C-compatible libraries with it no problem.
If it is for work, however ... Stay with your C.
Rust is nice and everything, but the ecosystem is incredibly small. There are few libraries for it, many are already unmaintained and/or not working. Also the tooling (IDEs, compiler, the cargo build tool, etc.) are fairly immature. I have been looking at it recently with the goal of writing some extension modules for Node.js & .NET, but I went back to regular C for this reason.
I don't know about replacing C but my car certainly seems to think that replacing Fe with rust is a practical thing to do!
C has probably been around longer than you have. Rust probably isn't even a blip on the radar.
Be very wary of embracing immature technology for anything that matters. There are good reasons to do it, but they have to be EXTREMELY good reasons.
Otherwise, even if the tech succeeds, you will be stuck with a code base with immature and deprecated idioms. (Note the very old Java applets you sometimes see on the web that modern versions of Java make nearly impossible to run. So much for "write once run anywhere". There are no such programs written in ANSI C -- unless they involve 3rd party libraries).
You will also have to deal with buggy and immature developer tools and will spend weeks debugging problems that might be resolved with a simple Google search in C.
I have learned this the hard way, unfortunately..
Unless you might want to switch architectures in 2 years, and you don't want to only choose from architectures with good C++ compilers.,
At this point, it's segmented PICs (? maybe) and obscure DSPs without C++ compilers. Just about everything else is supported by GCC a or IAR, both of which compile C++, though IAR is about 5 years out of date in that regard.
In any case if you're that deep embedded, porting is basically a rewrite anyway.
SJW n. One who posts facts.
Let the new engineer write in Rust, and you write a Rust interpreter in C! Both sides win, right?
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
There were times that in-service instances did crash, reboot, and continue operating, but these were rare.
Like I said... if your embedded system can't be allowed to crash.
Clearly, yours could. For other systems, people die when they crash.
1) The Rust project is not controlled by Mozilla. Just look at the copyrights on the rust source code. It's permissive open source, with copyright shared by ~1200 individuals, and Mozilla is not on that list. So this is like spreading FUD by warning people that Linux is controlled by the Linux Foundation (Linus's employer)--hint, it isn't.
2) Mozilla and Oracle are quite different. The Mozilla Foundation is a non-profit, open source organization that exists to provide a public benefit through the creation of open source software. The Mozilla Corporation (employer of some of the Rust developers) is a wholly owned subsidiary that donates all of its profit to the foundation. By contrast, Oracle is known for being one of the most rapaciously greedy software organizations in existence: just consider the Oracle article on Slashdot right now, about how Oracle rips off customers via "traps" in the opaque licencing terms.
3) How can you be sure that Rachael Craig and Nicolette Verlinden are cisgender males? They have female names and photos.
So yeah, I'm pretty sure the parent is a troll, and I fell for the bait.
I have written a truly remarkable program which this sig is too small to contain.
Rust's type system provides protections against some problems that can be quite hard to debug in C.
Between having a programmer that is inexperienced in C writing C code and having a programmer inexperienced in Rust writing Rust code, arguably you might be better off with the latter.
This sounds like a reasonably small component, so what is the worst that could happen? That you would have to rewrite it some day? I'd say go for it.
OK. The answer is very simple. Does Rust buy you something, timing, memory space, cheaper architecture, that C doesn't. What the language buys is critical.
You are producing code for a business that must maintain it going forward, after you are gone and your young enthusiastic engineer has gone off to find a better job. He will.
Realtime control has limits that must be observed. After that the choice of languages is all about long term support. So check the hire boards and see how easy it will be to replace your young enthusiastic engineer. If easy, make sure the next hire or two has Rust under their belt. Or go with C. The next hire will know that language.
What I 'like' is not relevant. I liked bash for most system level scripting, but often python is a better choice. So I use python.
Last. Talk your choice out with the young engineer. Let him know you took him seriously, did your homework. He's follow your lead easier with that example.
No problem. Just tell HR to advertise for someone with ten years of Rust experience.
Looks like you have an engineer that wants to play with Rust on your dime. I've seen a lot of projects try to shoehorn a lot of shitty code in a lot of shitty languages into working because some jackass thought he could be more clever in that language. A few months later he's gone and you're stuck trying to maintain some abomination that tries to do asynchronous IO using threads in Ruby or some other goddamn shit. If you have an elevator shaft on hand, I suggest you acquaint him with the bottom of it, and then get on with your project.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
First is it really an engineer or is it you?
If it is you then should have done enough independent rust projects to be able justify it to management without going on slashdot.
If there is another engineer, ask to see his rust projects. Make sure they are complete and run them under valgrind or similar tool to make sure it's clean.
Keep in mind he may want to do this project in Rust to put it on his resume and find a job where he does Rust full time.
Finally keep this in mind. It's always the young engineers that hate C/C++. It was that way twenty years ago. Why?
Because the young engineers go running to alternatives, and then wind up getting out of programming. Leaving us old timers who don't mind C/C++.
I think this is somebody trolling. FFI and gem are common fanboy words.
We had a similar situation. I won't bring up the language for fear of derailing the conversion but a new engineer had a favorite language and pushed for its use in a new project. Even though no one else on the team knew the language, we believed his tales of faster development time and unicorns and rainbows. Sadly, he left the company a few months and we ended up having to rewrite the stupid thing since once we started looking at what he had done, we realized it would be faster to just rewrite it so it ended up being 6 weeks of wasted time. My recommendation is that if you don't know the language, don't put yourself in the position of having to support it. Bulldoze away!
Glendower:
I can call spirits from the vasty deep.
Hotspur:
Why, so can I, or so can any man;
But will they come when you do call for them?
- Henry IV, Part 1
I suppose that if you want to be close to the hardware and you don't know assembly, C is OK.
"The mind works quicker than you think!"
Rust should add rudimentary support for exceptions
It does have exactly that, rudimentary being the operative word. It has panic(), which doesn't kill the program but does kill a much larger unit of it (a thread actually) then try/except/finally normally controls. Still, it's enough to recover from things like out of memory, because it guarantees the memory will be freed.
The reason it has only rudimentary exceptions is because it can do the by combining it's type inference engine with it's spectacularly powerful macroing system. The type system allows you return arbitrary stuff with the caller really having to know or care (because it has an implicit type generation), and they have provided a "try!" macro in the standard library. So it's all there, just not done in the conventional way.
And in case you are wondering why force you to learn this newfangled way when the old way worked perfectly well - it's because the old way imposed run time over heads on everything. The new way handles it in the type system so overheads disappear at compile time.
It's just a repeat of Rust's memory handling solution, really. In C you handle memory allocation and exceptions manually, with all sorts of nasty consequences like dangling pointers and people dereferencing NULL. Java/C#/YouNameIt eliminates the nasty consequences using run time solutions like gc and exceptions - but they impose a runtime overhead. Rust brings something totally new to the table - the programmer handles it, but the language eliminates all the nasty consequences. So it's fast like C, and safe like Java/C#/YouNameIt. But there is nothing free in this world. Rust's extracts it's pound of programmer flesh with it's borrow checker.
The mainframe failed significantly twice that I knew about when I was in college. IIRC, it was a 370/168. Once was because the water-cooling plumbing leaked all over the motherboard. Another time was because it really didn't like it when they added the fourth megabyte.
The System/34 minicomputer I used for a summer job failed because we were a steel fabricating company, and somebody in the shop was looking for the circuit breaker for his welder, and turned off our power instead. That would be fine, but our data entry clerk had been typing in a list of parts for a bid for six hours, and while the OS had saved where the file started on the disk when she opened it, it wouldn't save where the file ended until she closed it. So I spent about 5 hours on the phone with tech support, walking through the equivalent of fsdb to find all the blocks of the file, store their locations in the inode-equivalent, and write the end-of-file marker on the disk.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Ok, I'm from a different era, but learning pointers wasn't that hard, though it was pretty much the key to C programming. It took a bit of reading library source code to really understand what K&R was saying about them, by seeing how other people used them, but they were amazingly simple and powerful.
The problems with pointers were that you always had to be careful that they were pointing to something appropriate, and that you had to know how big the things they pointed to were (in case they were passed to you from somewhere else or you were passing them _to_ somewhere else), so you still had to always always ALWAYS be careful to either do bounds checking, or put sentinels into the data, as well as checking that a pointer that some function handed you wasn't NULL or some other evil value.
And reading library source code included looking at things like strcpy() doing
while(*feet++ = *bullets++);
and noticing that it was much more efficient not to bother checking that "*bullets" would hit a zero before "*feet" ran out of places to store it, because obviously the person doing the function call would have checked that, so you didn't have to worry about shooting anybody else's feet. And then you have to learn not to do that yourself, which way too many people haven't learned over the last 35 years, which is why almost nobody should be allowed to program in C, even though it's my favorite programming language.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
C++, especially C++14, provides a lot of the nice features of a language like Rust, but will interact well with all of your existing C code. Far, far more engineers understand C++ well, so having somebody else pick up the project will be much less of a burden.
The main drawback of C++ is that it can be a bit of a tricky language to use properly. There are some unfortunate caveats that require some level of expertise to write code that doesn't blow up once it goes beyond moderate complexity (I highly recommend Effective C++ as a good book to read on the subject).
Rust is a language I feel I want to learn it when I saw it the first time after learned C,Java,Python. But as I go on, I found I must "Think in rust" and "Write code in rusty ways" to master it. Then I gave up.
A gem extension is a way to call into C from Ruby. I think that's what the GP is referring to.
"First they came for the slanderers and i said nothing."
Looks to me like the problem with OOM is the standard library. You probably want to avoid the Rust standard library when doing safety critical embedded.
https://users.rust-lang.org/t/...
There's really no reason ever to use C over C++ if you have a C++ compiler available.
What about for something like an OS? Or for tiny little embedded stuff where memory is an issue? (Honestly curious, I'm not current with the latest C++ developments.)
that's actually not that big or long time to been around.
the question I would pose would be.. would it be the same trouble to do it in C. it's just an interface that they're building so the rust code and C code are likely to be the same size and same complexity, heck they will be c externing the stuff for ruby anyways.
so go with C. unless you want a pilot project in the company done with rust..
world was created 5 seconds before this post as it is.
There's a reason we still use C after all these years and one million attempts to replace it with something else. Most of the over-hyped C replacements have gone the way of the Dodo bird. Those who are still around bring something new to the table instead of trying to outdo C in its own domain.
Unless you understand why this is so, don't even think about doing something else.
Assorted stuff I do sometimes: Lemuria.org
There is this large number of younger coders that got into IT not because they love it, but because they thought it was a sure meal-ticket. These people are scared by things like pointer-handling or memory management, because they do not actually understand it. Then they jump on every new thing that comes around just because they hope it will make them appear less incompetent.
The rabid pro-Rust crowd is an excellent example, because the benefits of Rust are not actually that remarkable and, in addition, both language and libraries are immature and hence should never be used in any production project at this time. Yes, they _can_ be used, but that would be hugely unprofessional and bring more problems with it than the language can solve. The one exception is the Rust developers themselves as they have to accept that drawback in order to get experience with their language. Nobody else has to and nobody else should.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
That is simply not true.
I was referring to the tiny micros, not the DSPs, though that's not clear. When fiddling with those tiny micros, the majority of the code is register tweaking to set up the peripherals correctly. None of that's portable to a different manufacturer.
SJW n. One who posts facts.
Ypu're a C programmer, but I gather ypu have stagnated somewhat and have a management function. He is still a programmer at the coal face. Let me hazard a guess that you have stopped working days and studying at night.
You need to be a programmer OR a manager. If you're a programmer, get up to date( a huge job) and name 6 languages he could do the task in and learn at least three of them. Then stay up to date. If you're a manager, He is the professional. Do you trust his choice? Empower him.
My son is a Swift (=Apple OS & IOS) programmer. He programs phones, watches, Apple TVs He can program in about 20 languages. He wrote a multitouch project in Chuck. Ever heard of that?
Yes, the junior devs should beta test compilers/languages on their own time. After 3 to 5 years of free labor by thousands of programmers, most companies will be able to determine if Rust is worthy of production. It's called free testing.
.. and so does C ...
If you're going to call in to C libraries, then why use another language?
"Consensus" in science is _always_ a political construct.
Rust can give you precise control of memory layout, and supports inline assembly as well as calling C functions. So it ought to have everything you need for controlling hardware.
Rust the language is young but stable (code you write now should continue to work in newer releases). And it sounds like this is a relatively small project that shouldn't need a ton of 3rd-party libraries, so the maturity of the library ecosystem isn't as big a concern.
My experience was that Rust took a little getting used to but it's a pretty nice language. In addition to the safety guarantees, it gives you a lot of expressiveness compared to C++ and (especially) C -- algebraic datatypes, very nice iterators, lambdas, generics, etc. And I expect that any well-rounded developer with a good grasp of C could learn Rust pretty quickly.
Right. In my career I've been taught one language (Pascal) and been tossed face-first into 4 other languages: C/C++, C#, Lisp, and Python. Language learning happens in phases:
- I can learn the syntax, reserved words, flow control, and basic structure of a language in 3-4 days. At that point I'd be able to take a small block of simple code and figure out what it's doing. I could write very simple programs to do pretty pointless things.
- Given another week or so I could learn enough of the support libraries to have some exposure to basic things like file access, network APIs, thread and process creation, database access, etc to understand what more general code is supposed to be doing. So about two weeks in I could start contributing to real work by finding and patching certain types of bugs, adding simple feature extensions, or building useful test cases.
- Given another 2-4 weeks of work I might be knowledgeable enough to create moderately complex subsystems, debug most single factor bugs, or begin commenting on any architectural problems.
- I won't know enough to make architectural changes for another month or more.
In the end, I wouldn't trust myself to make big changes on less than three months familiarity with a language. With some projects I'd want that much time just on that project's codebase, *after* the three months getting familiar with the language. At that point I've probably learned enough to know what it is I don't yet understand.
because we WANT our programmers to eventually not understand how a microprocessor works.
We need to breed a dumber programmer so s/he can write buggy code, fast.
Make it idiot-proof because eventually the bar will be so low, only idiots will be needed to do the job.
If we're lucky, this will cause a resurgence in VisualBasic.
I don't know the meaning of the word 'don't' - J
My C got wet and it turned to Rust.
I would be more worried about the fact that the team also has one gorilla, a werewolf, something that looks like a walking dildo, a female hentai character that seems to be getting some action from behind off-screen, a kitten, a cat and a penguin.
On the other hand, Yehuda Katz is there. He is a very major Ruby on Rails contributor. As a dedicated RoR fan that worries me because if he jumped ship RoR lost a very valuable contributor.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
Sounds like a micro-aggression to me.
That's more dogmatic than I would accept.
Then you're completely unqualified to work on avionics code under DO-178B. Freeing memory is strictly forbidden. If you have to free memory, you're doing something wrong.
It's always the young engineers that hate C/C++. It was that way twenty years ago. Why?
WTF are you talking about? 20 years ago I was still in school, and everything was C or C++ (or assembly). We didn't have any alternatives back then, except Java, which at the time was still very new. Of course, there were a bunch of academic languages and older languages: FORTRAN, COBOL, Lisp, Forth, Pascal etc., but most of those are older than C; in fact, in 1995, C++ was a relatively new language.
You know what?
It helps if you know what you are talking about.
1995 C++ was not "relatively new". The ARM was published in 1990. Meyers and Cope were both published in 1992. I don't know about your potentially inferior schools, but I saw tons of C++ programmers around.
And there were very many alternatives around. Start with the two you mentioned. Lisp and Pascal. There were three commercial Lisps ( which cost a lot ) out there: Allegro CL, Corman Lisp ( Ok Windows only and very cheap ), I can't remember the name of the third. Pascal-- ever heard of TurboPascal or Delphi? Ok not portable but no one cared. And guess what? A lot of the young engineers were screaming "Let's do it in Lisp" or "Let's do it in Delphi".
If you were doing, GUI's there was PowerBuilder and VB. Again I heard a lot of engineers say "Let's do it in PowerBuider or VB."
There were also Smalltalk (at least two commercial compilers ), Eiffel ( again at least two commercial compilers ), Dylan ( ditto ) and Self. Finally there was Ada which was mandated for all military applications without special dispensation.
What's more Java at that time was more mature then Rust is now.
So there were plenty of choices and the young engineers were always choosing them. Maybe if you had paid attention to the real world when you were a student.
Every language under the sun has a foreign function interface for the purpose of calling into C libraries. Does the existence of an FFI from Python obviate the need for Python? Does JNI obviate the need for Java?