Re: Adacore joins with Ferrous Systems to support Rust

[Paul Rubin <no.email@nospam.invalid>]

"Luke A. Guest" <laguest@archeia.com> writes:
> You don't need to learn both languages inside and out. You pick a
> project and implement it in both languages,

Not realistic, as the saying is that it's possible to write Fortran in
any language.  What I want to see is proper idiomatic usage of both
languages as experts would write them.  Also, it seems to me that one of
Ada's big strengths is its modularity, e.g. the separation of
specification from implementation.  And that makes itself felt more with
large programs than small ones.  A beginner or tryout project wouldn't
exercise this.

> [Ada] Learn the basic part,

I think I have done that, but there is a heck of a lot more.

> [Haskell] So it's no different than a C++ compiler checking against
> classes or a variant of C with strong typing?

It is very different from either of those.

> Still no ranges, subranges, ranges with holes in, etc. This is where
> the power is.

No not really, especially since Ada doesn't enforce ranges with (static)
type checking, although it is sometimes possible in SPARK.  Range types
are a nice Ada feature but only "where the power is" if you haven't used
anything else ;).  Anyway, you can implement ranges (with runtime
checks) in C++ or Haskell with a bit of pain.

>> Example: a red-black tree using Haskell GADT's
> I don't know Haskell. Uni did a shit job at teaching functional, and
> logic languages.

Well are you familiar with red-black trees?  They are a data structure
similar to B-trees which you may have seen.  Basically the trees have
nodes that are coloured either red or black, and there are some rules
such as that internal red nodes can have only black children, and that
enforces some invariants that keep the trees balanced so that lookups
and updates are guaranteed to run fairly fast.

Now these trees have been implemented in many languages, and if you look
at almost any implementation, there is usually a test suite or internal
debugging code to make sure that the invariants are preserved after
doing an update.  It is quite easy to make a mistake after all.  But the
Haskell code doesn't have those tests.  Why not?  Because the invariants
are enforced by the datatype!  If you make a mistake and mess up an
invariant, your code won't compile!  It's the difference between
checking a subscript at runtime, and verifying that it in range with
SPARK.  SPARK lets you get rid of the runtime check.  Haskell's type
system is able to do similar things.

> 1. What do you want to do?

I have too many obligations and wannado projects to embark on anything
well suited for either Ada or Rust right now, unless someone is paying
me.  Also, I see Ada and Rust not really aiming at the same areas.  I
think of Ada as being more for control programs (they might compute a
lot, but tend not to make complex use of dynamic memory allocation)
while Rust is the opposite (handling dynamic allocation reliably is a
big part of the design motivation).

> 4. Ada is comparable to C++.
>   4a. Ada > C++ in many ways.

I don't see Ada and C++ as really comparable.  Ada > C++ in reliability
for sure, but C++ > Ada in convenience a lot of the time.

Particularly, a lot of effort in Ada programming goes into making
programs never crash.  For example, if the program runs out of memory
during operation it might crash, so Ada programs are often written to
never allocate new memory after a startup phase.  In C++ or Rust, it's
important not to get wrong answers like 2+2=5, but if your program runs
out of memory and crashes, go get a bigger computer.  So idiomatic C++
and Rust programming uses dynamic allocation freely, and that makes some
kinds of programming more convenient, at the expense of tolerating
possible crashes.