4 ms·

Think Kubernetes and Docker: They are trendy technologies. But they are declining in popularity, they are fragile over time. D is Lindy Effect. It's been aroun

Think Kubernetes and Docker: They are trendy technologies. But they are declining in popularity, they are fragile over time. D is Lindy Effect. It's been around for 19 years, it'll probably stay around for at least another 19. > The Lindy effect is a theory that the future life expectancy of some non-perishable things like a technology or an idea is proportional to their current age, so that every additional period of survival implies a longer remaining life expectancy.[1] Where the Lindy effect applies, mortality rate decreases with time. So Rust may be hot now– but remember, NoSQL and Docker were hot once too, and they are now not popular. Plus D is adding Rust's ownership and borrowing. D compiles faster than C++20 and is easier to learn.

virtue3 6y ago
What are people using instead of Docker now? I'm a bit confused about your statement.
- pjmlp 6y ago
  What about not using it at all, just plain application servers and VMs as always.
  - virtue3 6y ago
    I personally saw a lot of value when we (top 20 site) moved to docker over VMs. Using hammer / provisioning VMs kinda sucks. Being able to dynamically scale your app with containers is really really trivial.
vips7L 6y ago
> Plus D is adding Rust's ownership and borrowing. Is this for GC code or just @nogc and DasBetterC? Ownership seems a bit heavy when running the GC.
tinco 6y ago
In what universe are Docker and Kubernetes not as popular now than they ever were before? The core of Docker became a standard that I'm pretty sure is used in every new production pipeline on the planet. And I don't much like Kubernetes but it works and I don't know if a competitor that is as powerful and that is gaining popularity.
- crazypython 6y ago
  Kubernetes deprecates Docker: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md https://github.com/kubernetes/kubernetes/blob/master/CHANGEL... https://podman.io/ https://podman.io/ https://linuxcontainers.org/ https://linuxcontainers.org/ Kubernetes alternatives (?): https://docs.docker.com/engine/swarm/ https://docs.docker.com/engine/swarm/ https://www.hashicorp.com/ https://www.hashicorp.com/
  - tinco 6y ago
    You just picked wrong examples, docker containers are not some trend. They are a fundamental technology that has now been standardized to the point that there are now alternative management systems for them to suit specific use cases such as being part of Kubernetes. The D programming language was trendy for a bit, 15 years ago. Now it's just old tech people make blogs about reviving retro games as a gimmick. It never got substantial traction because it sat half way between Java and C++ in a way programmers from neither camp would switch to it. Rust is fundamentally different, it attacks C++ at its heart and is not only a better language, but a superior programming platform. In a few years the ecosystem will be large enough that there are no reasons for anyone to choose C++ anymore, and at that point, what is the relevance of D?
PoignardAzur 6y ago
> Plus D is adding Rust's ownership and borrowing Saying that "@live" feature is "adding Rust's ownership and borrowing" is technically accurate, but in reality I'd be surprised if it were used in production in major systems in the next 5 years. The @live feature has multiple problems: - The author wants it to be implementable incrementally (eg some code uses @live, some doesn't), but doing so isn't really feasible in safe code. From the moment you disable GC, you either need your entire program to respect some strict memory model (in which case you basically have a new programming language, and no incrementality), or your program won't be any safer than C++. This is not hyperbole: Rust-with-unsafe and D-with-@system is safer than C++, because you only need to audit an annotated subset of your codebase. D-with-@live (or more accurately, D-with-@trusted-@live) is not safer, because a memory error can come from anywhere in your program. - Speaking of a memory model, D doesn't have one. Rust has Stacked Borrows, which gives library developers a framework to know whether their unsafe code might lead to undefined behavior. D doesn't seem to have nailed down semantics as to how @live might create/affect undefined behavior (which means the semantics will probably be "whatever the DMD/LLVM/GCC backend wants"). - Rust has Non-Lexical-Lifetimes (and soon Polonius). D's documentation is very sparse about how lifetimes in @live will be determined, but I think it's safe to assume that it will be scope-based at first. This means that, eventually, when @live ships, it will be roughly equivalent to Rust as it was in 2015. Not great. And, finally, saying that Rust will decline because another language will add OB misses what makes Rust great. The strength of Rust is that things work by default. A quick search through D's forums will raise dozens of instances of people complaining about edge cases in the language, things that don't work exactly as expected or produce undefined behavior (autodecoding and uninitialized variables come to mind). Rust has very few problems like that. If your Rust code compiles, it will work. You will never have a bug that happens on a coworker's machine but not on yours, or a crash that happens because you used two niche features that weren't designed to be used together. If your code crashes, it will be in a predictable, reproducible way, with an error message and a stack trace to tell you what to fix. Rust isn't perfect, but it's infinitely less fragile over time than D.
- EvenThisAcronym 6y ago
  > Rust has Non-Lexical-Lifetimes (and soon Polonius). D's documentation is very sparse about how lifetimes in @live will be determined, but I think it's safe to assume that it will be scope-based at first. @live also has non-lexical lifetimes: https://forum.dlang.org/post/r742l6$2ofo$1@digitalmars.com https://forum.dlang.org/post/r742l6$2ofo$1@digitalmars.com

