Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ark – A modern systems programming language

ark-lang.org

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Ark – A modern systems programming language

#31

Post by vardump »

kibwen wrote: post #6
webkike wrote: post #2

If all this is Rust with the syntax of go, aw heck that's all I ever wanted anyway.

Although some bits of syntax are reminiscent of Rust, semantically it's not Rust in the slightest: "Ark is not a garbage collected language, therefore when you allocate memory, you must free it after you are no longer using it. We felt that, as unsafe as it is to rely on the user to manage the memory being allocated, performance takes a higher precedence. Although garbage collection makes things fool-proof and remove…

Well, while I see the advantages of manual memory management as an embedded and kernel driver developer, one should understand manual memory allocation and freeing are very expensive and unpredictable operations. Very, very far from "zero overhead". There's usually no way you can afford to allocate memory while processing an interrupt request! It's simply too unpredictably slow. (Not to mention many synchronization mechanisms memory management usually requires, like mutexes, are simply not feasible at IRQ level. No process switching is possible, so a deadlock occurs.)

But some GC schemes could be fast enough even from an IRQ handler, if memory allocation is just something simple like an atomic add to top of heap pointer. As long as non-interrupt level routines, potentially running on an another core, have enough time to clean up the garbage.

Manual memory management seems to be at the end of its road when it comes to high core count systems, with tens or hundreds of CPU cores. Allocation and application side object lifetime synchronization and management will simply saturate any inter-core communication mechanism, limiting scalability. GC should be able to get around that limitation. At that scale, you could already dedicate one or more cores just for cleaning garbage.

Re: Ark – A modern systems programming language

#32

Post by [deleted] »

vardump wrote: post #26

Could this be used for embedded development? Currently C is used pretty much universally for this purpose. While C is better than straight assembler, it seems to be very prone for bugs, especially when there are multiple developers and over time in maintenance phase. Something safer is desperately needed for embedded firmware development. Lack of such a language is already affecting physical safety of end user device…

[deleted]

Re: Ark – A modern systems programming language

#33

Post by minthd »

vardump wrote: post #26

Could this be used for embedded development? Currently C is used pretty much universally for this purpose. While C is better than straight assembler, it seems to be very prone for bugs, especially when there are multiple developers and over time in maintenance phase. Something safer is desperately needed for embedded firmware development. Lack of such a language is already affecting physical safety of end user device…

If you're willing to be stuck with a specific architecture(xcore by xmos) ,they offer their XC language and tools ,which are very good your requirements:

