Live data from Hacker News

Deca - a systems language based on modern PL principles

code.google.com

51–59 of 59 posts

Re: Deca - a systems language based on modern PL principles

#51
post #49
post #32

Earlier quoted context omitted.

Yes I know of Rust and think it's very interesting. For most system level programming it should be an excellent choice. It's great that the dearth of systems capable languages is something that is becoming less of an issue. But when i was making the list I was thinking about if the language could possibly be used in an embed context. C is still king there. Rust I believe, is partially garbage collected in a way that…

Garbage-collected languages can still be fast on microcontrollers. When there isn't a lot of memory it only takes a few milliseconds to run a collection cycle. The problem would be when you need real-time and can't deal with the jitter.

Can modern garbage collectors deal with almost full heaps? There is an urban legend that GC only shows good performance with 50% of memory free, which is certainly unacceptable for microcontrollers. Also, most garbage collectors require boxing which prevents tight packing of heap data. Are all these problems already solved somewhere? Jitter is the least important issue as there are a lot of works on realtime collectors.

Re: Deca - a systems language based on modern PL principles

#52
post #25

Nice to see something actually trying a CLOS-style object system. There are good ideas in there that don't get enough presence in more recent language efforts.

I wonder what happened to SELF-like object systems (slots, prototypes and all that).

JavaScript

Re: Deca - a systems language based on modern PL principles

#53
post #40
post #19

I keep a (small) list of active awesome and interesting alternatives to C. Cyclone has been mentioned already, adding Deca now. the other two I know are: * ATS http://www.ats-lang.org/#what_is_ats_good_for * Clay http://claylabs.com/clay/

You may be interested in this (see the section about Nothing and Maru): http://www.vpri.org/pdf/tr2011004_steps11.pdf A lot of work there has been done in completely replacing the entire current software development stack with something more reasonable (in terms of size/bloat and design). They aim for a full system (frontend user apps to the metal) in under 20,000 lines of code. Check it out. Quite the alternative to…

Thanks yeah, I've heard of VPRI and read a few of thier papers and seen some of their videos. Alan Kay is one of my heroes and I really do think that the idea of breaking down problems to domains and working within that is very important going forward.

Re: Deca - a systems language based on modern PL principles

#54
post #49

Earlier quoted context omitted.

Garbage-collected languages can still be fast on microcontrollers. When there isn't a lot of memory it only takes a few milliseconds to run a collection cycle. The problem would be when you need real-time and can't deal with the jitter.

Can modern garbage collectors deal with almost full heaps? There is an urban legend that GC only shows good performance with 50% of memory free, which is certainly unacceptable for microcontrollers. Also, most garbage collectors require boxing which prevents tight packing of heap data. Are all these problems already solved somewhere? Jitter is the least important issue as there are a lot of works on realtime collecto…

Unfortunately I've no idea how the various GCs deal with the trade-offs; my point is that (memory bandwidth / memory size) in these embedded things is high enough that garbage-collection is fast, contrary to popular wisdom. I was looking at OCAPIC for an example, which has a very simple stop and copy gc which takes 1.5ms to collect. The trade-offs would have some 2× impact on some metric, but not change the feasibility of the thing.

Re: Deca - a systems language based on modern PL principles

#55
post #54

Earlier quoted context omitted.

Can modern garbage collectors deal with almost full heaps? There is an urban legend that GC only shows good performance with 50% of memory free, which is certainly unacceptable for microcontrollers. Also, most garbage collectors require boxing which prevents tight packing of heap data. Are all these problems already solved somewhere? Jitter is the least important issue as there are a lot of works on realtime collecto…

Unfortunately I've no idea how the various GCs deal with the trade-offs; my point is that (memory bandwidth / memory size) in these embedded things is high enough that garbage-collection is fast, contrary to popular wisdom. I was looking at OCAPIC for an example, which has a very simple stop and copy gc which takes 1.5ms to collect. The trade-offs would have some 2× impact on some metric, but not change the feasibili…

My point is that 2x slowdown is critical for many systems - embedded, gamedev, HPC, systems software. Controlled measurement of slow-down and heap slack caused by GC is beyond capabilities of most embedded devs. Academia provided us with some experimental results saying that in half-empty heaps GC is lightning fast, but there's no (recent) data for 90% full heaps and for very large heaps.

Re: Deca - a systems language based on modern PL principles

#56
post #52

Earlier quoted context omitted.

I wonder what happened to SELF-like object systems (slots, prototypes and all that).

JavaScript

I mean high-performance implementations. Techniques to (statically) compile prototypes into efficient code were developed, but they are largely irrelevant to Javascript. High-performance modern implementations of JS rely on tracing JIT.

Re: Deca - a systems language based on modern PL principles

#57
post #49
post #32

Earlier quoted context omitted.

Yes I know of Rust and think it's very interesting. For most system level programming it should be an excellent choice. It's great that the dearth of systems capable languages is something that is becoming less of an issue. But when i was making the list I was thinking about if the language could possibly be used in an embed context. C is still king there. Rust I believe, is partially garbage collected in a way that…

Garbage-collected languages can still be fast on microcontrollers. When there isn't a lot of memory it only takes a few milliseconds to run a collection cycle. The problem would be when you need real-time and can't deal with the jitter.

There are real time GC working on mission critical embedded scenarios in real life.

One example is one of the french radar system for missile defense, Normandie.

Re: Deca - a systems language based on modern PL principles

#58
post #36

Earlier quoted context omitted.

> Whichever way you want to look at it one thing the Go team can't say is that writing an OS is a "non-systems" problem. I do agree with that. (Perhaps it would be helpful to apply the high/low qualifier to systems languages?) > Ideally these would be disjoint sets (in my opinion) but consider this: ASM -> C -> C++ -> Java -> ... looks like a continuum if you're writing any kind of Java code, but there's a sharp disc…

Personally I'd sooner map the somewhat fuzzier concept of "applications language" onto that supposed continuum instead. It would put Go in a clearer category, since it seems to compete with Java and Python better than it does with C. I still don't imagine an OS being written in a non-systems application language, since you've got drivers and performance critical subsystems to write and things like GC to worry about f…

Have a look at Spin or Native Oberon, just to name two operating systems written in GC enabled languages.

Before C existed, there were already operating systems written in PL/I and ALGOL, which provide better type safety and memory management as C or C++.

Unix and C success has regressed what meant to be a proper systems programming language.

There is even a paper from Adele Goldberg about this phenomena, unfortunately I cannot recall the title now.

Re: Deca - a systems language based on modern PL principles

#59
post #52

Earlier quoted context omitted.

JavaScript

I mean high-performance implementations. Techniques to (statically) compile prototypes into efficient code were developed, but they are largely irrelevant to Javascript. High-performance modern implementations of JS rely on tracing JIT.

Pretty sure polymorphic inline caches are standard fare in both Javascript and other VMs (JVM, CLR, etc.). What other techniques are you referring to?
Post reply on HN