virtue3 6y ago

What are people using instead of Docker now? I'm a bit confused about your statement.

pjmlp 6y ago
What about not using it at all, just plain application servers and VMs as always.
- virtue3 6y ago
  I personally saw a lot of value when we (top 20 site) moved to docker over VMs. Using hammer / provisioning VMs kinda sucks. Being able to dynamically scale your app with containers is really really trivial.

vips7L 6y ago

> Plus D is adding Rust's ownership and borrowing. Is this for GC code or just @nogc and DasBetterC? Ownership seems a bit heavy when running the GC.

tinco 6y ago

In what universe are Docker and Kubernetes not as popular now than they ever were before? The core of Docker became a standard that I'm pretty sure is used in every new production pipeline on the planet. And I don't much like Kubernetes but it works and I don't know if a competitor that is as powerful and that is gaining popularity.

crazypython 6y ago
Kubernetes deprecates Docker: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md https://github.com/kubernetes/kubernetes/blob/master/CHANGEL... https://podman.io/ https://podman.io/ https://linuxcontainers.org/ https://linuxcontainers.org/ Kubernetes alternatives (?): https://docs.docker.com/engine/swarm/ https://docs.docker.com/engine/swarm/ https://www.hashicorp.com/ https://www.hashicorp.com/
- tinco 6y ago
  You just picked wrong examples, docker containers are not some trend. They are a fundamental technology that has now been standardized to the point that there are now alternative management systems for them to suit specific use cases such as being part of Kubernetes. The D programming language was trendy for a bit, 15 years ago. Now it's just old tech people make blogs about reviving retro games as a gimmick. It never got substantial traction because it sat half way between Java and C++ in a way programmers from neither camp would switch to it. Rust is fundamentally different, it attacks C++ at its heart and is not only a better language, but a superior programming platform. In a few years the ecosystem will be large enough that there are no reasons for anyone to choose C++ anymore, and at that point, what is the relevance of D?

PoignardAzur 6y ago

> Plus D is adding Rust's ownership and borrowing Saying that "@live" feature is "adding Rust's ownership and borrowing" is technically accurate, but in reality I'd be surprised if it were used in production in major systems in the next 5 years. The @live feature has multiple problems: - The author wants it to be implementable incrementally (eg some code uses @live, some doesn't), but doing so isn't really feasible in safe code. From the moment you disable GC, you either need your entire program to respect some strict memory model (in which case you basically have a new programming language, and no incrementality), or your program won't be any safer than C++. This is not hyperbole: Rust-with-unsafe and D-with-@system is safer than C++, because you only need to audit an annotated subset of your codebase. D-with-@live (or more accurately, D-with-@trusted-@live) is not safer, because a memory error can come from anywhere in your program. - Speaking of a memory model, D doesn't have one. Rust has Stacked Borrows, which gives library developers a framework to know whether their unsafe code might lead to undefined behavior. D doesn't seem to have nailed down semantics as to how @live might create/affect undefined behavior (which means the semantics will probably be "whatever the DMD/LLVM/GCC backend wants"). - Rust has Non-Lexical-Lifetimes (and soon Polonius). D's documentation is very sparse about how lifetimes in @live will be determined, but I think it's safe to assume that it will be scope-based at first. This means that, eventually, when @live ships, it will be roughly equivalent to Rust as it was in 2015. Not great. And, finally, saying that Rust will decline because another language will add OB misses what makes Rust great. The strength of Rust is that things work by default. A quick search through D's forums will raise dozens of instances of people complaining about edge cases in the language, things that don't work exactly as expected or produce undefined behavior (autodecoding and uninitialized variables come to mind). Rust has very few problems like that. If your Rust code compiles, it will work. You will never have a bug that happens on a coworker's machine but not on yours, or a crash that happens because you used two niche features that weren't designed to be used together. If your code crashes, it will be in a predictable, reproducible way, with an error message and a stack trace to tell you what to fix. Rust isn't perfect, but it's infinitely less fragile over time than D.

EvenThisAcronym 6y ago
> Rust has Non-Lexical-Lifetimes (and soon Polonius). D's documentation is very sparse about how lifetimes in @live will be determined, but I think it's safe to assume that it will be scope-based at first. @live also has non-lexical lifetimes: https://forum.dlang.org/post/r742l6$2ofo$1@digitalmars.com https://forum.dlang.org/post/r742l6$2ofo$1@digitalmars.com