

Ark – A modern systems programming language - felixangell
http://ark-lang.org/

======
vardump
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 devices.

Something that can run for example on a microwave oven, car engine control,
digital thermometer and industrial machinery.

Maybe I'm missing some, but some of the most important wish list items I can
think of right away:

\- High readability, Golang-like "understandability"

\- Anywhere between 1 - 256 kB of RAM, 2 - 1024 kB of program ROM.

\- Must have C-like code density and performance, but a small loss is
acceptable in exchange for better safety.

\- Ability to implement IRQ service routines, etc. low level code.

\- Array access, pointer and type safety.

\- Debugging support... this is a tricky one.

\- Migration assist from C code. Doesn't need to be perfect, just to assist
where ever feasible.

\- Would be very nice: Some language level support for duplicating and
checking critical variables in memory. Like those for controlling servos etc.
physical. To improve end user physical safety.

Targets should include at least, in order of importance:

\- ARM thumb-2 (like Cortex M0)

\- Altera NIOS 2 (must be possible to modify easily to target custom
instructions)

\- 8051

Various Atmel architectures, MIPS and OpenRISC would also be nice.

But I guess it comes down to LLVM support for those platforms.

~~~
dom96
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.

~~~
vardump
Yeah, Nim is one of the languages I'm interested in.

> 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.

Yes, this is indeed a huge plus for this application.

>If you're brave you can attempt to use Nim's GC in embedded hardware too,
it's very flexible.

I'm not going to be that brave. :)

> 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.

Static guarantees are good, less code and checking at runtime. I haven't
dismissed Rust in any way. One huge bonus point for Rust is that it has a
major organization, Mozilla, behind it. Of course, the fact that Mozilla is
primarily interested to develop a web browser can be a liability. In the
future, Rust might take a path that's less suitable for embedded firmware.

