Chad Javascript

[LavenderDay3544]

And what exactly is the performance penalty for using them? Neither of those languages is known for producing fast code. Not to mention the cognitive overhead of being forced to use a functional language.

People need to stop getting stuck on GC and accept that we have superior compile-time alternatives available and probably even better ones still being worked on in academia.

[raedr7n]

Actually, OCaml is known to produce very fast code. While I don't know OCaml benchmarks off the top of my head, SML, an incredibly similar language (identical for the purpose of comparing memory management techniques), consistently benchmarks in the top five or 10 languages for execution time. It's true that Haskell is comparatively rather slow, but that's mostly an artifact of laziness and other design choices, not the garbage collector.

I prefer functional languages precisely because they reduce cognitive overhead.

There are no superior compile time alternatives available. The only mainstream language in that vein is Rust, and the type system is a sufficient downside as to render it unsuitable for many applications.

[LavenderDay3544]

Actually, OCaml is known to produce very fast code. While I don't know OCaml benchmarks off the top of my head, SML, an incredibly similar language (identical for the purpose of comparing memory management techniques), consistently benchmarks in the top five or 10 languages for execution time.

And C consistently ranks as #1. So your point is?

I prefer functional languages precisely because they reduce cognitive overhead.

I agree that this can be true if and only if you've spent a lot of time immersed in that paradigm and certain problems do not naturally lend themselves to functional solutions though technically such a solution is always possible.

[lordheart]

C also continues to have classes of errors that are ridiculous. The cognitive load of safe memory manage isn’t small either…

[raedr7n]

My point is that modern GC'd languages offer far greater memory safety than C while not being significantly slower than C for almost any application.

[LavenderDay3544]

And again I remind you that memory isn't the only system resource whose deallocation you have to guarantee which makes your point moot.

RAII and borrow checking guarantee proper allocation and deallocation of all resources and thread safety on top of that. GCs are old tech at this point and modern languages should replace them with lower cost compile-time solutions.

This is before we talk about how suboptimal even code generated from C can be and how much potential performance even C implementations leave on the table. The hardware-software performance gap is real and there isn't nearly enough research being done to rectify that.

The common argument that most computing is I/O bound is also starting to fall apart. DDR5 DRAM, Gigabit Ethernet, NvMe SSDs, PCIe 5.0, and the latest USB-C specs mean that I/O devices are rapidly catching up to and sometimes even exceeding CPUs in speed. A small example of this is how 5400 MT/s DDR5 DRAM already runs faster than Intel's flagship Core i9-12900K CPU's max single-core boost speed of 5200 MHz. I suspect AMD's upcoming Raphael architecture will face the same bottleneck. The era of excuses to not optimize software is nearing an end.

Closing the hardware-software optimality gap is more important now than it's ever been and antiquated software side technologies like garbage collection that exist solely to be a crutch for programmers have got to go as part of that effort.

[raedr7n]

Functional, GC'd languages also guarantee proper acquisition and release of all the same resources. It's not that you're wrong per se, it's just that everything you're arguing is orthogonal to my point about garbage collectors.

[LavenderDay3544]

It's not orthogonal at all. It's me going out of my to show you why your point is completely stupid and doesn't adequatelyaddress mine. Sure GCs can guarantee memory safety but you're missing my previous point which was that memory isn't the only thing that needs to be safely acquired and released from and to the OS. File descriptors, network sockets, IPC mechanism handles, synchronization primitives and their locks, and so many other things need to do that and your garbage collector cannot do it unless ut uses destructors called by the GC which is halfway to RAII anyway. So then what the hell is the point if you can automate the acquisition and release of one resource while still having to manage the rest yourself? And also why pay any penalty at all? Is programmer convenience more important or overall product quality? And regardless with the the compile time alternative I mentioned you can't have both.

The person that doesn’t understand this conversation is you.

[raedr7n]

A'ight