back to article Rust is eating into our systems, and it's a good thing

Rust is eating into our systems. The first Rusted drivers are being welded into Linux, while Microsoft's Azure CTO Mark Russinovich said C/C++ – until now, the systems languages of choice – should be dropped in favor of Rust henceforth.  This is not universally applauded. No change in ecosystem ever is, and language wars have …

  1. prandeamus

    Pension plan

    Even if you don't learn Rust, there's also some scope for C and C++ to become the COBOL of the 2030s. If I live that long, it could well be an addition to my pension.

    (If you're thinking of arguing the exact date this might happen, yeah, yeah, yeah, whatever)

    1. bazza Silver badge

      Re: Pension plan

      Could be. Though if the (probably hypocrophal) wise-old-coders' lore is correct, there's more Cobol been written than anything else so the scope of a C-fuelled pension scheme is less than the one that once existed for Cobol.

      We might end up competing for C maintenance jobs!

      One of the interesting things might be that, because Rust interops with C so well, maintain old C code might be best done by re-writing the module in Rust.

      Another thing that could be interesting, for old code bases, is that Rust seems to be picking up talents in all sorts of areas (web, etc). So if one has a large pile of C that, for example, needs to (finally) get with the Internet, adding that by adding a Rust module could be an effective way of doing that.

    2. Steve Channell
      Meh

      Re: Pension plan

      Java is already the COBOL of the 21st century, while Java/EE is a slower version of CISC/COBOL in the 21st century. C++ might be the PL/1 of the 21st century.

      by far the best thing about Rust is that you don't have to explain why you never switched to unique_ptr<> for type safety ... many of us C++ developers don't have the luxury of rancid buggy code to justify a shiny new toy.

      Rust is great, but cpp2/cmake/vcpkg will eclipse it

      1. bazza Silver badge

        Re: Pension plan

        Ah, PL/1. Never used it, but I did earn some money programming in PLP on a Prime mainframe. Happy days. Seemed to involve a lot of croquet as I recall.

        It will be interesting to see how things go. It's been pointed out that Rust is a sibling of Algol66, rather than a descendant. That could have some consequences in the future. IF the academic world starts teaching Rust, rather than any Algol66-derived language (C, C++, Java, C#, etc) then there could eventually be a population of programmers who are entirely used to Rust and all it does for you, and have no awareness of Algol66-style languages and all their characteristics. That could make ancient code bases very difficult to get maintained.

  2. Mike 125

    we won't go quietly...

    "A generation of systems programmers have gone from hip young codeslingers to senior management,"

    You say that like it's a good thing. Some of us stayed coding, because done properly, it's just as satisfying and fun as it ever was.

    Of course, change must come. No corner of IT, big or small, is single threaded any more. And it's no longer just about execution speed and code size.

    So bring it on, young guns. Show us what you've got.

    But I'll C you and raise you anyday!

    1. AndrueC Silver badge
      Happy

      Re: we won't go quietly...

      I never climbed into management because I preferred to code. Also being in management means spending more time dealing with people and that's just not fun.

      I've been through a lot in my time (Basic->BCPL->C++->Delphi->C#. CP/M->MSDOS->OS/2->Windows. By and large things have got easier over time (Basic->BCPL being an exception, lol and there are certainly times when I feel that Visual Studio is not making anything easier) so if I wasn't retiring I'd be investigating Rust.

      Being wedded to one particular technology and resistant to change is one of the worst things you can do if you work in IT. It's a balancing act though - leaping with wild abandon onto the next new thing is worse :)

      1. sgj100

        Re: we won't go quietly...

        Nice to see another BCPL user! My first post University job was porting a suite of BCPL code from an IBM mainframe to a Motorola 68000 based S100 system running Cromix, Nowadays, for fun, I use Go which I think has something of BCPL about it

        1. AndrueC Silver badge
          Happy

          Re: we won't go quietly...

          It took a while to get my head around the lack of types but the upside was that it taught me more about the low-level side of programming languages whilst at the same time introducing me to hierarchically structured code. And of course a good taster for my later C/C++ work.

        2. prandeamus

          Re: we won't go quietly...

          BCPL ? Me too.

          Electronics Dept at Uni of Southampton, wrote an interactive debugger for 6809 and 68K systems for my undergraduate degree. It was crap, by the way, so if anyone bumped into it in later years, sorry. Then worked for Richards Computer Products in the mid-80s.

          Lovely little language, if a little eccentric by modern standards.

        3. Anonymous Coward
          Anonymous Coward

          Re: we won't go quietly...

          I remember writing in BCPL on a BBC B as a hobbiest. Don't remember too much about it as that was a looong time ago.

    2. John Hawkins

      Re: we won't go quietly...

      "Worse yet, they may become managers who never get to write any code themselves"

      Snow Crash, Neal Stephenson 1992

  3. trevorde Silver badge

    Meh!

    I can write Fortran in any language

    1. Anonymous Coward
      Anonymous Coward

      Re: Meh!..Meh, Meh

      I can write any language in asm..

      ..but dont ask me to write it in x86. I'd rather kill myself. Or watch back to back episodes of Emmerdale Farm for a week. All 168 hours.

      Yes, x86 is that gruesome.

      1. Anonymous Coward
        Anonymous Coward

        Re: Meh!..Meh, Meh

        Yes, x86 can be gruesome, but PowerPC is absolutely horrific.

        1. Anonymous Coward
          Anonymous Coward

          Re: Meh!..Meh, Meh

          And Emmerdale Farm may be bad, but imagine having to listen to the entire run of The Archers.

          1. Anonymous Coward
            Anonymous Coward

            Re: Meh!..Meh, Meh..Emmerdale.

            I hesitated a moment between Emmerdale Farm and The Archers. But plumped for Emmerdale Farm as being the most awful. I vaguely remember The Archers being ever so slightly interesting some time in the late 1970's. But that might might have been a hallucination brought on by old age.

        2. Anonymous Coward
          Anonymous Coward

          Re: Meh!..Meh, Meh.. PPC is OK

          Wrote quite a bit of various PowerPC starting with the 601. It was OK. A huge step down from the 68K for orthogonality and ease of getting things done. But nothing outstandingly awful.

          I'd rate the PowerPC as about average when it came to pain and suffering. You want a painful RISC instruction set, try the SH-2.

          1. bazza Silver badge

            Re: Meh!..Meh, Meh.. PPC is OK

            Plus, if (hazy) memory serves, one of the philosphies of RISC was that one used a compiler instead of hand writting assembler.

            Having said that, I have been the beneficiary of the labours of some extremely talented assembler coders who really, really knew what they were doing with PowerPC assembler, Altivec, and the caches on the CPU. Their employer would occassionally let them out for fresh air...

        3. Jonathon Green

          Re: Meh!..Meh, Meh

          RISC instruction sets as a class literally are not intended for human consumption…

          1. Tom 7

            Re: Meh!..Meh, Meh

            That's why the have an assembler!

          2. Anonymous Coward
            Anonymous Coward

            Re: Meh!..Meh, Meh..RISC compiler only? really?

            ARM and MIPS, both very RISC, are both nice asms to work with. PPC is not bad. Sparc left me me with a throbbing headache.

            In CISC world 68k is orthogonal heaven. Z80 and 6502 are both workman like. Get things done without much fuss.

            x86 makes me want to slit my wrists. x64 is almost tolerable.

            Now the Transputers Occam was fun. But never really commercial. And 2900 bit-slice was great for instruction control freaks.

            1. Arthur the cat Silver badge

              Re: Meh!..Meh, Meh..RISC compiler only? really?

              In CISC world 68k is orthogonal heaven

              I'd argue that NatSemi 320xx processors were slightly better, but unfortunately came late to the game so never really got anywhere.

              x86 makes me want to slit my wrists. x64 is almost tolerable.

              x86 makes me want to slit the "designer"'s throat. Agree on x64.

              Now the Transputers Occam was fun. But never really commercial. And 2900 bit-slice was great for instruction control freaks.

              Ooh, 2900 bit-slice. Now that was fun!

      2. Version 1.0 Silver badge
        Thumb Up

        Re: Meh!..Meh, Meh

        I wrote assembly software for a device that I created - it generated an clinical quality EKG two channel simulation back in 1979. I wrote it with a pencil because there was no assembler, it was only running on an SD Systems Z80 Starter Kit so it was writen with a pencil, occasional errors were just erased and replaced, then manually coded into an Eprom via the keyboard , it ran great - the link shows the board it was written on.

        1. werdsmith Silver badge

          Re: Meh!..Meh, Meh

          Writing assembler on paper with a pen, and then manually transposing the assember into hex codes, and then manually entering the hex codes sequentially on a keypad was a normal activity for me back in the olden days.

          1. that one in the corner Silver badge

            Re: Meh!..Meh, Meh

            Ditto - but only after soldering all the bits and pieces onto the PCB in the first place; how else was one supposed to get hold of a microprocessor and write code for it?

            1. eldel

              Re: Meh!..Meh, Meh

              Ah memories of a Nascom 1. Fondly remembered even though, if I were to be completely honest, it caused me to learn and invent many more swearwords.

            2. werdsmith Silver badge

              Re: Meh!..Meh, Meh

              Ditto - but only after soldering all the bits and pieces onto the PCB in the first place; how else was one supposed to get hold of a microprocessor and write code for it?

              I also made these things on Vero stripboard back then. With 7 segment LED displaying an 8 bit latch (I think 74LS374) outputs and a hex keypad from RS.

              But the college machines which were essentially the same thing were repurposed point of sale machines.

          2. Anonymous Coward
            Anonymous Coward

            Re: Meh!..Meh, Meh..hex?

            Well the pen and paper was all we had when I wrote my first assembly language program. Which then had to be hand-assembled into octal. For input on a front panel.

            It was absolute heaven when I got to write my first 6502 by hand and then type it into an Apple II and have it displayed on a screen and then stuff happened - on the screen. Although not where I wanted as it turned out the Apple II had non contiguous video memory mapping. That Woz guy and his obsession with saving a few 74LS TTL's wherever he could.

            1. Anonymous Coward
              Anonymous Coward

              Re: Meh!..Meh, Meh..hex?

              I never liked Z80 assembler (or x86 for that matter) but loved 6502 assembler - I wrote a complete Windowing System in 6502 assembly language (10K? 12K? of code) for a BBC Micro and burnt it onto a EPROM so the machine booted into it :-)

              Those were the days!

              1. AndrueC Silver badge
                Happy

                Re: Meh!..Meh, Meh..hex?

                I'm the opposite. I could never get past two things: The lack of registers on the 6502 and syntax that combined source and destination. I'm guessing that with the lack of source options it made sense but I will never accept LDA, 123. It should LD A, 123 :)

      3. druck Silver badge

        Re: Meh!..Meh, Meh

        26 bit ARM was a thing of beauty with all instructions conditional, free barrel shifts, and the combined PC+PSR allowing costless flag preservation over subroutines. 32 bit ARM lost a bit of the magic when the PC and PSR became separate, but it was still fun. But now with ARMv8, it could really be just any other 64 bit ISA, so I leave it to the compiler.

        1. Vometia has insomnia. Again. Silver badge

          Re: Meh!..Meh, Meh

          Sophie Wilson seemed to be quite the assembler enthusiast back in the day and certainly made good use of it, so I can see why that would be the case; I think her philosophy for the ARM's design was pretty much a 6502 on steroids. But she moved elsewhere decades ago and I guess the newer models were done by people who were primarily logic and circuit designers rather than enthusiasts.

          I never learnt assembler properly. Too skint to afford one in my early teens (shame, the 6809 I had available had a good reputation amongst, erm, assemblerists) and too busy trying to get thrown out of college later on. :|

          1. Kristian Walsh Silver badge

            Re: Meh!..Meh, Meh

            Yes, 6502 was her original influence, but ARM was always a 6502 programmer’s wish-list for a better ISA.

            The first time I saw the “conditional instruction” idea I was amazed at how something so simple could fix such a common performance issue - branches are fairly expensive, but code is filled with short conditional jumps. For example, code like "if (x==0) y=1 else y=2” need five instructions on a typical ISA (load, branch-if-zero +2, load #1, branch-unconditionally +1, load #2), but only three on ARM (load, load-if-zero #1, load-if-not-zero #2). Saves space and memory, Genius.

    2. Bertieboy

      Re: Meh!

      D'accorde! Still the daddy as far as I (an un-reconstructed number cruncher) am concerned but I must admit C is all I use these days. Now where did I put my pension book?

    3. Anonymous Coward
      Windows

      Re: Meh! - You had languages?!?

      Programming has been going downhill since we gave up on plug boards and patch cables.

  4. Dan 55 Silver badge

    Something C++ can do that Rust can't

    Backward compatibility.

    From C/old C++ to Rust would be a big bang change, from C/old C++ to new C++ can be done piecewise.

    That's quite a barrier to overcome.

    1. The Indomitable Gall

      Re: Something C++ can do that Rust can't

      If you're properly modularising your code, then you should be able to spin off any existing code to runtime-linked libraries, so that's nowhere near as big an issue as it would have been 25 years ago.

      1. karlkarl Silver badge

        Re: Something C++ can do that Rust can't

        What? And marshal the data (i.e std::string) between them? No thanks. Spending my time writing bindings is not productive when I can just stick to one homogeneous language.

        Unlike good ol' C, the C++ and Rust languages also have weak ABI compat making this a further waste of time.

        1. sneed

          Re: Something C++ can do that Rust can't

          Both C++ and Rust can use the C ABI as an intermediary.

      2. Anonymous Coward
        Anonymous Coward

        Re: Something C++ can do that Rust can't..ha.ha

        ..properly modularising ...

        I'd guess you have not worked on very many very large commercial application code bases then.

        Some of the better ones actually have a kinda logically organizer source tree. Sort of. Dont have enormous numbers of globals which cause weird unrelated code interdependencies. Hell, I'm happy if i can edit a single source file and it does not cause a global recompile. You think I'm joking?...

        Here's an example. And its one of the cleaner application codebase I've seen. Go grab the Chrome browser source code. All of it. Now try to get it to build. All of it. Read all those build instructions carefully. Several times Now try to get it to build. Now find the code for a nice simple feature to modify. Try to work out how to modify it. Watch what gets rebuilt. Go off and have lunch. Have a coffee. Read a short novel.

        And thats one of the saner codebases. You should see whats inside the codebases that never see the public gaze.

    2. RichardBarrell

      Re: Something C++ can do that Rust can't

      Totes can. I've seen someone write up the process before of turning a working C program into a working Rust program one `.o` file at a time.

      1. karlkarl Silver badge

        Re: Something C++ can do that Rust can't

        And liberal use of unsafe {} to support the char* C-style strings I suppose.

        1. ssokolow

          Re: Something C++ can do that Rust can't

          Rust has `std::ffi::CString` (allocate/free in Rust) and `std::ffi::CStr` (can be wrapped around memory allocated outside Rust) types for null-terminated strings, so you only need `unsafe` for the `from_raw`/`from_ptr` constructors which rely on you to ensure their input is in compliance with the expected invariants. (Stuff like "must be a non-null pointer to a null-terminated string".)

          The rest is on you designing an API that ensures they can't be used incorrectly.

      2. Dan 55 Silver badge

        Re: Something C++ can do that Rust can't

        I'm talking about one variable, string, structure, or function at a time. Refactoring when fixing bugs over months or years that doesn't scare the PHBs and their budgets, because it's effectively free.

        1. ssokolow

          Re: Something C++ can do that Rust can't

          There's also Federico Mena Quintero's blog, where he detailed the process of incrementally rewriting librsvg from C to Rust.

          https://viruta.org/tag/rust.html

    3. DrXym

      Re: Something C++ can do that Rust can't

      First off, don't move to Rust unless you have a good reason to. If something works, it works.

      However if you do need to switch then yes it can be done piece wise. Tools like bindgen & cbindgen generate the C headers or Rust files to call from C to Rust or Rust to C super easy. It's actually pretty straightforward although since C is not safe and Rust is safe, you need to think of your interface and what data you share..

      For C++ you would call Rust like a C lib through exposed functions and wrap it with some RAII class. Similar to how you might wrap a C library. Calling C++ from Rust would require you expose a C function (i.e. not mangled) in your C++ as an entry point that caught exceptions etc, which would be similar complexity to trying to call C++ from C - not something people usually do.

      1. ssokolow

        Re: Something C++ can do that Rust can't

        ...and, cbindgen's support for C++ constructs aside, there also exist crates like flapigen (https://lib.rs/crates/flapigen) which can do a lot of that for you to ensure that it's a compile-time error if the Rust→C→C++ parts don't line up.

  5. Decani
    Go

    I'm getting rusty

    I've still got 5 to 10 years before I retire, but I'm looking into migrating to Rust, to escape the utter BS of modern Java development (endless frameworks rather than writing code, verbosity, vanilla developers). I did plenty of C and C++ back in the day so it wouldn't be a total shock. Null-safety, memory safety, sum types, no reflection, no byte code weaving, etc. All good. Plus maybe the framework w*nks won't destroy the fun of programming in Rust before I retire.

    Either that or I've got PTSD/Long Covid after looking at so much shocking java.

    1. Tessier-Ashpool

      Re: I'm getting rusty

      I'd join you, but I already scarpered from the world of work. I was doing primarily C# for many years, which I must admit was an easy and powerful way to program, especially with LINQ extensions. But the headaches of null pointer reference exceptions was a real pain in the neck, and garbage collection / object disposal was always a bit hit and miss as to whether it would work efficiently and cleanly. I got into the habit of using the "using { }" construct religiously to dispose of disposable resources, but code analysis would inevitably moan that I needed to go through additional manual hoop jumping to clean things up. Right. Royal. Pain. In. The. Neck.

      1. tiggity Silver badge

        Re: I'm getting rusty

        And garbage collection still is a PITA in C#

        .. Just today, to deal with some exceptions that would otherwise occur later in the code I had to follow myObj.Dispose(); with myObj = null; (alternatively I could have forced garbage collection, but the code convention we use is set to null after dispose just to make clear its one of those weird C# disposal bugs

    2. fg_swe Bronze badge

      Not True

      The efficiency of C and C++ comes from things such as

      + Stack Allocation of complex data

      + Finely controlled heap allocation/deallocation (as opposed to stop the process GC)

      + Arrays of complex data structures (as opposed to arrays of pointers)

      + Call by reference

      + synchronous destructors

      + RAII

      They can be realized in a rather straightforward manner in a memory safe evolution of C and C++.

      Proof: http://sappeur.ddnss.de

      1. Crypto Monad Silver badge

        Re: Not True

        For anyone looking for a "better C/C++", then this is interesting:

        https://ziglang.org/

      2. Anonymous Coward
        Anonymous Coward

        Re: Not True

        Will you please stop spamming the board with your own property commercial "language". Nobody wants TypeScript for C++. If you must advertise, pay El Reg to advertise.

    3. chololennon
      Unhappy

      Re: I'm getting rusty

      "I'm getting rusty"

      So do I. I am an experienced C/C++ programmer (more than 30 years using them) who used to love both languages, but about 6 years ago I started to hate C++ with passion. Even with my experience I can't longer say that I am an expert in C++, but with 15 years in Java or Python I can do it, why? because C ++ is so bloated with new features that's impossible to know all of them, and of course, at the same time, we have all the nasty features available (e.g. the fiasco initialization). The language is so complex now that each programmer does what they can with their knowledge, which in turn ends up in horrible code bases when new, old, good and bad features are mixed. Another thing to mention: The same feature present in other languages is always more complex in C++, OMG! (e.g. just look what multithreading, concepts or coroutines are).

      I'm sorry for my rant, but that's why I am learning Rust these days (I am still don't know if it is better or not than than C/C++, but I will find it)

      1. cornetman Silver badge

        Re: I'm getting rusty

        I hear that.

        The other thing that is the bane of my life is templates and how truly awful they are in C++. A good concept done really badly, or at least implemented really badly. Every time I have to decode template error messages I want to tear all the skin on my face off.

        https://www.youtube.com/watch?v=tnqgYm0CXys

        1. DexterWard

          Re: I'm getting rusty

          C++ template error messages are so obscure that they have introduced a new language feature in C++20 purely to make the template errors comprehensible. ‘Concepts’. I like C++ but it is now so huge and complex that I can’t believe anyone can know all of it. Rust strikes me as more a replacement for C than C++ anyway. Much less expressive power than C++ but it tries to do one thing well, which is not a bad idea at all.

      2. TheMeerkat

        Re: I'm getting rusty

        I have a feeling that Java is truly on the way to become a monster like C++ in terms of number of features added to the language…

      3. DrXym

        Re: I'm getting rusty

        In terms of complexity Rust sits somewhere between C and C++.

        It has some new concepts and will kick your ass until you learn how borrowing works, but it alleviates a LOT of bullshit that C++ causes by its design and the overcomplexity caused by classes, inheritance, overloading, rule of 3, rule of 5 etc. etc.

    4. Michael H.F. Wilkinson Silver badge

      Re: I'm getting rusty

      I am a long-time C/C++ user in my research (and have used Pascal, FORTRAN, and assembler in the past). Rust does have a real appeal. I am considering rewriting some parallel and distributed algorithms for processing HUGE images and volume data (biggest one 162 giga-voxel, 32 bit floating point from the LOw Frequency ARray (LOFAR) radio telescope). Better still, I could get one of my students to do that. Very curious how that will pan out

  6. Anonymous Coward
    Anonymous Coward

    Rust likes to promote itself as a better and safer C, but it isn't really. It's quite a lot different from C, and the only way to make C safer is to remove or curtail the features that make it so useful.

    The argument for using Rust, like so many modern arguments, seems to be analogous to "Everybody is clumsy occasionally, so nobody should ever be allowed to use sharp knives, and then nobody will ever accidentally cut themselves. Nanny knows best. Health and Safety. etc." Personally I find that somewhat uninspiring.

    C is pretty much the perfect language for low-level drivers and embedded programming. But using C is a different skill to programming in a high-level language, and it requires a different mindset. If you are the kind of programmer that thinks in abstract terms about objects and numbers and strings rather than bytes and pointers and registers then don't try to write C.

    1. MJB7

      Re: "nobody should ever be allowed to use sharp knives"

      But that's not what Rust says. If you need a sharp knife without a safety guard, you can have it - you just have to mark the code region as `unsafe`. That means when I come to review your code, I don't have to worry about dangling pointers, use-after-free, multi-threading errors, etc in 90% of the code, and hopefully the remaining 10% is so simple that it is obviously free of errors.

    2. fg_swe Bronze badge

      A Bit More Complicated

      A lack of memory safety translates into exploitable weaknesses and therefore cyber security risks.

      For some(many?) computer applications, this can have very real, deadly consequences.

      Also, bankrobbers have programmers these days.

      1. Anonymous Coward
        Anonymous Coward

        Re: A Bit More Complicated

        You call it "a lack of memory safety".

        Others may call it "the ability to easily reference any byte in the address space".

        Whether you view this as desirable or undesirable depends entirely on your application.

        1. martinusher Silver badge

          Re: A Bit More Complicated

          I depends on the hardware, too.

          Programmers have shown repeatedly that they can't cope with segmented address spaces, the like the large puddle of generic memory because it means they don't have to design memory usage. It causes all sorts of issues, though. The problem was recognized many decades ago, the fix is obvious, but.....

        2. Anonymous Coward
          Anonymous Coward

          Re: Whether you view this as desirable or undesirable depends entirely on your application.

          Yeah, do you want your application to work or not?

        3. ssokolow

          Re: A Bit More Complicated

          Optimizers frown on that, even in C, and there are experiments ongoing with architectures like CHERI which encode pointer provenance in a hidden second 64 bits of the pointer so, if you step outside of the allocation your pointer descended from, you get a hardware trap.

    3. StrangerHereMyself Silver badge

      This is one of the excuses I hear ALL the time: "All those other programmers suck! I can write C code flawlessly!"

      We, of course, know they can't. It's too damned hard and even if they could they're not given enough time by senior management, which want it finished NOW because they want their $100 million bonuses.

  7. Locomotion69

    Yet another kid on the block

    My background is with C/C++, and I like it. Not the most easy languages to master though (and I definetly do not claim I do).

    Over the years, many other "languages" have been released to challenge the position of C/C++ - and failed, however most of them collected a lot of enthousiasts and find their place in the IT ecosystem.

    I expect this to happen to Rust too. I am curious to learn more about it (although I am not employed in "IT" anymore).

    But I doubt it will challenge the position of C++, let alone C. C emerged in 1972-1973, and is just as normal to be as, say, breathing.

    Rust is not going to take my breath away....

    1. fg_swe Bronze badge

      ALGOL, PASCAL, MODULA 2, ADA

      Algol/Algol mainframes is older than C and Unix. Arguably, this is the technologically more robust and more secure approach.

      Unix was given away for "free", so it dominates to this day.

      Windows is even worse, yet it dominates applied computer science.

      If you really want to improve things, look here for inspiration:

      https://en.wikipedia.org/wiki/Friedrich_L._Bauer

      https://en.wikipedia.org/wiki/Niklaus_Wirth

      https://en.wikipedia.org/wiki/Tony_Hoare

      https://en.wikipedia.org/wiki/ALGOL

      https://en.wikipedia.org/wiki/ICL_2900_Series

      https://en.wikipedia.org/wiki/Modula-2

      https://en.wikipedia.org/wiki/SPARK_(programming_language)

      The greatness of European thought comes from intellectual honesty, not from sucking up to power.

      1. Dan 55 Silver badge

        Re: ALGOL, PASCAL, MODULA 2, ADA

        Unix was given away for "free", so it dominates to this day.

        AT&T Unix was most certainly not free. Neither were Solaris, AIX, or HP U/X. And yet it still came out on top.

        1. fg_swe Bronze badge

          Re: ALGOL, PASCAL, MODULA 2, ADA

          BSD and Linux are given away for free.

          1. Dan 55 Silver badge

            Re: ALGOL, PASCAL, MODULA 2, ADA

            You should probably check the date each thing you cite failed in the market, you'll probably find that it died when competing against paid-for Unix.

            1. MarcoV

              Re: ALGOL, PASCAL, MODULA 2, ADA

              Pascal still lives in Delphi and Free Pascal.

              Modula2 is fairly dead (while there is a GNU M2, it isn't the most active). It was used quite a bit in the mid nineties in medical and other.

              Wirthian influences are heavily felt in Java (listed in the credits of the VM IIRC), and of course C# is a hybrid of Java with Delphi directly.

        2. Charlie Clark Silver badge

          Re: ALGOL, PASCAL, MODULA 2, ADA

          Unix wasn't sold as software, largely because the idea of software that could be installed, uninstalled, swapped, etc. didn't exist at the time. You bought a machine and it came with the necessary documentation, including the source code in order to be able to run it.

          Unix became a standard, largely because of C, and as a result and some fairly large DARPA projects, the BSD effectively became the first software and it was both free to use and "open source", inasmuch as it was assumed you'd need the source code in order to fix any of the inevitable bugs.

  8. Tomo1967

    I see only one reason to use Rust.

    To get rid of all those expensive C++ers, requiring too much money.

    Rust is a way of Idiocracy.

    Why I can't do that:

    double X = 1.2345;

    double sinVal = sin(X);

    double cosVal = cos(X);

    Ownership is good. Rust implementation is idiotic.

    1. fg_swe Bronze badge

      Can someone verify the correctness of the claim above ? I doubt it.

      1. Ilsa Loving

        It's wrong, but I can't be bothered to go into all the reasons why.

        His argument basically boils down to "I want to code like _X_, but rust won't let me, therefore it sucks.".

        I deplore this kind of attitude from developers. The decisions made /w Rust have nothing to do with the developer, and everything to do with development as a long-term effort.

      2. zac_harrold
        Facepalm

        Yeah They're Wrong

        Below is a complete snippet of Rust code that performs exactly what they say is impossible:

        fn main() {

        let x: f64 = 1.234;

        let a = x.sin();

        let b = x.cos();

        }

        What I think they were trying to refer to is the ownership system in Rust, which allows unlimited read-only references to a variable, but only 1 owner. If sin() or cos() modified x directly, then they would be correct in saying Rust wouldn't allow that code.

        For anyone interested in learning more, the Rust Docs have a pretty detailed section describing the concept of ownership: https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html

        1. Dan 55 Silver badge

          Re: Yeah They're Wrong

          So "const double x" in other words?

          Why am I supposed to be impressed by "let x: f64" instead of "const double x"?

          This is a genuine question.

          1. werdsmith Silver badge

            Re: Yeah They're Wrong

            I don't think anyone is trying to impress you.

          2. Kristian Walsh Silver badge

            Re: Yeah They're Wrong

            f64 Makes it obvious to new programmers how big a “double” is. I’ve seen code where people forget this, read 32 bits from a stream, cast it to double, store it somewhere, then all hell breaks loose later.

            I write a lot of C. With the exception of loop-counters, I always use the <stdint.h> names for integers, not the built-ins.

            I've looked into Rust a few times. It seems to be a way of automating some of my own (hard-won) good practices when using C++: use RAII, avoid "new", methods take objects as const references not pointers unless you've a really good reason to do otherwise, try to use return by value of small types wherever you can. Memory leaks and violations weren't ever a class of bug I got in my C++ code.

            C is a simple language. That makes it easy to master, but it is very, very low-level, and that puts everything on your shoulders. Some people like to think that makes them a better programmer, but after a long time doing this stuff, I think that honestly it just gives you more chances to plant landmines in your code. One thing I like about Rust is that it still allows you to do the dangerous but fast things if you need to, but the path of least resistance produces safer code than taking the same unthinking approach in C.

            1. Dan 55 Silver badge

              Re: Yeah They're Wrong

              If the programmer is really at a level where they don't know how wide an IEEE double-precision floating point value is, perhaps they might also be confused with what the "f" is in "f64".

              Nor am I convinced by the ownership argument which wasn't expanded upon, unless by default all variables are const unless specified otherwise, which could be something to enforce better programming practice... or a pain in the backside.

              You mention following good design patterns in C++ saves a lot of debugging time later. From what I can gather it seems Rust's main advantage is it doesn't have older design patterns which people fall back on so removing foot-gun opportunities. There are a tonne of paid-for static code analysis tools which can do similar for C and C++, but like code reviews, business is loathe to spend the money on them.

          3. ssokolow

            Re: Yeah They're Wrong

            The Pascal-ish "let <name>[: <type>] = ..." syntax is to avoid needing The Lexer Hack and comes from Rust's Ocaml ancestry.

            (Any time you wonder about a piece of Rust syntax that's different from C++, it probably boils down to "Rust is kinda an ML-family language in a C++ trench coat".)

            Same reason typecasting is `*x as Y` rather than `(Y) *x`.

  9. Aremmes
    Headmaster

    Romani ite dōmum

    Surely you meant to say *ductor interretī* given the second declension genitive, right?

    It bugs me that there seemingly doesn't exist any good Spanish translation for router (*enrutador* doesn't sound right even if the parts look correct), or for a lot of IT terminology for that matter. The English language truly has cemented its hegemony in this field, for better or worse, and it doesn't appear to be losing ground there, ductores interreti notwithstanding.

    1. fg_swe Bronze badge
      Happy

      Re: Romani ite dōmum

      English is a good compromise between German and Latin, so we can live with it ?

      It could be much worse, Finnish or Welsh ;-)

    2. Bitsminer Silver badge

      Pronunciation?

      Is it rowter, or rooter?

      Canadian mind wants to know. I've done both, I must say.

      As in "routing the packets here and there, the router is an important element...."

      1. Irony Deficient

        Is it rowter, or rooter?

        It’s dialect-dependent. Both pronunciations exist in North American dialects.

        1. Anonymous Coward
          Anonymous Coward

          Re: Is it rowter, or rooter?

          In the Australian dialect, the noun rooter generally has the preposition "filthy" before it.

      2. ssokolow

        Re: Pronunciation?

        As a fellow canuck, I rowt packets and plan my root on the roads.

    3. Irony Deficient

      Re: Romani ite dōmum

      Surely you meant to say *ductor interretī* given the second declension genitive, right?

      Presuming that the -ret… part came from the Latin word for “net”, rēte, which is third declension, its singular genitive would be interrētis.

      It bugs me that there seemingly doesn’t exist any good Spanish translation for router (*enrutador* doesn’t sound right even if the parts look correct),

      There are apparently a number of Spanish translations of “router”, e.g. direccionador, encaminador. “Router”, of course, comes from “route” and goes back to Latin (via) ruptaruptus, the perfect passive participle of rumpō. The modern Spanish descendant of ruptus is roto, but given the current definitions of roto, it might not be the best choice from which to coin a Spanish translation of “router”.

      1. Aremmes

        Re: Romani ite dōmum

        Presuming that the -ret… part came from the Latin word for “net”, rēte, which is third declension, its singular genitive would be interrētis.

        Thanks for the correction.

        The modern Spanish descendant of ruptus is roto, but given the current definitions of roto, it might not be the best choice from which to coin a Spanish translation of “router”.

        Roto/a (meaning broken) is one descendant, the other is ruta (meaning route), e.g. Ruta Panamericana.

        1. Irony Deficient

          Re: Romani ite dōmum

          Since you’d already written that enrutador didn’t sound right to you, I’d excluded ruta from consideration.

          Perhaps basing a Spanish translation of “router” on a meaning of Latin ductor might be another alternative? For example, guiador ?

          1. Aremmes

            Re: Romani ite dōmum

            That would work, or perhaps conductor. There's some precedent behind that logic as well -- IBM call their ESCON/FICON switches directors. Now it's just a simple matter of convincing Spanish-speaking IT geeks to call routers conductores.

  10. Proton_badger

    It saves time.

    I feel I've spent half my time for the last few decades looking at memory related bug reports in C++ code and they're hard to reproduce and fix. No matter how expert we think we are - we're above all human and we can't keep track of it all in a complex codebase.

    The amateur thinks he's that good and can manage it, the expert knows he's not.

    With Rust the compiler helps us writing good code and keeping track of memory references, while still requiring us to understand how it works (unlike a black box garbage collector). The language also have a lot of other great features that are never talked about.

    I was watching Asahi Lina write the M1 GPU Linux driver in Rust. What was amazing was that there were almost no crashes in the driver, even during development. She mostly had to chase down logic errors.

    AsahiLina wrote this comment about the experience: "Not just secure, but more reliable! This particular GPU has a limitation that means that if the firmware crashes, the user needs to reboot the whole machine (there is no way to recover), so it's important to get it right. I use Rust's type system to manage the types and lifetimes of GPU-side pointers and data, not just the CPU side ^^

    Honestly, this is the first time I've ever written anything serious in Rust, but I'm very happy with the language! I feel like it encourages good design, and then the compiler goes a long way towards making sure your implementation is correct. The firmware crashes I had yesterday were due to silly logic/setting bugs (getting a ring buffer size wrong and forgetting the last command in some command lists), and the only time the kernel side crashed was when I tried to release an imported GEM object as if were one of the driver's own. All the lifetime stuff just works, everything gets allocated and freed when it needs to be, no dangling pointers (neither on the GPU side nor the CPU side), ..."

    CloudFlare had similar experiences writing their Pingora proxy and the reliability of the code in production.

  11. Ilsa Loving

    Good

    This can't happen soon enough.

    The pendulum has swung way too far towards the "developer convenience" side and away from the "quality" side. Sloppy, poorly thought out software has gotten sloppier and more poorly thought out with each passing year, and there are way too many self-taught developers who think "runs" equates to "done".

    Shoehorning extra safety features (or yet another "framework"... *shudder*) onto existing languages can never solve the problem, because it doesn't stop developers from ignoring those features and doing it wrong anyway.

    The single biggest advantage of rust is that, by default, it doesn't let you get away with _anything_. No ridiculous untyped variables. No incomplete conditionals. No memory manipulation nonsense. Sensible crate management.

    In short: The language has sensible default requirements, and if you want to stray away from that, you need to go out of your way to do that. That's as opposed to basically every other language out there that requires developers to code defensively to protect from the languages failings. And heaven forbid the developer doesn't know how to do that, because you end up with a code base rife with ticking time bombs.

    Rust may hurt developer "velocity" in the short term, but the long term means dramatically reduced maintenance cycles, bugs, and headaches in general.

    1. StrangerHereMyself Silver badge

      Re: Good

      I don't agree. The quality of software has increased markedly over the last two decades. Even larger programs are generally much more stable than the ones in the late '90's, which had memory errors all over the place and you could actually "feel" their instability.

      Case in point: Microsoft Access.

  12. yetanotheraoc Silver badge

    Gives with one hand, takes away with the other

    Sure, Rust mitigates one class of error. As a commentard alluded to in the Russinovich article, crates.io introduces a whole other class of error. We can say it takes some effort in C++ not to run into the first class of error, but it will take just as much effort in Rust not to run into the second class of error. Maybe Rust is worse, because in C++ the books say not to make the first error, but in Rust the books say to make the second error.

  13. DS999 Silver badge
    Facepalm

    Rust is just the latest fad

    First it was C++, then it was Java, now we have Rust.

    It is just one more language added to the zoo. Rust does not do anything unique other languages do not, but it is being touted by its adherents with the same religious zeal that C++ and Java evangelists were touting them as the solution to all software ills.

    1. Anonymous Coward
      Anonymous Coward

      Re: Rust is just the latest fad

      Java was going to be bug free, IIIRC.

      ...but this time it is right, it will work, and no one will have to get nailed to anything.

    2. StrangerHereMyself Silver badge

      Re: Rust is just the latest fad

      I assure you Rust is not a fad. In fact I see it picking up steam all the time. It's already big at Microsoft internally and no doubt other large ISV's are also researching it.

      Rust's biggest problem is that it doesn't have a nice UI framework like wxWidgets. There are some Qt bindings but those are not native Rust and therefore lose a lot of the benefits of Rust.

    3. Abominator

      Re: Rust is just the latest fad

      It's like the Go evangelists all over again from 10 years ago.

      1. StrangerHereMyself Silver badge

        Re: Rust is just the latest fad

        Go has never really taken off, except with Google internally.

        It seemed like a good idea back then, but has since been superseded by Rust.

        1. DS999 Silver badge

          Re: Rust is just the latest fad

          Don't worry, Rust will be superceded as well. Something new will come along that addresses Rust's faults and that will be the new hotness.

          I am guessing you are a bit younger than some of us, and haven't seen this play out again and again for as long as we have.

  14. Henry Wertz 1 Gold badge

    Hear hear!

    Hear hear! Agreed with the article. The parts I see as most important and relevant:

    1) Memory safety, thread safety, etc. It's possible to write code that is just as safe in C/C++, if you do everything just right, and this is being used as an argument against Rust. Well, you can follow that argument to it's conclusion and conclude everything should be written in assembly -- why have all that hand-holding C does either? Just saying.

    2) Rust is fairly similar to C. I don't have much to add to this. Just saying, it's much closer to C syntactically than it is to Javascript, Python, Java, or C# for instance. You're not going to have to forget everything you learned and start over.

    Please don't fear Rust, I think using it in the places it's going now is a positive.

    (Disclaimer: My language of choice is Python, and to be honest I prefer Python to both C and Rust; but obviously Python does not belong in kernel code.)

    1. StrangerHereMyself Silver badge

      Re: Hear hear!

      I don't agree with you on 2). Rust's syntax is dissimilar enough compared to C that it's IMHO less fun to work with. I despise the return value operator (=>) which is tedious to type (and you need to type it all the time).

      Also I despise the shorthand notation for lots of stuff (fn = function, pub = public). The thing I love about C# is that it spells out everything clearly without one having to guess the meaning.

      1. sneed

        Re: Hear hear!

        This one confused me a bit, you despise "=>" because it's "tedious" to type, and "you need to type it all the time", but are totally fine with tediously typing out "function" and "public" - all the time?

        Chopping these keywords down makes them less tedious and isn't any less clear: Hmans r vry gd at fguring out wht wrds with mssng lettrs mean, and this time you're not even having to read a sentence. Maybe this would have some merit if Rust went gung-ho and chopped "break" down to "brk" (for example), but, it doesn't: https://doc.rust-lang.org/reference/keywords.html

        BTW, "=>" doesn't even make it into the top 10 most commonly used syntax in Rust, and nor does "->", which is what I think you actually might be talking about. https://twitter.com/davidtolnay/status/1534955471714406402/photo/1

        1. StrangerHereMyself Silver badge

          Re: Hear hear!

          I'm a touch typist so typing text is very fast. Symbols and such are, however, a pain.

          1. sneed

            Re: Hear hear!

            My recommendation would be to look into snippets provided by your IDE. I'm sure it already provides snippets that can mitigate your symbol typing concerns, for any language.

  15. martinusher Silver badge

    What's with the obsession with NES?

    This harping on about 'NES' and '8 bit' says more about the author than the technology of that period. A lot of people were building quite powerful and complex systems that required the code to be type safe, memory safe, thread safe and generally programmer proof, the just weren't the people that this author would be aware of. The entire PC buisiness has been one of masses of people learning why wheels were round, water wet and so on as the shortcomings of the cheap 'n dirty school of computer architecture were addressed piecemeal. Hence years later we learn that languages ideally should be programmer proof becuase only a subset of programmers have the patience to manage that level of detail. Rust appears to be one such language, a 'super-C' that takes a lot of the legwork out of coding. It might well be useful in my world, it largely depends on how well it integrates with other components and whether an efficient code generator for less well known parts becomes available.

    The older 'programmer proof' language? Ada, of course. Not what I'd call my favorite by any stretch of the imagination but its a bona-fide attempt to achieve these goals.

    1. StrangerHereMyself Silver badge

      Re: What's with the obsession with NES?

      The difference was that games or programs in general didn't encompass hundreds of thousands or millions of lines of code. Everything was much simpler and smaller and could therefore be programmed in assembly.

  16. Anonymous Coward
    Anonymous Coward

    Rust versus Linux distros

    My concern with Rust is regarding its/the Rust devs situation regarding distros.

    Rust has the concept of 3 Tiers of supported/unsupported platforms.

    Tier-1 is "guaranteed to work" and, for Linux systems, is basically aarch64 and x86/x86_64 with glibc.

    Tier-2 is "guaranteed to build" (and by implication *not* guaranteed to work) and includes Linux platforms using musl instead of glibc (i.e. Alpine Linux, a popular distro for containers), RiscV chips, some MIPS chips.

    Many distros support multiple archs that include more than just Tier-1 platforms and it causes issues if Rust-based applications cannot be built or don't then work on some of the distro's platforms.

    In addition to this some distros face the problem that each new Rust release needs to be built by only using the directly previous Rust release, so if multiple releases have come out in the intervening time then a sequence of step-by-step builds needs to be performed (A->D is not possible so A is used to build B, then B builds C, then C builds D).

    Distro-related issues are not unique to Rust, e.g. it is only recently that Python added support for wheels with musl. Indeed some developers seems to be resistant to distros packaging their software in general and want/expect users to use other means to get it - that's fine if those are generic applications but it's a different story for "key" tools like compilers or crypto libraries.

    1. ssokolow

      Re: Rust versus Linux distros

      Tier 1 is quite literally "we have access to CI farms using this hardware-software combination that every push and PR gets natively built and regression tested on".

      Tier 2 is more of a "We also do these on our CI, but we can only cross-compile for them".

      They're pretty conservative about what they're willing to promise because they've made "fearless upgrades" one of their slogan goals.

      (I believe, if Microsoft weren't donating Azure capacity for their CI, their development process would be seriously bottlenecking on CI capacity.)

  17. zac_harrold

    Still Learning

    I've only recently started learning Rust, coming from a Python, C#, and JavaScript background. I know people are excited to replace C/++ with Rust, but I'm far more excited to see it replace C#. I've spent the better part of half a decade on a C# REST API, and the number of problems that could've been caught at compile time that just aren't is insane. Between garbage collection causing randomised performance, random guard clauses being darted all over the codebase for fear of the null, and a general lack of understanding among less experienced devs around how C# defaults to passing by mutable reference for objects ("Why did my function change that variable? Isn't it copied??"), I wish I could migrate the project to something with clear rules, and a compiler which actually enforces them.

    1. werdsmith Silver badge

      Re: Still Learning

      Rust is more aligned with C than C++ or C#. It doesn't support inheritance in the way that OO languages can have a type hierarchy. Although it does have traits and can use interfaces, I wouldn't say it is a replacement for Object Oriented languages. And C# is more of a high level language with a C++ like style.

      1. zac_harrold

        Re: Still Learning

        Oh yes I agree they're very different in style, I'm not saying that Rust is C# 2, but rather that (at least in my experience thus far) Rust solves problems in ways that are superior to C#. I've yet to see Rust code that was substantially harder to grok than equivalent C# code in the projects I've worked on, but are verifiably better.

        As a personal opinion, I will say I prefer the trait/interface method of composing data into objects, as opposed to everything being an object directly with an inheritance structure. There are any instances where the C# insistence on OO is clearly antithetical to a programmer's intention. The implicit single-file namespace and implicit Program.main() are pretty clear evidence of that IMO.

  18. teambob

    Recovering C++ Programmer

    Rust doesn't have a stable ABI. Looks like they are going to copy at least one of C++'s mistakes.

    Of course Go gets around this problem by using static linking only. Without a stable ABI it means there will never be a "maven" for C++ or any other language that doesn't have an ABI

    1. ssokolow

      Re: Recovering C++ Programmer

      Rust has a "release a minimum viable product now, enhance it later" philosophy.

      They don't have a stable ABI now, but that doesn't mean they've rejected the idea forever.

      Among other reasons they don't have a stable ABI yet, they're still finding ways to improve it. For example, Rust v1.0 didn't ship with automatic structure packing, but Rust now has it if you don't use #[repr(C)]` to request a C ABI layout.

      Also, in the mean time, there exist crates like abi_stable (https://lib.rs/crates/abi_stable) which allow the problem to be worked around. (abi_stable does Rust-to-Rust FFI through the C ABI, handling the task of making sure, at compile time, that both sides share the same interpretation of the higher-level constructed being pinned into stable forms by the C ABI in the middle.)

      They also care enough that one of the big names in their low-level work made the frustrating discovery that there is no one "the C ABI" even within a single platform when writing a checker to make sure Rust could reliably speak "the C ABI" without having to carry along a C compiler.

      https://gankra.github.io/blah/c-isnt-a-language/

      (eg. GCC and LLVM don't agree on how to represent __int128 because the AMD64 SysV ABI document is merely human-readable, not an executable conformance suite.)

      > I wrote this dang thing to check for mistakes in rustc, I didn’t expect to find inconsistencies between the two major C compilers on one of the most important and well-trodden ABIs!

  19. StrangerHereMyself Silver badge

    Systems Programming Language vs. Application Programming Language

    I keep reiterating that C (and Rust) are Systems Programming Languages, to be used for developing operating systems, device drivers and time critical applications (such as audio / video encoding and decoding). But somehow we ended up using it an Application Programming Language, most likely because some developers are stubbornly insisting on a programming language which produces the fastest code.

    The makers of C have called it "high level assembly language" and that's what it basically is. With all the warts and dimples that go with it, like no pointer validation or bounds checking.

    Even mediocre programmers can write a flawless C program of a couple hundred lines of code. But it's nigh impossible to write bug-free C code programs consisting of hundreds of thousands of lines of code. People should recognize that and switch to a language which does enable them to do so. Rust tries to solve it by adding handlebars to prevent you from making errors. Another solution would be to make a safe Application Programming Language.

    1. ssokolow

      Re: Systems Programming Language vs. Application Programming Language

      Because they intuitively recognize that, in addition to being capable of low-level programming, Rust also has a lot of high-level constructs and, more importantly, it cares a lot about being an imperative systems programming language in the original definition of the term, where languages with comparable guarantees tend to be functional languages like Haskell.

      To reference a quote used to good effect in https://willcrichton.net/notes/systems-programming/ :

      > In Systems Programming Languages (Bergeron et al. 1972), the authors say:

      >

      >> A system program is an integrated set of subprograms, together forming a whole greater than the sum of its parts, and exceeding some threshold of size and/or complexity. Typical examples are systems for multiprogramming, translating, simulating, managing information, and time sharing. […] The following is a partial set of properties, some of which are found in non-systems, not all of which need be present in a given system.

      >>

      >> The problem to be solved is of a broad nature consisting of many, and usually quite varied, sub-problems.

      >> The system program is likely to be used to support other software and applications programs, but may also be a complete applications package itself.

      >> It is designed for continued “production” use rather than a one-shot solution to a single applications problem.

      >> It is likely to be continuously evolving in the number and types of features it supports.

      >> A system program requires a certain discipline or structure, both within and between modules (i.e. , “communication”) , and is usually designed and implemented by more than one person.

      In other words, by the original definition that Rust pays a lot of attention to, Java and Go are also systems programming languages, because systems programming is about producing complex infrastructural components with a long service life that need to be maintained by shifting teams... like the networks of microservices Go excels at.

  20. Robert Grant

    This might be a good direction, but I've never before thought, "The CTO of Azure has something to say about systems programming! Let's listen!"

    1. Trixr

      You need to read up on Mr Russinovich's CV. Azure is merely the latest iteration of his career.

      I'm a bit surprised he pivoted into Azure, personally, but maybe they needed someone to go kick some butt and get them delivering on security and maintainability.

  21. DaleksInc

    Syncretism begone!

    "But as religion so ably attests, sooner or later the language of the past cannot fully support the needs of the now. People still have fun creating Latin terms for 'internet router' (ductor interretus, since you ask), but Christianity has largely recompiled itself for better compatibility with the present day."

    Ironically, attempts to make Christianity "more hip" (as opposed to "okay, have we been reading the Bible wrong due to cultural baggage?") usually make it less applicable to the modern day.

    This is because attempts at "modernization" tend to discard traditional doctrine (which, while I know some people will disagree with me on this, does a good job of not conflicting with what we know about the world) in favor of feel-good moralistic mysticism. A good example of this is theistic existentialism (a la Kierkegaard), in which blind, unquestioning faith replaces "traditional" Christianity's rationalism.

    Also, as other people have mentioned, you need to touch up on your Latin grammar.

    1. Michael 66

      Re: Syncretism begone!

      I was wondering if anyone who thought Christianity had become hip has visited Texas.

  22. electronicbits

    "Much depends on culture and ego, rather than technical proficiency."

    Oh yes... having worked on IT for 20+ years, I can attest to this.

    Many technical decisions come first from ego + politics. Not necessarily being the best technical decision.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like