4 ms·

What's wrong with it, then? Such a language would need: 1. tool support (valgrind, gdb or better) 2. good performance - 64-bit on the major desktop OSes (mobi

What's wrong with it, then? Such a language would need: 1. tool support (valgrind, gdb or better) 2. good performance - 64-bit on the major desktop OSes (mobile a plus, obviously) 3. real concurrency 4. libraries 5. build time for large projects ("compiles down to C++" makes me think this could be an issue) Most new languages fail at several of these, for years. You'll notice that I haven't mentioned language design at all.

srean 13y ago
It scores extremely, extremely well on 2. Regarding 3 it has had coroutines built into the language since the last 10~15 years, much before the language Go made it more mainstream. preemptive threads is more recent. It does have a stop the world garbage collector, which is not good for concurrent applications, but the semantics allows one to avoid creating garbage to a large extent. Libraries is chicken and egg, one needs higher level of adoption to drive this. 5 could be a legitimate concern, but I dont think its going to be any worse than Scala or C++ in this respect. As far as language design goes, Skaller the author is a well regarded PL theorist active on LTU. I am not saying this the best, end all language, but one that has enough interesting features that would be interest to the early-adopter rich crowd that we have here. It certainly has grabbed my eye balls
- jongraehl 13y ago
  Coroutines are nice, but don't provide concurrency (by which I mean simultaneous computation on >1 cpu - sorry if I got my terminology crossed up). Thanks for the recommendation. I respect LTU-respected language designers. I didn't know it was 15+ years old. Stop-the-world might be ok for batch compute work where I care about amortized cost (as long as the GC itself could use all my cores efficiently). I'd be interested in the debugger experience - since it compiles to C++, I'm a little scared.
  - srean 13y ago
    > (by which I mean simultaneous computation on >1 cpu - sorry > if I got my terminology crossed up). I think you meant parallelism there. Felix does have preemptive threads for that, but its a relatively new addition, so I expected it to be rough on the edges. You will probably be able to catch Skaller on LTU, ATS mailing list and of course on Felix's own mailing list. He can answer questions better than I can. I think you will have to debug the generated C++ because I dont think it preserves the corresponding Felix source lines by default. The good thing is that it supports functional style (though not restricted to it), so you can debug individual functions easily enough. Besides it has robust and flexible type system (way better than C++'s) that you can enlist to catch errors early. It does type deduction so you dont have to litter the code with types.

srean 13y ago

It scores extremely, extremely well on 2. Regarding 3 it has had coroutines built into the language since the last 10~15 years, much before the language Go made it more mainstream. preemptive threads is more recent. It does have a stop the world garbage collector, which is not good for concurrent applications, but the semantics allows one to avoid creating garbage to a large extent. Libraries is chicken and egg, one needs higher level of adoption to drive this. 5 could be a legitimate concern, but I dont think its going to be any worse than Scala or C++ in this respect. As far as language design goes, Skaller the author is a well regarded PL theorist active on LTU. I am not saying this the best, end all language, but one that has enough interesting features that would be interest to the early-adopter rich crowd that we have here. It certainly has grabbed my eye balls

jongraehl 13y ago
Coroutines are nice, but don't provide concurrency (by which I mean simultaneous computation on >1 cpu - sorry if I got my terminology crossed up). Thanks for the recommendation. I respect LTU-respected language designers. I didn't know it was 15+ years old. Stop-the-world might be ok for batch compute work where I care about amortized cost (as long as the GC itself could use all my cores efficiently). I'd be interested in the debugger experience - since it compiles to C++, I'm a little scared.
- srean 13y ago
  > (by which I mean simultaneous computation on >1 cpu - sorry > if I got my terminology crossed up). I think you meant parallelism there. Felix does have preemptive threads for that, but its a relatively new addition, so I expected it to be rough on the edges. You will probably be able to catch Skaller on LTU, ATS mailing list and of course on Felix's own mailing list. He can answer questions better than I can. I think you will have to debug the generated C++ because I dont think it preserves the corresponding Felix source lines by default. The good thing is that it supports functional style (though not restricted to it), so you can debug individual functions easily enough. Besides it has robust and flexible type system (way better than C++'s) that you can enlist to catch errors early. It does type deduction so you dont have to litter the code with types.