5 ms·

I am genuinely wondering, what is (or could you point me to) the alternative with the following properties: - Compiled, type-safe and available for armv6. - S

I am genuinely wondering, what is (or could you point me to) the alternative with the following properties: - Compiled, type-safe and available for armv6. - Simple semantics: Rust and Ada are complex (C++-ish) and it gets hard to limit the number of memory allocations/accesses as well as data copies going on. - Tooling and discoverability: Man pages and Emacs with a few modes that are easy to setup beats anything I've tried so far. I understand that C has shortcomings when it comes to safety/security and even lacks features that would make programming certain things easier, but what do you suggest I use when I want to write a UNIX daemon that needs to transfer a boatload of data from disk over the network and vice-versa? I personally like it, I find it to be clear and concise, a little tedious but at the price of giving me fine grained control over the data in memory: I just have to be careful with that.

nickpsecurity 11y ago
The problem is, outside Ada and Rust, there isn't much of anything that's maintained because people stayed rejecting anything but C. I will post this on Ada so you can see (a) a nice survey of problems that show up and (b) how it systematically counters them. http://www.adacore.com/uploads/technical-papers/SafeSecureAdav2015-covered.pdf http://www.adacore.com/uploads/technical-papers/SafeSecureAd... The best candidates for simpler ones were Wirth-like languages, esp Modula-3. I used to recommend Delphi as it was a Pascal alternative to Visual C++ whose apps rarely crashed. Free Pascal succeed w/ Lazaurus IDE succeeded it w/ tons of hardware support. Component Pascal w/ Blackbox is still active AFAIK. D is quite active. Some Modula-2 benefits https://news.ycombinator.com/item?id=9640126 https://news.ycombinator.com/item?id=9640126 Modula-3 features https://en.wikipedia.org/wiki/Modula-3 https://en.wikipedia.org/wiki/Modula-3 Note: Fast to compile, fast to run, easy to read, easy to integrate, optional GC, optional OOP... why we need C and C++ again? Outside legacy systems... Free Pascal http://www.freepascal.org/ http://www.freepascal.org/ Component Pascal https://en.wikipedia.org/wiki/Component_Pascal https://en.wikipedia.org/wiki/Component_Pascal D language (C/C++ successor) https://en.wikipedia.org/wiki/D_%28programming_language%29 https://en.wikipedia.org/wiki/D_%28programming_language%29 Julia http://julialang.org/ http://julialang.org/ Note: It's a language for scientific programming but it's worth considering given speed and C support. On functional side, people are writing OS's in Haskell, Ocaml, and so on. OcaPic put Ocaml on 8-bitters. ATS Language was used for drivers and 8-bitters. RED/System is like LISP w/out parenthesis for system programming with ability to make DSL's. Any such language can have safety checks built in or output something for analysis. So, even functional languages are performing acceptably in places where C used to be required. Just need more people investing into any trouble spots. Someone could also pick up the code of Popcorn, Cyclone, or another safer C to develop it. Cyclone is worth linking to as it was so clever: https://en.wikipedia.org/wiki/Cyclone_%28programming_language%29 https://en.wikipedia.org/wiki/Cyclone_%28programming_languag... Just gotta maintain the front-end. Ivory language from Galois is still maintained & extracts to C. Tools like Softbound+CETS will autotransform your code to safety at a 10-40% performance hit. A typed assembler language like TALx86 or custom one from Hyde's HLA would give you lower level than C with more safety ironically. So, many options for OSS to build on with some like Pascals having mature tooling. EDIT: Just remembered the Pike programming language used in Roxen web & app servers as a C alternative. They're FAST. So, do google it.
- fredmorcos 11y ago
  Wow, thank you for that reply! I don't think that C stays alive because people just automatically rejected anything else. There is something to C that I appreciate extremely, and that is the clarity and simple semantics: there is not much hiding and unintentional obfuscation that one can cause when writing C code. Maybe safety and simplicity are mutually exclusive if speed and fine-grained control over memory are the main goals. For Modula, the tools and documentation are not being updated anymore, I could not find a programming environment for eg., emacs and on armv6. Free Pascal and Lazarus are great, until I realized there were no resources to learn modern pascal from. The emacs mode is too basic and doesn't take any advantage of things offered by fpc. But I have to admit, I've never seen anything as good as Lazarus before. D is more like a C++ successor that's aiming at Java than a successor to C. It is complex and does not seem to be making any effort in unifying its concepts: in the same spirit of C++. Cyclone is definitely interesting, but unmaintained and not exactly simple, similarly to Rust but with a C-like syntax. Julia crashes all the time with segmentation faults, sorry, the quality of Julia is super low. I would not use it for anything serious. It has great ideas though. OCaml is super complex with its syntax and semantics. I love Haskell, which makes great efforts to unify its concepts: the language is super simple (its implementation can be arbitrarily complicated). Haskell is where I go to write beautiful things. Fast (like, systems programming fast) Haskell code is ugly and unmaintainable and defeats the purpose of choosing Haskell in the first place. I'll be taking a look at the rest! Thanks!
  - ihnorton 11y ago
    > crashes all the time with segmentation faults We would very much appreciate any bug reports, even if you don't have the time to reduce (if you have filed under another username, thank you!).
  - StefanKarpinski 11y ago
    > Julia crashes all the time with segmentation faults, sorry, the quality of Julia is super low. I would not use it for anything serious. I've seen a lot of Julia used in real world scenarios at companies and this is a pretty surprising claim. Segfaults are very rare – much rarer than in code written in C or C++. You may either have a messed up build of Julia or you could be using packages that call C libraries and do so incorrectly – that would certainly cause segfaults.
