It's 2023, so of course I'm learning Common Lisp

Re:It's 2023, so of course I'm learning Common Lisp by lenkite on Thursday July 27, 2023 @06:20AM (#36891444)

Can you explain why this is not ? Code injection in production environments is generally considered an easy attack vector. Lots of CVE's around this in other language SDK's that have been ironed out over the last decade and half. I don't think Common Lisp gets "special protection" here or does it ?

Unless you are restricting this to only development in which case there are a lot more languages other than common lisp that support hot-reloading/re-definition.

[ Parent | on HN ]

Re:It's 2023, so of course I'm learning Common Lisp by moonchild on Thursday July 27, 2023 @04:19PM (#36899574)

> Lots of CVE's around this in other language SDK's that have been ironed out over the last decade and half

Like what? The only notable one I know of is log4shell. And no one advocates not to use java because of rce. Nor javascript, nor python, nor erlang. Compare with c...

[ Parent | on HN ]

Re:It's 2023, so of course I'm learning Common Lisp by bo-tato on Friday July 28, 2023 @02:24PM (#36911080)

You are loading code you wrote, not evaling untrusted user input. Common Lisp is actually safer than a lot of languages in that Java, Python, Javascript, etc all do lots of runtime reflection and metaprogramming that leads to vulnerabilities where lisp metaprogramming is happening at compile time and therefore a lot safer.

[ Parent | on HN ]