------
jflatow
Not to be confused with Arc:
[http://arclanguage.org/](http://arclanguage.org/)

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

~~~
kibwen
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 removes a significant amount of workload from the user,
it inhibits the performance we were going for."_

[https://github.com/ark-lang/ark-
docs/blob/master/REFERENCE.m...](https://github.com/ark-lang/ark-
docs/blob/master/REFERENCE.md#managing-memory)

This is the usual false dichotomy that languages subscribe to, where they
presume that manual and unsafe memory management is the only alternative to
dynamic and safe memory management. But Rust's secret sauce is that memory
management is static and safe, thanks to linear types and the borrow checker.
Rust is still the only competitor in the space of zero-overhead memory-safe
languages.

~~~
donuteaters
I really wish Rust was as great as you advocates say, but that has not been my
experience. For background: I've been following it for a while now. About a
year or so ago, I dove it into with enthusiasm, but I got bit when the sigils
went away, and so I backed off until the 1.0 release. After the 1.0 release, I
figured it was ready so I spent another couple of weeks learning the new way
of things and really hoping that it would be my replacement for C and C++. I
really wanted Rust to be great.

Unfortunately, it has lots of warts that have sent me crawling back to C++.
Addressing the particular item you're talking about here, manually specifying
lifetimes of objects is a cure that's worse than the disease. It's great when
the compiler infers everything for you, but I'm never going to be able to
explain the syntax or semantics of those ugly 'a marks to my coworkers who
aren't interested in programming language theory.

Anyways, I've been tempted to write a full blog post listing all of my Rust
complaints, but I figured it's better to just quietly let you guys enjoy your
thing. However, whenever I see these advocacy posts from you and the other
Rust honchos, I can't help but scream a little bit inside. It's really not as
good as it could've been.

To be really specific: it's great that you got "zero-overhead memory-safety",
but I can't even implement fundamental data structures without using unsafe
blocks and lifetime annotations.

~~~
kibwen
Don't hold back! :) Criticism helps us improve, as long as you can make it
constructive and make at least a cursory effort to understand Rust's goals. As
I've said elsewhere, if memory safety isn't a priority for your product then
Rust may not be for you.

As for the lifetime annotations, we _could_ be extending lifetime elision to
more places, including to struct definitions, if people come up with rules
that are easy enough to understand. I'd probably be for it, but there are
others who think that if you go too far toward removing lifetime annotations
then you actually make programs more difficult to understand and the language
harder to teach. But that was also the argument against our current lifetime
elision rules, which are pretty fantastic in retrospect, so I'm not
particularly swayed.

~~~
Jweb_Guru
I hate our current lifetime elision rules, as do many people who have been
using Rust for a while. There was an RFC (which was closed) to add some back.
IMO, the rules largely exist for the sake of making short examples look less
threatening, rather than because they actually make Rust more usable.

------
protomyth
Here the example on the site:

    
    
      func main(): int {
          mut i := 0;
    
          for i < 5 {
              printf("i: %d\n", i);
              i = i + 1;
          }
    
          return 0;
      }
    

I'm really curious about 2 things: that _for_ seems to really be a _while_.
Why := in the declare and = in the assignment?

~~~
notduncansmith
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.

~~~
AYBABTME
Their compiler is written in Go.

See [https://github.com/ark-lang/ark](https://github.com/ark-lang/ark)

~~~
warmwaffles
You also need to remember that at one point Go's compiler was written in C, as
with rust. It's all apart of the language evolution.

~~~
AYBABTME
I'm not blaming them, just saying there's evidence the authors are quite
familiar with Go. =P

------
rubiquity
How long before someone releases another language "to fix all the dangerous
parts of C" \-- but the twist is that this language is just C but it forces
you into a `git add --patch`-style menu that makes you double check all your
usage of malloc and free every time you compile?

~~~
98Windows
bugs in C are often a lot less obvious then just malloc and free usage.

------
andrewchambers
I don't understand how a language can be a year old and have 3000 commits, but
have so few tests in its implementation.

That is an instant red flag for me.

~~~
felixangell
It started off as a side project by myself, I'm a student so I work on it
every now and then, but I'm 17 so I have bigger things to prioritise like my
education. The large commit count is due to a certain someone _cough_ Vedant
_cough_ making several accounts and doubling the commit history when he re-
authors his commits.

The fact that it's a year old is because the language has changed loads in the
past, since I considered it a side-project that I would just play around with.
However, after I stuck to something, it gained a bit more popularity and
people started to help me out with it. Now we have ported to Go, with a decent
sized team working on it (when we can).

~~~
andrewchambers
I recommend increasing the number of tests significantly, this is really
important. A compiler is one of the easiest bits of software to test, so
mastering good practice here will help you in the future.

It is impressive if you are only 17! Keep it up.

~~~
felixangell
lol, thanks will do :)

------
qznc
A comparison with Rust would be nice.

~~~
trollsalad
Looks like it's basically Rust without the ownership, borrow checking, and a
few other things. Think of C/Go(?) with a rust syntax, and a few more higher
level things like boundary checking, unicode support, etc (I'm aware Go has
unicode support, I mean C).

~~~
markus2012
Rust provides a good solution to C++ legacy cruft, complexity, undefined
behavior, data races and provides some nice new language features like ADTs,
traits, etc. I find it ties the language feature together with a beautiful and
well thought out syntax.

Still, because of tooling, direct C++ interop and familiarity we would have
stuck with C++. The killer feature that elevates Rust above everything else -
and made us switch - is the borrow checker.

~~~
kibwen
Mind if I ask who "we" is? I love hearing feedback from groups of people using
Rust from their own projects, and at the moment I'm especially interested in
people using Rust for their jobs. Feel free to send me an email to the address
in my profile if you'd like to continue this discussion without derailing this
thread.

------
topkekz
> _Our goal is to write a systems programming language that adopts many modern
> concepts and advancements in the field of compilers and language design over
> the past 43 years._

But they still kept = for assignent and the very ugly == for comparaison. Into
the trash it goes.

~~~
felixangell
I've never really found those a problem, I imagine this is more of a
subjective thing.

