4 ms·

All the comparisons are with scripting and untyped languages perhaps for faster development and more intuitive eco-system to increase developer productivity. I

All the comparisons are with scripting and untyped languages perhaps for faster development and more intuitive eco-system to increase developer productivity. In the age of IntelliSense, auto-completion and AI assisted coding, does the choice of scripting and untyped language justifiable for increased in productivity at the expense of safety and reliability? If you're building data system not just for exploratory, surely modern compiled and typed system languages like Rust and D language make more sense for safety and reliability for the end users? Even more so with D language where you can even have scripting capability for exploratory and protyping stage with its built-in REPL facility [1],[2]. This is feasible due to its very fast compile time unlike Rust. It has more intuitive "Phytonic" syntax compared to other typed languages [3]. You can also program with GC on by default if you choose to. Apparently, you can have your cake and eat it too. [1] drepl: https://github.com/dlang-community/drepl https://github.com/dlang-community/drepl [2] Why I use the D programming language for scripting: https://opensource.com/article/21/1/d-scripting https://opensource.com/article/21/1/d-scripting [3] All in on DLang: Why I pivoted to D for web, teaching, and graphics in 2025 and beyond! [PDF] https://dconf.org/2025/slides/shah.pdf https://dconf.org/2025/slides/shah.pdf

geokon 7mo ago
It's a bit apples to oranges. If you're "building data system not just for exploratory" then you're probably not going to be using any of the presented options. However, in my experience Clojure has an ecosystem where there it is very easy to transition from exploring/playing with data at the REPL to a more robust "pro" setup that's designed to scale, handle failures, etc.
- teleforce 7mo ago
  I understand the sentiments but I disagree with the approach, it's probably efficient for exploratory but not effective for everything else including prototyping and systems development. For any engineering work, including software engineering you choose the best tool for the job. In D you can have the high performance tool capable of bit shifting, string processing, array manipulation (to name a few) and from scripts to highly concurrent low-latency applications (see presentation in the ref [3] above by Prof. Shah from Yale). It's a shame that the proper typed programming language are being ignored just because of programmers' locally sub-optimal preferences and limited exposure. The productivity increased using typical scripting languages including Python is diminishing everyday with the proliferation of IntelliSense, auto-complete and AI assisted coding. For production codes, the scripting language based systems if they ever made it to production (mostly do e.g AirBNB, Twitter, Shopify, Github, etc) will be a maintenance headache and user nightmare, if the supports are not great and not unicorn start-ups. The last thing you want is that your saved eclaim form that you spent many hours preparing totally dissapeared since the system cannot recall the saved version. Granted this can be because of many reasons, but most of the problematic production systems are mostly written in scripting languages including Python because these are the only language the programmers know and familiar with. Adding to the insults are the readily available so called "battery included" libraries are convenients but ironically written in other compiled but unsafe system language in C/C++.
  - geokon 7mo ago
    I think you're going to trouble convincing people a compile-loop language is going to be on-par with a REPL/interactive setup. You can look at some extreme example like MATLAB. With all your tools you're never going to reach the same level of interactive productivity with D for the subset of problems it's address. You can have all your tools dump out and rewrite the oodles of boiler plate your typed languages require - but at the end of the day you have to read all that junk... or not? and just vibecode and #yolo it? But then you're back to "safety and reliability" problems and you haven't won anything Also "safety and reliability" are just non-goals in a lot of contexts. My shitty plotting script doesn't care about "safety". It's not sitting on the network. It's reliable enough for the subset of inputs I provide it. I don't need to handle every conceivable corner case. I have other things to do > Adding to the insults are the available readily available libraries are convenients but ironically written in other compiled but unsafe system language in C/C++ No on cares if you leak memory in some corner case with some esoteric inputs. And noone is worried your BLAS bindings are going to leak your secrets. These are just not objectives
    - teleforce 7mo ago
      My point is that Dlang scales from beginner to expert, from scripting to highly concurrent low-latency applications. Why settle for sub-optimal scripting languages if you can have the real deal with much better performance and freely available open source? In the automative world if you can afford it, you need daily drive car for the job and supermarket runs, weekend supercar for fun/showing off, and off-road 4x4 vehicles for overnight camping. But in the software world D can cater for mostly everything with free open-source compilers, minimum productivity overhead and much cheaper to host as well [1]. Funny you mentioned BLAS, since Dlang BLAS implementation has also surpassed the run-of-the-mill high performance BLAS library that these scripting languages can only dream of (Matlab calling the 3rd party Fortran codes no less) [2]. [1] Saving Money by Switching from PHP to D: https://dlang.org/blog/2019/09/30/saving-money-by-switching-from-php-to-d/ https://dlang.org/blog/2019/09/30/saving-money-by-switching-... [2] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen: http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
zelphirkalt 7mo ago
One general problem or challenge with statically strongly typed languages is, that one can quick get to a local optimum, but that local optimum might lack some flexibility, that is needed later on, only discovered after some usage and seeing many use cases. Then a big refactoring is ahead, possibly even of the core types of the project. If that is allowed and introducing such flexibility thought of, it often happens, that expressing it in types becomes quite complex, which, without a lot of care, will impact the user of the project. The user needs to adhere to the same types and there might then be quite some ceremony around making something of the correct type, to use it with the project. It is safer, but it is not without its downsides. It demands a careful design to make something people will enjoy using.
physPop 7mo ago
python isn't untyped, its dynamically typed https://stackoverflow.com/questions/2351190/static-dynamic-vs-strong-weak https://stackoverflow.com/questions/2351190/static-dynamic-v...
iLemming 7mo ago
> with its built-in REPL facility brotha... please.. you're making me laugh so hard, my parentheses are shaking and getting unbalanced. Non-lispy langs that "provide REPL facilities" and Lisp dialects share the word "REPL" the way a rowboat and an aircraft carrier share the word "vessel". A Lisp REPL is an architectural relationship between you and a running system. Dlang's REPL is a nice sketchpad - worse than Python's. It's in the same "sketchpad league" with C#'s, Ruby's, Kotlin's and Node's. Clojure REPL is closer to what Smalltalk had - you're always inside the machine.

