Hacker News Reader

Comment by phoe-krk | Hacker News Reader

As a Lisp programmer, I don't dunk on everything that is not Rust; I instead dunk on everything that is C. The extensive use of this language has brought us countless pain via stack overflows, buffer overflows, memory corruption, and multiple other vulnerabilities that are literally baked into the language model. Dropping C for any sane alternative will be a massive boon.

View on HN

I think ada can be good contender for C replacement

I think Ada's future is in safety-critical systems, where it makes sense to invest heavily in correctness, with the option of using SPARK and formal verification. Additionally, Ada has several mature compilers suitable for life-and-death applications.

For more ordinary software though, doesn't Rust make more sense? Its approach to memory management for instance, with a borrower-checker, seems much nicer than what Ada has to offer.

Disclaimer: I know neither language very well.

You need something with traction. How are you going to rally people to use ada? Where is the ada version of Gitoxide?

> You need something with traction

No language has traction, until it does.

It would be fair to point out though that Ada has had decades to catch on and replace C, but it hasn't done so, except in certain narrow areas of highly critical embedded software development in aviation and military applications. My understanding is that it's not easy to work with for 'general purpose' work (command-line applications on GNU/Linux), as it lacks mature bindings.

I think it's fair to say Ada failed to truly embrace Free and Open Source software. A pity, in my opinion.

Well they are trying to reach FOSS community. Recently they started survey asking community "Hello here, we (AdaCore) have some plan for the future of GNAT Community that we want to share and have your opinion on: https://forms.gle/Q34myTCQUXvrva5n7 " There is Ravenports very good port manager written in ada for FreeBSD so ada can be used for CLI apps and has good gtk binding too

A good sign, see also relevant discussion at [0]. I like the idea of a FORTH target that someone suggested.

Are the higher assurance-levels of SPARK going to remain unavailable to FOSS developers, as they apparently are now? [1]

[0] https://groups.google.com/forum/#!topic/comp.lang.ada/M3yS4S...

[1] https://www.adacore.com/sparkpro

Doesn't Ada have the same explicit deallocation and use-after-free problems C does?

Better do not use Lisp, since the interpreters have at least around 10% C.

They're compilers, not interpreters - or at least SBCL, CCL, ABCL, ECL, Clasp, CLISP, ABCL, and LispWorks are. I'm not aware of any other alive contemporary Common Lisp implementations.

Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C. In addition, the Lisp compilers are written in Lisp itself, not in C, which further decreases the attack vector.

Also, the currently-in-progress SICL project intends to do away with C completely, even for its garbage collection and OS-interfacing parts.

CCL:

Totals grouped by language (dominant language first):

  lisp:        336793 (84.60%)
  asm:          30410 (7.64%)
  ansic:        29862 (7.50%)
  sh:             718 (0.18%)
  objc:           299 (0.08%)
  java:             7 (0.00%)

> Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C.

Yeah, right.

> Yeah, right.

In Lisp, the programmer never frees memory themselves, so use-after-free and double-free are not triggerable by the user. Bound checks for all array types are in effect, so overflows are impossible. Strong typing and a lack of casting prevent type confusion.

Do you have any arguments other than the unsubstantial "yeah, right"?

Lisp implementations using C means that the implementations may have C-related vulnerabilities, not Lisp programs themselves. You're not facing the risk of creating new C-related vulnerabilities by writing new application code in Lisp, even if the Lisp you're using has substantial amounts of the run-time written in C.

Reply on news.ycombinator.com