SoylentNews is people
SoylentNews
Eric S Raymond, author of "The Cathedral and the Bazaar", blogs via Ibiblio
I wanted to like Rust. I really did. I've been investigating it for months, from the outside, as a C replacement with stronger correctness guarantees that we could use for NTPsec [a hardened implementation of Network Time Protocol].
[...] I was evaluating it in contrast with Go, which I learned in order to evaluate as a C replacement a couple of weeks back.
[...] In practice, I found Rust painful to the point of unusability. The learning curve was far worse than I expected; it took me those four days of struggling with inadequate documentation to write 67 lines of wrapper code for [a simple IRC] server.
Even things that should be dirt-simple, like string concatenation, are unreasonably difficult. The language demands a huge amount of fussy, obscure ritual before you can get anything done.
The contrast with Go is extreme. By four days in of exploring Go, I had mastered most of the language, had a working program and tests, and was adding features to taste.
Have you tried using Rust, Go or any other language that might replace C in the future? What are your experiences?
(Score: 3, Insightful) by ledow on Tuesday January 17 2017, @01:04AM
Same for me, but the languages I use are generally a little older.
I remember PHP coming in and was going to solve all those horrible Perl CGI security problems - yeah, that worked a treat! (What's Soylent running? *cough*)
I remember Java going to be write-once-run-anywhere. It almost made it too. But the fact is that 90% of the Java programs I see are locked to a platform one way or another. In the last month alone I've had to update Java modules on photocopiers, a library system and an access control system. Because the first was using a feature that not all photocopier's JavaVM's implemented, the second demanded Java 1.8 for some feature or other (prompting JRE updates on 200+ machines) - and incidentally it only uses Java on PC and on other platforms they rewrote in something else entirely, and the third has to stay on ancient-Java if it's to work at all.
I remember all kinds of "We're going to fix C" languages, whether they were structures in the language itself, or rewrites, or incompatible but similar languages. We still write in C. The languages are mostly dead now but some spawned some of the ones you mention.
I tried to run a program in Python the other day. It took ages to get a compiler that worked, and then it ran into all kinds of problems (something to do with incompatibilities between Python 2.5 and OpenSSL libraries that had never been fixed?), and then the Python program wouldn't compile anyway, and it would have had required further tweaking to get it working on other platforms.
C is probably the language that has changed the least. There's not much written in C that won't run on a modern compiler, and if you stick to even C99 (18 years old at least!) you get even better chances of success. That's probably why we stick with it.
(Score: 3, Insightful) by NCommander on Tuesday January 17 2017, @07:11AM
I'll note for the record if I recoded rehash today, it won't be in Perl, and I would be very hesitant to start any new projects in Perl. Realistically, for performance reasons, I'd consider Ruby, a fast Python implementation, or even possibly Java; I might even consider Rust based on my previous experiences with the language. We've been in a LOT of pain because some of the poor design decisions made for perl web applications; specifically binding the request ($r) object to Apache internal structures. A lot of the codebase changed due to subtle behavior changes in $r, such as the ability write back to form variables, and them later. I had to write a shim to copy the array in initialization to get the old schematics back. It took several weeks of dedicated effort to migrate us to an Apache of this century.
Because there's no standardized (de-facto or other) way to get fast performance, it's not trivial to migrate an existing application from one framework to another. Right now, the leaning feeling of the staff is the next time we get a breaking API change with Apache, we're going to rip it out and migrate the mess to fastCGI and possibly switch nginx. This creates a process barrier to help reduce crashes, and at least in theory makes our life suck less since FastCGI has been relatively stable API vs. Apache's mod_perl. We still can't use Apache 2.4 due to broken dependencies all over the ecosystem. Even once all the dependencies are available for 2.4, I'm expecting I'm going to have to apply a fresh set of hacks to keep things lumbering on.
Furthermore, I've had plenty of C code go bang trying to switch compilers. For old K&R or C89 code I could understand it, but I've seen C99 code explode on different versions of GCC when you switch platforms or compilers because someone did something stupid and was depending on uninitialized data. I don't have much issue with C itself though I question the validity of using it for anything beyond system-level programming where you have both experience and the need for direct memory access. Userland applications are a lot harder to justify because a typo is a security hole.
Still always moving