geokon 7mo ago

It's a bit apples to oranges. If you're "building data system not just for exploratory" then you're probably not going to be using any of the presented options. However, in my experience Clojure has an ecosystem where there it is very easy to transition from exploring/playing with data at the REPL to a more robust "pro" setup that's designed to scale, handle failures, etc.

teleforce 7mo ago
I understand the sentiments but I disagree with the approach, it's probably efficient for exploratory but not effective for everything else including prototyping and systems development. For any engineering work, including software engineering you choose the best tool for the job. In D you can have the high performance tool capable of bit shifting, string processing, array manipulation (to name a few) and from scripts to highly concurrent low-latency applications (see presentation in the ref [3] above by Prof. Shah from Yale). It's a shame that the proper typed programming language are being ignored just because of programmers' locally sub-optimal preferences and limited exposure. The productivity increased using typical scripting languages including Python is diminishing everyday with the proliferation of IntelliSense, auto-complete and AI assisted coding. For production codes, the scripting language based systems if they ever made it to production (mostly do e.g AirBNB, Twitter, Shopify, Github, etc) will be a maintenance headache and user nightmare, if the supports are not great and not unicorn start-ups. The last thing you want is that your saved eclaim form that you spent many hours preparing totally dissapeared since the system cannot recall the saved version. Granted this can be because of many reasons, but most of the problematic production systems are mostly written in scripting languages including Python because these are the only language the programmers know and familiar with. Adding to the insults are the readily available so called "battery included" libraries are convenients but ironically written in other compiled but unsafe system language in C/C++.
- geokon 7mo ago
  I think you're going to trouble convincing people a compile-loop language is going to be on-par with a REPL/interactive setup. You can look at some extreme example like MATLAB. With all your tools you're never going to reach the same level of interactive productivity with D for the subset of problems it's address. You can have all your tools dump out and rewrite the oodles of boiler plate your typed languages require - but at the end of the day you have to read all that junk... or not? and just vibecode and #yolo it? But then you're back to "safety and reliability" problems and you haven't won anything Also "safety and reliability" are just non-goals in a lot of contexts. My shitty plotting script doesn't care about "safety". It's not sitting on the network. It's reliable enough for the subset of inputs I provide it. I don't need to handle every conceivable corner case. I have other things to do > Adding to the insults are the available readily available libraries are convenients but ironically written in other compiled but unsafe system language in C/C++ No on cares if you leak memory in some corner case with some esoteric inputs. And noone is worried your BLAS bindings are going to leak your secrets. These are just not objectives
  - teleforce 7mo ago
    My point is that Dlang scales from beginner to expert, from scripting to highly concurrent low-latency applications. Why settle for sub-optimal scripting languages if you can have the real deal with much better performance and freely available open source? In the automative world if you can afford it, you need daily drive car for the job and supermarket runs, weekend supercar for fun/showing off, and off-road 4x4 vehicles for overnight camping. But in the software world D can cater for mostly everything with free open-source compilers, minimum productivity overhead and much cheaper to host as well [1]. Funny you mentioned BLAS, since Dlang BLAS implementation has also surpassed the run-of-the-mill high performance BLAS library that these scripting languages can only dream of (Matlab calling the 3rd party Fortran codes no less) [2]. [1] Saving Money by Switching from PHP to D: https://dlang.org/blog/2019/09/30/saving-money-by-switching-from-php-to-d/ https://dlang.org/blog/2019/09/30/saving-money-by-switching-... [2] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen: http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...

zelphirkalt 7mo ago

One general problem or challenge with statically strongly typed languages is, that one can quick get to a local optimum, but that local optimum might lack some flexibility, that is needed later on, only discovered after some usage and seeing many use cases. Then a big refactoring is ahead, possibly even of the core types of the project. If that is allowed and introducing such flexibility thought of, it often happens, that expressing it in types becomes quite complex, which, without a lot of care, will impact the user of the project. The user needs to adhere to the same types and there might then be quite some ceremony around making something of the correct type, to use it with the project. It is safer, but it is not without its downsides. It demands a careful design to make something people will enjoy using.

physPop 7mo ago

python isn't untyped, its dynamically typed https://stackoverflow.com/questions/2351190/static-dynamic-vs-strong-weak https://stackoverflow.com/questions/2351190/static-dynamic-v...

iLemming 7mo ago

> with its built-in REPL facility brotha... please.. you're making me laugh so hard, my parentheses are shaking and getting unbalanced. Non-lispy langs that "provide REPL facilities" and Lisp dialects share the word "REPL" the way a rowboat and an aircraft carrier share the word "vessel". A Lisp REPL is an architectural relationship between you and a running system. Dlang's REPL is a nice sketchpad - worse than Python's. It's in the same "sketchpad league" with C#'s, Ruby's, Kotlin's and Node's. Clojure REPL is closer to what Smalltalk had - you're always inside the machine.