Earlier quoted context omitted.
wait, you don't like putting your List inside your Arc inside your Cell ?? ;)
Nobody puts Baby in the Box .
Dirty Dancing quote, right? ;)
Ark – A modern systems programming language
21–30 of 55 posts
Re: Ark – A modern systems programming language
#22Earlier 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…
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 tha…
What, specifically, would you want to have Rust do instead regarding lifetimes?
It sounds like you don't want memory safety without garbage collection, based on your last paragraph, and that's totally fine! My use cases aren't necessarily your use cases, and I don't want to claim that everyone who truly doesn't care about zero-overhead memory safety is wrong. But I think it's defensible that memory safety is an important feature for many projects (for example, the ones I work on) in 2015, even if it results in an additional learning curve. The disease we're trying to cure is a never-ending stream of security vulnerabilities and crashes in systems code, and none of the attempts to solve the problem that have existed so far have worked.
Re: Ark – A modern systems programming language
#23Earlier quoted context omitted.
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).
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…
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.
Re: Ark – A modern systems programming language
#24Here 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.
Indeed it is written in Go, after all.
Re: Ark – A modern systems programming language
#25Earlier 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…
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 tha…
I feel like the explicit lifetime annotations just move the invariants from the comments to the code. So I feel like it's a good thing to make explicit. I could be wrong as projects get larger though.
Though I do feel a bit let out after reading http://cglab.ca/~abeinges/blah/turpl/_book/vec.html which implements Vec from scratch, as it's not super simple.
But really, that would be impossible in Go, just as tricky in C++ (if you make it stl compatible), and impossible in implement generically without lots of void* stuff in C, so I guess I wasn't sure what I was expecting. It's a pain to implement fundamental data-structures I guess.
Still, if you've got anything new to say, go ahead and say it.
Re: Ark – A modern systems programming language
#26Could 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.
Re: Ark – A modern systems programming language
#27Earlier quoted context omitted.
wait, you don't like putting your List inside your Arc inside your Cell ?? ;)
You need those for memory safety. It is very true that you don't need Rust's memory safety features, such as Arc and Cell, if you don't want memory safety, but it's also not a very interesting observation.
There are alternative mechanisms that do not use Cell but still provide safe mutation of pointer-free data. Cyclone had one, and IIRC Rust itself even had one before a type system simplification.
Re: Ark – A modern systems programming language
#28Earlier quoted context omitted.
You need those for memory safety. It is very true that you don't need Rust's memory safety features, such as Arc and Cell, if you don't want memory safety, but it's also not a very interesting observation.
There are alternative mechanisms that do not use Cell but still provide safe mutation of pointer-free data. Cyclone had one, and IIRC Rust itself even had one before a type system simplification.
Sure, and I'd be interested in exploring how those might be integrated into Rust in the future. Carving out subsets of pointer-free data seems pretty powerful.
(It doesn't seem like the language in the OP is interested in memory safety though.)
Re: Ark – A modern systems programming language
#29Re: Ark – A modern systems programming language
#30>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.