a actor model like language for the xcore mcu. supports actors(paralell tasks with communication chnnels, pattern matching on "events", assigning actors to diffeent "cores"-hw threads, boundary checks on arrays, special pointers(aliased/restricted) with good error messages, type checking, mostly compatible with c(except pointers)

Debugging is very good: Regular debugger, xScope - a virtual scope/logic-analyzer with access to internal states.XTA Timing analyzer - can determine(i think statically) the worse case timing between any 2 points in code. xScope and XTA might also work in simulation mode.

This complements well with their architecture ,which basically allows real-time without jitter, and with very high accuracy/speed, through usage of multiple virtual cores.

Very well fitted to industrial environment, and maybe they would be willing to add your request for memory duplication of variables , because it fits their niche.

Re: Ark – A modern systems programming language

#34

Post by michaelmior »

notduncansmith wrote: post #15
protomyth wrote: post #12

Here the example on the site: func main(): int { mut i := 0; for i I'm really curious about 2 things: that for seems to really be a while . Why := in the declare and = in the assignment?

Perhaps the author was inspired by the Go language, as those are both Go-isms: Go's only loop is a for loop, and := tells the compiler to infer the variable type when initializing. In fact, this snippet is only a few deviations away from being valid Go code.

:= isn't really stating to infer the type (although this happens) but a way to differentiate variable initialization with assignment. When using := the variable is created while = is just a regular assignment. Having these as separate operators prevents errors like this:

    foo := 3
    fooo = 4
The second line is invalid because fooo does not exist.

Re: Ark – A modern systems programming language

#35

Post by vardump »

minthd wrote: post #33
vardump wrote: post #26

Could this be used for embedded development? Currently C is used pretty much universally for this purpose. While C is better than straight assembler, it seems to be very prone for bugs, especially when there are multiple developers and over time in maintenance phase. Something safer is desperately needed for embedded firmware development. Lack of such a language is already affecting physical safety of end user device…

If you're willing to be stuck with a specific architecture(xcore by xmos) ,they offer their XC language and tools ,which are very good your requirements: a actor model like language for the xcore mcu. supports actors(paralell tasks with communication chnnels, pattern matching on "events", assigning actors to diffeent "cores"-hw threads, boundary checks on arrays, special pointers(aliased/restricted) with good error m…

Sounds very good and interesting. But vendor lock-in and architecture restriction is unacceptable. Embedded firmware development needs something that can be targeted to existing platforms.

Re: Ark – A modern systems programming language

#37

Post by yoklov »

vardump wrote: post #31
kibwen wrote: post #6

Earlier quoted context omitted.

Although some bits of syntax are reminiscent of Rust, semantically it's not Rust in the slightest: "Ark is not a garbage collected language, therefore when you allocate memory, you must free it after you are no longer using it. We felt that, as unsafe as it is to rely on the user to manage the memory being allocated, performance takes a higher precedence. Although garbage collection makes things fool-proof and remove…

Well, while I see the advantages of manual memory management as an embedded and kernel driver developer, one should understand manual memory allocation and freeing are very expensive and unpredictable operations . Very, very far from "zero overhead". There's usually no way you can afford to allocate memory while processing an interrupt request! It's simply too unpredictably slow. (Not to mention many synchronization…

Sure, malloc/free are slow, but in realtime code (and probably embedded too, but I've never worked there) you allocate out of arena to get around that.

Suddenly your memory allocation routine is a pointer addition, and you don't need garbage collection either. Deallocation is just as fast as well, it just happens in one block.

It requires a bit of care in the code using it to not grow memory in an unbounded fashion, but this isn't really hard once you get used to it.

Re: Ark – A modern systems programming language

#38

Post by dom96 »

vardump wrote: post #26

Could this be used for embedded development? Currently C is used pretty much universally for this purpose. While C is better than straight assembler, it seems to be very prone for bugs, especially when there are multiple developers and over time in maintenance phase. Something safer is desperately needed for embedded firmware development. Lack of such a language is already affecting physical safety of end user device…

I think that Nim satisfies many of the items on your list. Have you taken a look at it?

Specifically, it's a very good C replacement as it compiles to C. So you can easily run it on all of those embedded architectures.

While I must admit that it leans towards using a GC for memory safety, you can disable it and use Nim as a more readable C easily. If you're brave you can attempt to use Nim's GC in embedded hardware too, it's very flexible.

If you want statically guaranteed memory safety then do check out Rust, I'm assuming you already have though and dismissed it for some reason.

Re: Ark – A modern systems programming language

#39

Post by vardump »

yoklov wrote: post #37
vardump wrote: post #31

Earlier quoted context omitted.

Well, while I see the advantages of manual memory management as an embedded and kernel driver developer, one should understand manual memory allocation and freeing are very expensive and unpredictable operations . Very, very far from "zero overhead". There's usually no way you can afford to allocate memory while processing an interrupt request! It's simply too unpredictably slow. (Not to mention many synchronization…

Sure, malloc/free are slow, but in realtime code (and probably embedded too, but I've never worked there) you allocate out of arena to get around that. Suddenly your memory allocation routine is a pointer addition, and you don't need garbage collection either. Deallocation is just as fast as well, it just happens in one block. It requires a bit of care in the code using it to not grow memory in an unbounded fashion,…

> Suddenly your memory allocation routine is a pointer addition, and you don't need garbage collection either. Deallocation is just as fast as well, it just happens in one block.

That's one of the techniques I apply. I have also some other tricks with different trade-offs up in my sleeve.

This is primitive garbage collection. Because compaction / sweeping phase is simply discard all, no marking phase is required.

Sometimes you get a lot of interrupts in a sequence, and if the lower priority code didn't have a chance to clean up the arena, you lose data.

Interrupts can also occur at any point, unless you disable them. But you can't keep them disabled for very long. Maybe long enough that you check IRQ handler is not currently running on another core. If not, swap an arena pointer IRQ routine uses, enable interrupts again and start to process the previously pointed arena buffer.

> It requires a bit of care in the code using it to not grow memory in an unbounded fashion, but this isn't really hard once you get used to it.

This. The babysitting code and care you need for this technique.

Re: Ark – A modern systems programming language

#40

Post by zem »

kibwen wrote: post #6
webkike wrote: post #2

If all this is Rust with the syntax of go, aw heck that's all I ever wanted anyway.

Although some bits of syntax are reminiscent of Rust, semantically it's not Rust in the slightest: "Ark is not a garbage collected language, therefore when you allocate memory, you must free it after you are no longer using it. We felt that, as unsafe as it is to rely on the user to manage the memory being allocated, performance takes a higher precedence. Although garbage collection makes things fool-proof and remove…

> Rust is still the only competitor in the space of zero-overhead memory-safe languages.

the only mainstream competitor, perhaps; ATS does a good job of it too [http://www.ats-lang.org/]

Post reply on HN