7 ms·
Ark – A modern systems programming language
- webkike 11y agoIf all this is Rust with the syntax of go, aw heck that's all I ever wanted anyway.
- exacube 11y agowait, you don't like putting your List<> inside your Arc<> inside your Cell<> ?? ;)
- kibwen 11y agoThe whole point of smart pointer types like Arc and Cell is that they give you fine-grained control over the capabilities of your data. If you don't need such fine-grained control, then Rust probably isn't the language you're looking for. :)
- rubiquity 11y agoNobody puts Baby in the Box<>.
- pcwalton 11y agoYou 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.
- cwzwarich 11y agoThere 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.
- pcwalton 11y agoSure, 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.)
- kibwen 11y agoAlthough 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.md#managing-memory https://github.com/ark-lang/ark-docs/blob/master/REFERENCE.m... 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 11y agoI 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.
- pcwalton 11y agoIt doesn't look like it's memory safe.
- felixangell 11y agoUnlike Rust, this is something we aren't focusing on. I just really like Rust, so we borrowed a lot of the syntax.
- pcwalton 11y agoYup, and that's a totally legitimate decision IMHO. Best of luck with your project :)
- qznc 11y agoA comparison with Rust would be nice.
- trollsalad 11y agoLooks 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 11y agoRust 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 11y agoMind 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.
- jflatow 11y agoNot to be confused with Arc: http://arclanguage.org/ http://arclanguage.org/
- rubiquity 11y agoHow 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 11y agobugs in C are often a lot less obvious then just malloc and free usage.
- protomyth 11y agoHere 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 11y agoPerhaps 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 11y agoTheir compiler is written in Go. See https://github.com/ark-lang/ark https://github.com/ark-lang/ark
- warmwaffles 11y agoYou 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 11y agoI'm not blaming them, just saying there's evidence the authors are quite familiar with Go. =P
- fapjacks 11y agoIndeed it is written in Go, after all.
- michaelmior 11y ago:= 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.
- vardump 11y agoCould 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.
- deleted 11y ago[deleted]
- minthd 11y agoIf 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.
- topkekz 11y ago>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 11y agoI've never really found those a problem, I imagine this is more of a subjective thing.
- andrewchambers 11y agoI 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 11y agoIt 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 11y agoI 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 11y agolol, thanks will do :)
- vardump 11y agoSo you're just 17. Heh. I've been working in this field for more than your age. Keep up the good work, I can't wait with what you'll come up with later! Goes to write some more bug prone C-based device driver code...