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.
Just learn some practical Rust, then make your choice. I mean, it's hardly difficult. The Rust community is a great one, and the language itself can (when utilized properly) save you a lot of development effort. It has for me in my smaller projects, and my confidence in it is growing on an almost daily basis. In fact if more of my team would get the sticks out of their hindquarters and learn a more modern language, we wouldn't have to bitch so much about C. Someone has to buck that trend or you'll just be a bunch of old farts stuck in perpetual snark limbo, while people who know better languages will enjoy their time more.
If there is lots of concurrency going on in the component try Rust, since it was built from the group up with that in mind. If not stick with the tried and true C.
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.
Announcing my new language, Crust.
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.
"Is it Practical To Replace Rust With C?"
Here is a list of reasons not to use Rust:
1) It is controlled by a single entity (Mozilla). People will scream about that, but it is true. Just like Java is owned by Oracle, C# is Microsoft, Rust is one corporate entity.
2) There is a "Legal" link on the Rust main website. That is never a good sign, and is related to #1.
3) If you look at the pictures of the Rust team members you will see that they are all cisgender white males. And we all know what THAT means.
Stick with C/C++. There are ZERO legal issues involved and isn't controlled by a corporate entity governed exclusively by cisgender white males.
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.
I tried going head first into using Rust, and it has a lot of strong things going for it. It's built on a solid LLVM foundation and it's community is really friendly and helpful. The problem I had was that the abstractions provided by rust often made to many assumptions on behalf of the programmer, sometimes entirely hiding features that I've come to expect, like being able to set the listen backlog size for a TCP socket. This is something Go also hides from the programmer but more mature languages like Python expose these parameters to tweak as you'd like. I'm averse to any abstractions that take away power from the developer or require strange workarounds.
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?
As long as you gather your needed resources, know how to craft any additional tools you may need, you should do just fine. If you are a pro however, all you need is a Rock!
You can't catch out-of-memory errors in Rust, which presumably is important in long-running embedded projects, and with possibly constrained memory.
Of course, Rust developers will tell you that that's not true; that only the standard library panics on OOM; that the language itself allows writing code which handles OOM.
The problem with that claim is that you can't use any boxed types if you want to handle OOM. Because Rust doesn't have pointers, and without boxed types and the Rust analyzer optimizing away copy-by-value, you're stuck using mutable references everywhere.
But Rust was _intentionally_ designed to make using mutable references _very_ tedious. So, yes, you can handle OOM in Rust, if you don't actually care about writing any idiomatic Rust code at all And because mutable references are so constrained, you might even find yourself resorting to using the unsafe code mode of Rust the majority of the time, which pretty much defeats the entire purpose of using Rust.
Rust was designed by GUI and game developers. GUIs and games will happily crash or, at best, exit when they run out of resources. (At worse they may play games with emergency memory pools, which is a bad idea without compiler help because it's difficult to test and make robust.) But in the embedded and server side you can't always be so carefree about those things, especially when you're not implementing a stateless service on a huge cluster. Crashing a thread that's juggling thousands of sessions just because the thousandth-and-one session happened to trigger OOM (maybe because of malicious input parameters, or because the process was in a sandbox with a constrained memory allotment) isn't how you write quality code. You could implement hacks, like keeping a watchdog thread around to resume event handling, but that's not _composable_; you can't hide hacks like that behind an interface.
That said, if handling OOM doesn't matter to you, then Rust is definitely a solid choice.
Rust should add rudimentary support for exceptions, something like Go's defer/panic, to be able to catch a stack unwind.
FWIW, the Lua scripting language might also be an option. It's better than Python in terms of language abstractions--true coroutines, full lexical closures--and faster to boot. It integrates with C better than any other scripting language around, either embedded within C or driving C code. And it actually permits catching and recovering from OOM, both from Lua script and from C code. (OOM is just an exception that can be caught anywhere.) The mainline implementation might even work for you out-of-the-box. If not there are quality forks (like eLua) geared toward smaller embedded systems, down to environments with just 32 kilobytes of memory and no FPU.
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...
Tell your young punk to learn C and like it. If he can't work with C, fire him and find someone who can.
Why bother with anything other than C (or C++)? I've written lots of gems in both C and C++ and they're typically on the short side and usually only contain just enough to talk to whatever library you need to. It's not worth bothering with another language.
You can also consider using FFI but that also has its pros and cons.
If your junior dev wants to play with Rust on a project, he should do it on his own time, not the company's. A language that's just went to 1.0 this year has no business being used in a production environment. Junior devs never understand that.
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
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 can't believe, in a world being transformed by various GO-based projects, that Rust is the question which surfaces.
DevOps solves all problems!
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.
A replacement for C without pointers, for stupid people? That'll work well. How does one use memory mapped registers and write device drivers without them? C is hear to stay. I only wish more effort was made to make C and C++ completely upwardly compatible.
Obviously your not a real engineer if you can't program in C
It's part of the rugged manifesto that I have on the wall of my cube:
"my code will be used in ways i cannot anticipate, in ways it was not designed, and for longer than it was ever intended."
Does it still seem like a good idea?
You want to use C because you're familiar with C. He wants to use Rust because he's familiar with Rust. You should compromise and use Scheme instead.
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.
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.
Unless you might want to switch architectures in 2 years, and you don't want to only choose from architectures with good C++ compilers.
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..
Sounds like the C extensions already exist and are proven to work. Rewriting them in ANY language is just making work for yourselves.
Cool story bro. Here.. hold my beer and watch this... *CRASH*
This is an attempt, with some credible gripes about what Rust is not doing correctly in this respect. Rust's type system is too tight for sections of code that are guaranteed to be single threaded.
https://web.eecs.umich.edu/~prabal/pubs/papers/levy15ownership.pdf
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!
I've heard the comments that C/C++ have compilers and toolchains for every architecture out there; however when you factor in Rust's support for the Ono-Sendax 7 I think its a win.
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++.
Isn't that like the cart pulling the horse?
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!"
I don't know about you, but I prefer breathing in C and breathing out CO2. Somehow I detest the idea of breathing in Fe2O3
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
A bad idea, but what the hell, you might get to move on before it bites you. After all, it's other people's money and you can take the blame for this engineer, who will be on to something else as soon as it's time to debug some old rust code.
Wait until it makes the Tiobe top 20.
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.
Rust is robust, but Nim goes many step beyond
http://nim-lang.org/
https://en.wikipedia.org/wiki/...
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.
This is so wrong. There are plenty of people using C/C++ who could be considered experts, yet still run up against corner cases in the language all the time. What you learn in a week might be enough for prototyping or exploring ideas, but it's not enough for production - not by a long shot.
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?
.. 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.
every time the paper jammed in the teletype
with younger programmers. With each new generation of coders there are new fads, presumably driven by professors pushing their own preferences as "best practices" to the young who do not seem to know when to ask questions. Each new language that comes along and each new set of ideas for what's best takes us further away from how the hardware actually works, adding the need for more memory and more speed to perform the same task.
I noted this initially when "GOTO" (in any language) was declared EVIL as "structured programming" became all the rage. The microprocessors themselves use GOTO (aka JMP or Bcc, etc) all over the place and would not function without it. Structured programming traded code efficiency for guard-rails-by-practice benefits for less competent coders. Competent coders wrote perfectly good code full of GOTO-equivalent opcodes (google: Apollo Guidance Computer, etc)
Now the EVIL enemy to be destroyed is the unmanaged pointer. The microprocessors themselves, of course, use such pointers as part of their basic functions. As with GOTO, this adds extra code both at build time and run time to protect against incompetent/lazy coders while actually not improving the performance of the system itself at all. These are just two examples, there have been many others and will certainly be many more in the future.
We seem to have created several generations of programmers who can code some amazing high-level stuff running on big fat server farms connected to the net, but who can bog-down even the fastest PC with their resource-hungry lazy habits and tools and who are completely lost on any platform that runs at less than a GHz and without a network connection; some seem completely lost when encountering a physical bit of hardware that must be controlled, never apparently never seen an opcode mnemonic, and have no idea what to do with an assembler. Don't get me wrong. I am not asserting that high level languages and new ideas are bad per se. but rather that things we used to teach on top of a foundation of low-level "how it actually works" knowledge seems to be the new foundation of education and the actual foundations seem to be not taught anymore. This is dangerous; it leads to programmers who think they know what's happening on the systems they are building but who actually have no idea how their systems actually work. New ideas/languages/tools/techniques are not good just because they are new, but rather because they are properly understood and then properly used when and where appropriate.
Now, you kids, Git offa my lawn!!!! [smile]
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.
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?