I can name one. At my job we do the kind of embedded programming were encoders inside machines send data to each other. Like reading optical sensors and sending bits indicating state to other controllers.

We absolutely do not "need" to know about Unicode, outside of interest about other realms.

> Essentially, the ISO 26262 certification mostly verifies that the compiler release process conforms to a certain standard. It does not create an ISO standard for rust, not does it aim to.

Sorry for a stupid question, but what does this mean?

Is it only that Rust itself (the language) is no use in a certification, but rather a specific compiler version? I.e. basically leading to the same outcome in the end.

Or does this mean to not get the hopes up (right now) for using Rust in a ISO26262 certified project?

Not your parent, and haven't worked directly in these areas, but this is my understanding.

"certification" is something that is done to a process that produces a software artifact.

So yes, in some sense it is "particular compiler version." The result of certification says "this compiler will do this when given this, and here is how we ensure that that is true, and here's the process for when that's not true, etc etc etc." Users can then use that specific compiler.

> I.e. basically leading to the same outcome in the end.

The difference is pretty important. Getting this certification does not require that the abstract concept of the Rust language is being specified in any specific way. It does require that a specific inputs to the compiler are described, and because compatibility with upstream Rust is desired, those specific inputs happen to map to inputs to rustc that are identical, but it is important to understand that this can happen completely independently of what the Rust Project decides is best for the language; this is a downstream project.

In theory, if the Rust project wanted a specification, starting with some of the work Ferrocene has done would be an option. But the qualification process doesn't require that.

> Or does this mean to not get the hopes up (right now) for using Rust in a ISO26262 certified project?

The opposite, this means you can use Rust in these places. Even though this work does not specify Rust.

Thank you for an exhaustive answer!

> The difference is pretty important. Getting this certification does not require that the abstract concept of the Rust language is being specified in any specific way.

Sorry, I was being vague. I meant the outcome for "us", the users, creating certified software relying on Ferrocene.

Totally on board with that there is a huge difference for certifying Ferrocene itself.

> The opposite, this means you can use Rust in these places. Even though this work does not specify Rust.

Nice, that's what I was hoping for. We are currently in a project creating safety certified software (in C, as are our other code) and are curiously looking at Rust, partly because of this effort.

You're welcome.

The main page for Ferrocene says "ISO 26262 and IEC 61508 qualified" with "DO-178C, ISO 21434, and IEC 62278 in the future," so depending on exactly which things you need, Ferrocene may work, but it also may not.

Sure, but many cities in the world are not in the US.

Assuming no other transportation alternative, and single person per car as well I guess?

Not assuming that, it's not that obvious how big parking needs to be.

> all of our computing resources are based on a 100+ year old concept of a file cabinet with folders and files.

While they are based on the same concept, putting things inside of things (in hierarchies) is a pretty solid way of sorting stuff.

There are other ways as well, such as labels/tags. But regardless of technology I feel like folders (in one way or another) is one of the tools you would reach for.

IMHO both exceptions and error handling in Rust (and others) have their upsides and downsides.

Personally, I much prefer Rusts solution, being both more up front and at the same time more terse.

The metaphor is kinda stupid though, the "cavemen" in our scenario knows very well that exceptions exist.

To be fair, they said particular location from the equator.

Does not have to mean close to the equator.

I can absolutely see that piracy could fit under (a).

"to deprive the owner of it" it being copyright

They have the right over copies, and to make money from it if they choose.

Are you hung up on that it has to be some physical object?

Edit: to be clear, in this reasoning, the thing deprived from someone is not your copy of the movie, but rather the right of copying.

I haven't read mastering emacs, but reading about it gives me impression that it is more for using emacs?

Emacs is very much on the radar otherwise, and I have actually skimmed documentation for information about its architecture.

Note how things are grouped / structured in emacs. (beyond the tree, aka implied surrounding environment, current abstraction level, abstraction level(s) below current abstraction level.

lisp (.) notation works for nice compact level notation aka outside (.) is parent environment, inside (.) is various levels of () abstraction, evaluating pair of () gives result of the () application evaluated. Where something like the bash shell, the (.) is what happens in the shell file, outside of the (.) is the command line environment, and inside () may be multiple nested shell file abstraction/other shell file references. Note: can extend the (.) concept to spreadsheets, where each cell in spread sheet is shell file & spreadsheet is "file directory".

Could check out how treesitter is used in vim/neovim vs. emacs. and/or 70's tex & nroff put together things.

ed fairly barebones editor, one step up from command line sed.

Slightly more modern approach, search engine term 'text editor written in ' adding language of choice/familiar with after 'in' aka 'text editor writtin in bash'. play around with source code.

What's the ide & code repository (with reports/code/"goals"/dev communication) being used? aka developer environment should take care of lot of non-code/code details that are needed for development, but not what the current developement focus is. aka focus using X11 for front end to database (vs. developing X11 gui library to use as front end).

lisp short notation, where in the (.) is the focus?

outside (.), result of some (.) nested in several (.) levels, or result of top (), or totally different top level ()?

Yes, looking for link about history of emacs. As memory serves, EMACs was written using the common 80's approach (from scratch, in non-device independent ways because predates c 89 standard & modular libraries didn't exist). Currently, this is causing lots of headaches when trying to use/add/move things over to modern gui / standard modularized to avoid/minimize device dependence / leverage other projects useful to expand emacs)

Smaller project note: make was written as one shot thing with intend of about 5 people using it, hence decision to go with 'tab' and not space(s) at start of line.

how?

By creating some sort of model to draw diagrams.

https://code.tutsplus.com/tutorials/how-to-draw-a-pie-chart-...