jondgoodwin

6 ms·

1.
by jondgoodwin 5y ago
You claim that a language can guarantee completely deterministic runs. How is that possible in Vale?
2.
by jondgoodwin 6y ago
Important mistype. It should read: "The proof does NOT stop us from knowing that SOME programs will or will not halt.
3.
by jondgoodwin 6y ago
Total functional programming indeed is another example of a valid approach to weakening cycles and thereby guaranteeing termination. Although it works for that, it is too restrictive for my taste. I am looking for less restrictive forms of
4.
by jondgoodwin 6y ago
It is indeed grand and delightful. I am glad you enjoyed the post so much. It was every bit as much fun for me to grok and then and share with others.
5.
by jondgoodwin 6y ago
AIUI actors are regularly idle. However, you are right that Pony offers a clever mechanism not offered by Erlang, which allows an actor to effectively despawn itself. I believe how it does this is to notice when no other actor has a referen
6.
by jondgoodwin 6y ago
Author here. You are 100% correct that Pony makes a strong claim about being deadlock-free: "It’s deadlock free. This one is easy, because Pony has no locks at all! So they definitely don’t deadlock, because they don’t exist." (fr
7.
by jondgoodwin 6y ago
Author here. Cool story about odd perfect examples. That said, my post is not trying to find a way to crack the halting problem, and thereby demonstrate it is not real. Turing wrote a most excellent proof, and I stand by it wholeheartedly.
8.
The Fascinating Influence of Cyclone(pling.jondgoodwin.com)
6 points by jondgoodwin 7y ago|0 comments
9.
by jondgoodwin 7y ago
Hey - I am thrilled to hear about your positive experience with interning strings. I never actually did a performance test, so I am delighted to hear your gains were substantial. As for you questions about performance on bigger source files
10.
by jondgoodwin 7y ago
Absolutely agree.
11.
by jondgoodwin 7y ago
Did you also read the follow-on post on transitional permissions?
12.
by jondgoodwin 7y ago
Very well said. This is very much what I am after. Some common idioms in Rust or C++ just feel unnecessarily verbose to me (e.g., `<exp>.unwrap().borrow_mut()`), and I am looking for straightforward ways, often borrowed from other l
13.
by jondgoodwin 7y ago
Thanks. I always welcome feedback and take it seriously.
14.
by jondgoodwin 7y ago
Yes, borrowed references being lifetime-constrained means that I have a "borrow checker" that ensures that. It is only partially implemented. You are correct that Cone supports a static, shared, mutability permission, including on
15.
by jondgoodwin 7y ago
> There is no available reference type that can target objects from different allocators. Cone actually does support Rust-like, lifetime-constrained borrowed references which can do exactly that safely. Cone also supports raw pointers (h
16.
by jondgoodwin 7y ago
Yes, but that's not what I meant in that quote. Cone is not ready for any use right now . So, I am making no effort to market it right now. When it is at least MVP (at least a year or more away), I will get more serious about marketin
17.
by jondgoodwin 7y ago
Cone is an imperative, multi-paradigmatic language in the family of systems programming languages (C, C++, Rust, D). It is fundamentally statically-typed. However, a language that is too rigidly typed can sometimes degrade programmer produc
18.
by jondgoodwin 7y ago
A summary of key differences from Rust: A richer collection of build-in memory management strategies (e.g., tracing GC), Pony-inspired permissions (esp. safe shared, mutable), structural subtyping (as well as nominal), and a bunch of featur
19.
by jondgoodwin 7y ago
It is memory safe in the same way as Rust is. Rust allows you to de-reference a raw pointer, but only within an explicitly de-marked `unsafe` block. Cone will require a similar explicit mechanism. If you want the compiler to check your code
20.
by jondgoodwin 7y ago
There is no connection. I was unaware of the similarity to UCF's logo until recently. It is something I will need to replace, as much as I like how it looks.
21.
by jondgoodwin 7y ago
That's a fair critique, and I will edit the website to make that disconnect between current reality and aspiration clearer (more than the disclaimer I have on the home page). Because there is so much left to do, I have made no effort t
22.
Compiler Performance and LLVM(pling.jondgoodwin.com)
122 points by jondgoodwin 7y ago|18 comments
23.
by jondgoodwin 8y ago
I appreciate the clarification, as I did not catch that from the context. I just assumed maybe you were not aware of my follow-up work with Cone. I do think there are good research opportunities in these ideas, e.g.: * Type theoretic work o
24.
by jondgoodwin 8y ago
> Several of the axes mentioned (memory management, language specialization) lack any documented attempts to systematize their treatment at the language level. This is not entirely true. The author of the Gradual Memory Management paper
25.
Gradual Memory Management [pdf](jondgoodwin.com)
2 points by jondgoodwin 9y ago|0 comments