steveklabnik 11y ago
> it gets hard to limit the number of memory allocations/accesses > as well as data copies going on. I would be interested in hearing more about this, if you have the time.
- nickpsecurity 11y ago
  That statement didn't fully sink in first time I saw it. I'm also curious as to what that was referring to. Especially since Ada/SPARK are mainly used in real-time, resource-constrained systems.
- fredmorcos 11y ago
  In this video[0] on Rust, in this example I was unable to directly tell whether the Vec structure is being copied to the take() function. If ownership is being handed over, why is a copy being made? And if a copy really isn't being made, then why aren't the function signature and the calling site reflecting that? I hope I am making any sense... Please tell me if I should try to rephrase, or if I am in need of clarification on the subject. (BTW, this is also something I really dislike about C++, two function calls that look exactly the same, foo(x) and bar(x), could either be pass by value or pass by reference: you have to go dig up the function signatures to figure that out). [0] https://youtu.be/O5vzLKg7y-k?t=1110 https://youtu.be/O5vzLKg7y-k?t=1110
  - steveklabnik 11y ago
    Gotcha. I thought the video would have explained this, but since it didn't get through, let me try :) fn take(vec: Vec<i32>) In Rust, the default way that things operate is to _move_. So when you call take(), we'd say that the vector moves into the function. Moving is always a memcpy. There's no way to change this behavior, so you can always know that it's true. But with a Vec, there's a subtlety: the Vec itself is three words: a pointer to the heap, a length, and a capacity. So when I say that the Vec is memcpy'd, I mean literally those three things. It doesn't try to follow the pointer and copy the data that it points to. Incidentally, that pointer is why we say that it moves: because two copies of the Vec structure itself would mean an aliased pointer to the heap, the compiler doesn't allow the use of the older binding after take() is called. For simpler types, like integers: fn take(i: i32) they implement a trait called Copy. This means that when you call take, the i32 is copied, in the same fashion that the Vec was copied. The only difference is that there's no problem with having these two copies, as an i32 is, well, just an i32. So the compiler won't prevent the use of the binding outside the function like it would with a non-Copy type. References are like pointers, but with the extra static checking that Rust does. fn take(vec: &Vec<i32>) References also implement Copy, and so when you pass a reference to a Vec to this function, the same thing happens as in the i32 case. The reference itself gets copied. This is sort of a long-winded way of saying that Rust is "pass by value", not "pass by reference." Some people like to call this "pass reference by value", since while it's always pass by value, references are themselves values. What if we _did_ want to make a full copy of the Vec, including its elements? For that, we have to use the .clone() method. let v = ... // some Vec<i32> let v1 = v.clone(); Now, v and v1 will be full, independent copies of the same thing. In other words, if you don't see .clone(), it will never be a deep copy. let v = ... // some Vec<i32> let v1 = v; // a move, always a shallow memcpy let v2 = v1.clone(); // a deep copy You can always see, syntactically, when you're making a possibly expensive copy of something. Does that help? I'm happy to elaborate further.
