no comments (yet)

sorted by: hot top controversial new old
there doesn't seem to be anything here
10 comments in c/rust@programming.dev view that post
[–] 25 points 1 year ago (5 children)

On the phoronix forums there are people seething about Rust nonstop. Rust in the linux kernel is their favorite enemy and they will have very strong opinions about it without ever having written rust nor a line of code in the kernel.

Rust won't 100% replace C++ code in old code bases but I'm convinced that in 5-10 years the amount of new C++ code will fall behind Rust code.

  • source
  • hideshow 5 child comments
  • [–] 13 points 1 year ago (4 children)

    5 years is optimistic. More likely 10-20 years at least. Established languages have a lot of inertia and it takes a very long time for that to change.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 5 points 11 months ago (2 children)

    language popularity can change pretty quickly

    according to the tiobe index, in 1985, lisp was the 2nd most popular programming language and c++ was the 10th. fast-forward 5 years and c++ took the 2nd place, while lisp fell down to 7th place. i wouldn't be surprised if something similar happened between c++ and rust

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 11 months ago* (1 child)

    Inertia also accounts for time and popularity. The longer something has been around and popular the more inertia it has and the harder it is for something to change it. Back in 1985 things had a lot less inertia then they do today - C and C++ have been gaining it constantly for 30 years since then.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 11 months ago

    To me the inertia could be measured in time to refactor projects.

    How much time would it take to refactor or create a net new replacement of all of the lisp code of 1985 in active production vs all of the c++ in active production today.

    I do not know the numbers but I would hypothesis a staggering delta in hours needed from the then to now. Even with advancements in code change velocity of today

  • source
  • parent
  • [–] 10 points 1 year ago (1 child)

    @shape_warrior_t I think faster delivery is also a consequence of a good DX, managing dependencies and building with cargo is probably less cumbersome than installing specific toolchain and fighting makefiles and CMake.

  • source
  • hideshow 1 child comment
  • [–] 2 points 11 months ago (1 child)

    Using the sum of C and C++ is a bit misleading. If you use C++20 or later with containers, smart pointers, ... the number of memory safety problems goes down a lot. But if you include all the problems from C and older C++...

  • source
  • hideshow 1 child comment