4 ms·

Is this actively being developed? I don't see an update for the past 8 months. From https://github.com/t1lang/t1lang.github.io/blob/master/NorthSec-20190516.pd

Is this actively being developed? I don't see an update for the past 8 months. From https://github.com/t1lang/t1lang.github.io/blob/master/NorthSec-20190516.pdf https://github.com/t1lang/t1lang.github.io/blob/master/North... slides, are telling for the language analysis to see why they think it's necessary to develop this: Go: - Only with TinyGo* - Limited language/runtime support* - "support for goroutines and channels is weak" - Maps can ony have up to 8 (eight!) entries - GC: only for ARM, other platforms "will just allocate memory without ever freeing it" (but GC is required for proper string management) Rust: - Inherits all memory-safety features of Rust - Heap is optional - But without the heap, everything is allocated on the stack - Supports ARM Cortex-M and Cortex-R, RISCV, and MSP430 (experimental) - Not other architectures that LLVM does not support - Typically more stack-hungry than C - Lots of automatic magic Forth: - Many incompatible implementations - It's more a concept than a language (there is an ANSI standard) - You are support to "write your own Forth" - Very compact, with low RAM usage - Even less safe than C and not portable Given all this, is it really cheaper to write a new language than add architecture support to LLVM? I also don't understand the "lots of automatic magic", is that referring to the generics and/or type inference in Rust? Additionally, if not using Heap (the criticism about Heap being optional), where else would you allocate memory besides the Stack? Can someone who does embedded explain that? btw, on the magic bit the T1 design does go on to talk about Generics support and a rich type system. Edit: this comment sounds too negative, and that wasn't really my intent. I just wanted to better understand some of the considerations that were used in deciding to make this new language.

snops 7y ago
I'd be interested to see the comparison against zig[1], which I am eying up as a quite interesting language for embedded development. I think the comparable features would be: - No automatic magic, anything that looks like a function or memory allocation is, anything that doesn't, isnt. - Good compile time code generation capabilities including reflection, much nicer than C macros. - Runtime safety features, such as bounds checking, but not as intrusive as Rust's borrow checker (which makes less sense for single threaded embedded applications). These can be turned off in release builds. - Very good C interop for use with manufacturer HAL libraries etc, includes a C compiler. - Better error handling than C, without needing full exceptions, instead the "try" and "defer" macros nicely replace C's "goto" for error handling[2]. - No garbage collection - Embedded is a first class target, unlike Go/TinyGo - Working async support on all platforms. - Sadly not as popular as others, one full time developer currently I think. [1] https://ziglang.org/ https://ziglang.org/ [2] https://eli.thegreenplace.net/2009/04/27/using-goto-for-error-handling-in-c https://eli.thegreenplace.net/2009/04/27/using-goto-for-erro...
- bluejekyll 7y ago
  I’m familiar with Zig. All of those features you list are also Rust’s capabilities. Is there a reason you don’t see Rust as an option in this space?
  - pron 7y ago
    There are a few. Rust is a very complex language; it's essentially a modern take on C++, and it fully adopts C++'s design philosophy. This has several implications for embedded development. For one, it makes it hard to write custom compilers and direct backends (AFAIK Rust currently only targets LLVM and WASM). For another, it makes certain formal and informal analyses and guarantees hard (this is perhaps ironic given Rust's emphasis on sound safety, but sound static analysis tools are easier to write for C). It appeals to those who already like C++, but embedded developers aren't crazy about C++; C still rules that space. Zig is a very simple language. Its strength is not in the features it has, but in the features it lacks. Also, Zig encourages stricter control over allocation than Rust, and it's C interop is virtually seamless. Zig is very young and may well end up disappointing, but its careful selection of features that provide what seems to me to be a great combination of power and simplicity (a single feature represented by a single keyword does the work of generics, value templates, constexprs and macros, all without the complications macros introduce). Anyway, I find it to be a very interesting take on what modern low-level programming can be.
    - bluejekyll 7y ago
      > Rust is a very complex language; it's essentially a modern take on C++, and it fully adopts C++'s design philosophy. This is a false and inflammatory statement, and unhelpful. It's more complex than C, but has very different set of features and type capabilities from C++ that makes it far simpler. Even for C, I would say it really is a different set of complexity. Rust brings that complexity to the fore-front, whereas C and C++ both have a significant amount of hidden complexity. > It appeals to those who already like C++ Perhaps, but I absolutely abhor C++ (after years of working with it) and completely love Rust, so :shrug: > Zig is a very simple language It is. It also doesn't make many of the same safety guarantees as Rust. So there are trade-offs. > I find it to be a very interesting take on what modern low-level programming can be. As do I! Though, I do think people keep looking for greener fields unnecessarily.

snops 7y ago

I'd be interested to see the comparison against zig[1], which I am eying up as a quite interesting language for embedded development. I think the comparable features would be: - No automatic magic, anything that looks like a function or memory allocation is, anything that doesn't, isnt. - Good compile time code generation capabilities including reflection, much nicer than C macros. - Runtime safety features, such as bounds checking, but not as intrusive as Rust's borrow checker (which makes less sense for single threaded embedded applications). These can be turned off in release builds. - Very good C interop for use with manufacturer HAL libraries etc, includes a C compiler. - Better error handling than C, without needing full exceptions, instead the "try" and "defer" macros nicely replace C's "goto" for error handling[2]. - No garbage collection - Embedded is a first class target, unlike Go/TinyGo - Working async support on all platforms. - Sadly not as popular as others, one full time developer currently I think. [1] https://ziglang.org/ https://ziglang.org/ [2] https://eli.thegreenplace.net/2009/04/27/using-goto-for-error-handling-in-c https://eli.thegreenplace.net/2009/04/27/using-goto-for-erro...

bluejekyll 7y ago
I’m familiar with Zig. All of those features you list are also Rust’s capabilities. Is there a reason you don’t see Rust as an option in this space?
- pron 7y ago
  There are a few. Rust is a very complex language; it's essentially a modern take on C++, and it fully adopts C++'s design philosophy. This has several implications for embedded development. For one, it makes it hard to write custom compilers and direct backends (AFAIK Rust currently only targets LLVM and WASM). For another, it makes certain formal and informal analyses and guarantees hard (this is perhaps ironic given Rust's emphasis on sound safety, but sound static analysis tools are easier to write for C). It appeals to those who already like C++, but embedded developers aren't crazy about C++; C still rules that space. Zig is a very simple language. Its strength is not in the features it has, but in the features it lacks. Also, Zig encourages stricter control over allocation than Rust, and it's C interop is virtually seamless. Zig is very young and may well end up disappointing, but its careful selection of features that provide what seems to me to be a great combination of power and simplicity (a single feature represented by a single keyword does the work of generics, value templates, constexprs and macros, all without the complications macros introduce). Anyway, I find it to be a very interesting take on what modern low-level programming can be.
  - bluejekyll 7y ago
    > Rust is a very complex language; it's essentially a modern take on C++, and it fully adopts C++'s design philosophy. This is a false and inflammatory statement, and unhelpful. It's more complex than C, but has very different set of features and type capabilities from C++ that makes it far simpler. Even for C, I would say it really is a different set of complexity. Rust brings that complexity to the fore-front, whereas C and C++ both have a significant amount of hidden complexity. > It appeals to those who already like C++ Perhaps, but I absolutely abhor C++ (after years of working with it) and completely love Rust, so :shrug: > Zig is a very simple language It is. It also doesn't make many of the same safety guarantees as Rust. So there are trade-offs. > I find it to be a very interesting take on what modern low-level programming can be. As do I! Though, I do think people keep looking for greener fields unnecessarily.