tavert 11y ago
You might like Nim or Crystal?
- nickpsecurity 11y ago
  I left Nim off on purpose because it wasn't simple or C-like at all. It's an interesting language that could be a C++ or C replacement, though.

nickpsecurity 11y ago

The problem is, outside Ada and Rust, there isn't much of anything that's maintained because people stayed rejecting anything but C. I will post this on Ada so you can see (a) a nice survey of problems that show up and (b) how it systematically counters them. http://www.adacore.com/uploads/technical-papers/SafeSecureAdav2015-covered.pdf http://www.adacore.com/uploads/technical-papers/SafeSecureAd... The best candidates for simpler ones were Wirth-like languages, esp Modula-3. I used to recommend Delphi as it was a Pascal alternative to Visual C++ whose apps rarely crashed. Free Pascal succeed w/ Lazaurus IDE succeeded it w/ tons of hardware support. Component Pascal w/ Blackbox is still active AFAIK. D is quite active. Some Modula-2 benefits https://news.ycombinator.com/item?id=9640126 https://news.ycombinator.com/item?id=9640126 Modula-3 features https://en.wikipedia.org/wiki/Modula-3 https://en.wikipedia.org/wiki/Modula-3 Note: Fast to compile, fast to run, easy to read, easy to integrate, optional GC, optional OOP... why we need C and C++ again? Outside legacy systems... Free Pascal http://www.freepascal.org/ http://www.freepascal.org/ Component Pascal https://en.wikipedia.org/wiki/Component_Pascal https://en.wikipedia.org/wiki/Component_Pascal D language (C/C++ successor) https://en.wikipedia.org/wiki/D_%28programming_language%29 https://en.wikipedia.org/wiki/D_%28programming_language%29 Julia http://julialang.org/ http://julialang.org/ Note: It's a language for scientific programming but it's worth considering given speed and C support. On functional side, people are writing OS's in Haskell, Ocaml, and so on. OcaPic put Ocaml on 8-bitters. ATS Language was used for drivers and 8-bitters. RED/System is like LISP w/out parenthesis for system programming with ability to make DSL's. Any such language can have safety checks built in or output something for analysis. So, even functional languages are performing acceptably in places where C used to be required. Just need more people investing into any trouble spots. Someone could also pick up the code of Popcorn, Cyclone, or another safer C to develop it. Cyclone is worth linking to as it was so clever: https://en.wikipedia.org/wiki/Cyclone_%28programming_language%29 https://en.wikipedia.org/wiki/Cyclone_%28programming_languag... Just gotta maintain the front-end. Ivory language from Galois is still maintained & extracts to C. Tools like Softbound+CETS will autotransform your code to safety at a 10-40% performance hit. A typed assembler language like TALx86 or custom one from Hyde's HLA would give you lower level than C with more safety ironically. So, many options for OSS to build on with some like Pascals having mature tooling. EDIT: Just remembered the Pike programming language used in Roxen web & app servers as a C alternative. They're FAST. So, do google it.

fredmorcos 11y ago
Wow, thank you for that reply! I don't think that C stays alive because people just automatically rejected anything else. There is something to C that I appreciate extremely, and that is the clarity and simple semantics: there is not much hiding and unintentional obfuscation that one can cause when writing C code. Maybe safety and simplicity are mutually exclusive if speed and fine-grained control over memory are the main goals. For Modula, the tools and documentation are not being updated anymore, I could not find a programming environment for eg., emacs and on armv6. Free Pascal and Lazarus are great, until I realized there were no resources to learn modern pascal from. The emacs mode is too basic and doesn't take any advantage of things offered by fpc. But I have to admit, I've never seen anything as good as Lazarus before. D is more like a C++ successor that's aiming at Java than a successor to C. It is complex and does not seem to be making any effort in unifying its concepts: in the same spirit of C++. Cyclone is definitely interesting, but unmaintained and not exactly simple, similarly to Rust but with a C-like syntax. Julia crashes all the time with segmentation faults, sorry, the quality of Julia is super low. I would not use it for anything serious. It has great ideas though. OCaml is super complex with its syntax and semantics. I love Haskell, which makes great efforts to unify its concepts: the language is super simple (its implementation can be arbitrarily complicated). Haskell is where I go to write beautiful things. Fast (like, systems programming fast) Haskell code is ugly and unmaintainable and defeats the purpose of choosing Haskell in the first place. I'll be taking a look at the rest! Thanks!
- ihnorton 11y ago
  > crashes all the time with segmentation faults We would very much appreciate any bug reports, even if you don't have the time to reduce (if you have filed under another username, thank you!).
- StefanKarpinski 11y ago
  > Julia crashes all the time with segmentation faults, sorry, the quality of Julia is super low. I would not use it for anything serious. I've seen a lot of Julia used in real world scenarios at companies and this is a pretty surprising claim. Segfaults are very rare – much rarer than in code written in C or C++. You may either have a messed up build of Julia or you could be using packages that call C libraries and do so incorrectly – that would certainly cause segfaults.

steveklabnik 11y ago

> it gets hard to limit the number of memory allocations/accesses > as well as data copies going on. I would be interested in hearing more about this, if you have the time.

nickpsecurity 11y ago
That statement didn't fully sink in first time I saw it. I'm also curious as to what that was referring to. Especially since Ada/SPARK are mainly used in real-time, resource-constrained systems.
fredmorcos 11y ago
In this video[0] on Rust, in this example I was unable to directly tell whether the Vec structure is being copied to the take() function. If ownership is being handed over, why is a copy being made? And if a copy really isn't being made, then why aren't the function signature and the calling site reflecting that? I hope I am making any sense... Please tell me if I should try to rephrase, or if I am in need of clarification on the subject. (BTW, this is also something I really dislike about C++, two function calls that look exactly the same, foo(x) and bar(x), could either be pass by value or pass by reference: you have to go dig up the function signatures to figure that out). [0] https://youtu.be/O5vzLKg7y-k?t=1110 https://youtu.be/O5vzLKg7y-k?t=1110
- steveklabnik 11y ago
  Gotcha. I thought the video would have explained this, but since it didn't get through, let me try :) fn take(vec: Vec<i32>) In Rust, the default way that things operate is to _move_. So when you call take(), we'd say that the vector moves into the function. Moving is always a memcpy. There's no way to change this behavior, so you can always know that it's true. But with a Vec, there's a subtlety: the Vec itself is three words: a pointer to the heap, a length, and a capacity. So when I say that the Vec is memcpy'd, I mean literally those three things. It doesn't try to follow the pointer and copy the data that it points to. Incidentally, that pointer is why we say that it moves: because two copies of the Vec structure itself would mean an aliased pointer to the heap, the compiler doesn't allow the use of the older binding after take() is called. For simpler types, like integers: fn take(i: i32) they implement a trait called Copy. This means that when you call take, the i32 is copied, in the same fashion that the Vec was copied. The only difference is that there's no problem with having these two copies, as an i32 is, well, just an i32. So the compiler won't prevent the use of the binding outside the function like it would with a non-Copy type. References are like pointers, but with the extra static checking that Rust does. fn take(vec: &Vec<i32>) References also implement Copy, and so when you pass a reference to a Vec to this function, the same thing happens as in the i32 case. The reference itself gets copied. This is sort of a long-winded way of saying that Rust is "pass by value", not "pass by reference." Some people like to call this "pass reference by value", since while it's always pass by value, references are themselves values. What if we _did_ want to make a full copy of the Vec, including its elements? For that, we have to use the .clone() method. let v = ... // some Vec<i32> let v1 = v.clone(); Now, v and v1 will be full, independent copies of the same thing. In other words, if you don't see .clone(), it will never be a deep copy. let v = ... // some Vec<i32> let v1 = v; // a move, always a shallow memcpy let v2 = v1.clone(); // a deep copy You can always see, syntactically, when you're making a possibly expensive copy of something. Does that help? I'm happy to elaborate further.

tavert 11y ago