Re: [agi] Re: ISO experienced Rust dev to help build AGI

[Basile Starynkevitch]

On 06/03/2023 19:15, stefan.reich.maker.of.eye via AGI wrote:

On Sunday, March 05, 2023, at 7:43 AM, Ben Goertzel wrote:
We nearly chose C++ but went with Rust for reasons like greater 
maintainability and greater ease of having the code more bug-free ...
Oh... Rust as a safe drop-in for C++. I get it. Yeah you wouldn't want 
memory errors to topple your AGI...



On the other hand, coding a garbage collector in C++ (which is done in 
the RefPerSys open source symbolic AI project on http://refpersys.org/ 
) is actually feasible.



With future work on http://refpersys.org/, that GC could be even be 
partly geenerated by RefPerSys itself (as generated C++ or later machine 
code).



Regards

--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/ & refpersys.org


--
Artificial General Intelligence List: AGI
Permalink: 
https://agi.topicbox.com/groups/agi/Ta26ae6adc3928674-M0f31c2cfd49fb2d635a5bcea
Delivery options: https://agi.topicbox.com/groups/agi/subscription

Re: [agi] Re: ISO experienced Rust dev to help build AGI

[stefan.reich.maker.of.eye via AGI]

On Sunday, March 05, 2023, at 7:43 AM, Ben Goertzel wrote:
> We nearly chose C++ but went with Rust for reasons like greater
maintainability and greater ease of having the code more bug-free ...
Oh... Rust as a safe drop-in for C++. I get it. Yeah you wouldn't want memory 
errors to topple your AGI...
--
Artificial General Intelligence List: AGI
Permalink: 
https://agi.topicbox.com/groups/agi/Ta26ae6adc3928674-M5990fc85a419168a592a08ba
Delivery options: https://agi.topicbox.com/groups/agi/subscription

Re: [agi] Re: ISO experienced Rust dev to help build AGI

[Ben Goertzel]

James,

If you look at what Greg has done w/ rho calculus

https://arxiv.org/search/cs?searchtype=author=Meredith%2C+L+G

and then these more recent elaborations of Native Type Theory that
provide a more elegant way of doing what Curry-Howard tries to do (and
does in limited cases),

https://github.com/leithaus/rho4u/blob/main/oslf/oslf.pdf

you'll see something that extends to quantum type systems pretty
naturally too...

MeTTa language that we're developing for Hyperon will be perfectly
capable of dealing w/ quantum type systems... which should ultimately
make it portable to general purpose quantum computers, and in the
shorter term, should make it useful to implement
classical-computer-based drivers of specialized quantum computing
hardware...

But we have a few fish to fry before that becomes our biggest problem
;) ... for now we are looking at the best ways to leverage Greg's work
to make MeTTa extremely efficient in a classical multiprocessor
setting.. (e.g. server farms of multi-GPU boxes...)

ben

On Sun, Mar 5, 2023 at 8:18 AM James Bowery  wrote:
>
> When I was tasked by AT & Knight-Ridder to architect their nationwide 
> rollout of a mass market information utility starting with electronic 
> newspapers, it was before TCP/IP had been carved in stone so I went to David 
> P. Reed (Mr UDP) and talked with him about his PhD thesis regarding a 
> distributed programming synchronization paradigm that, coincidentally (or 
> perhaps not so), was isomorphic to the dataflow architecture by the guys the 
> next floor or two down at the MIT LCS (Arvind and Gostellow's U-Interpreter). 
> A version finally ended up being implemented as TeaTime under the now-defunct 
> Croquet system.  I had some additional semantics sufficing to deal with the 
> memoization (cache) maintenance problem elegantly that didn't get 
> incorporated into TeaTime.  The main limitation as I saw it was the focus on 
> functional (N:1) programming as opposed to relational (N:M) programming since 
> one can get functional programming as a degenerate case of relational.  The 
> XSB Prolog guys finally got something done with incremental tabling that 
> handled part of the memoization (cache) maintenance problem, but the 
> parallelization and distributed atomic action problems remain. My focus on 
> relational semantics was reinforced by my interactions with Backus regarding 
> his seminal Turing Lecture about FFP when he admitted that would be an 
> afterthought.
>
> While it is true that we live in a world where there is an apparent unitary 
> state transition going on, hence N:1 is a kind of underlying assumption, this 
> is only true in the case of an atomic action "commit".  Up until that point 
> in time, the atomic action can be undone in a quasi-reversible programming 
> sense.  So, despite getting to know not only Backus, but also Curry and 
> Church toward their end of their lives, I saw relations as the cornerstone of 
> any programming paradigm for which I would be responsible since I could have 
> affected the lives of billions by failing to so-discipline my architecture.
>
> This obviously leads directly into quantum information systems, which 
> Federico Faggin attempted to explore with my colleagues at Boundary Institute 
> -- refugees from Paul Allen's Interval Research -- by resurrecting Russell's 
> Relation Arithmetic as the proper formal language of the quantum core.
>
> But here's the thing that everyone seems to miss about quantum information 
> systems:
>
> If we accept that they are at the basis of the empirical world (as Russell 
> said of Relation Arithmetic) then physical dimensions should naturally fall 
> out of the structure.  By "physical dimensions" I mean stuff of the physical 
> world that any programming language dealing with artificial intelligence must 
> necessarily deal with in order to be considered MODELs of reality.
>
> Other than Relation Arithmetic (as revived at Boundary), I've seen absolutely 
> NOTHING in the SIGPLAN-proximate world that remotely accomplishes this except 
> as a bricolage kludge.  This is quite frustrating and, to be quite honest, I 
> don't think ANY new programming language deserves to exist that doesn't 
> perform this feat as an inevitability of its structure.
>
> This isn't just an autistic demand for a pet project.  It gets to the 
> foundation of the way computers model reality.
>
>
>
> On Sun, Mar 5, 2023 at 12:06 AM Ben Goertzel  wrote:
>>
>> On Sat, Mar 4, 2023 at 6:06 AM stefan.reich.maker.of.eye via AGI
>>  wrote:
>> >
>> > I'd be very curious to hear what you see as the role of Rust in AGI if 
>> > you'd be willing to expand on it a little bit. (Trade secret?! :)
>> >
>> > Stefan
>> 
>> It's not very secret, see e.g.
>> 
>> https://github.com/trueagi-io/hyperon-experimental
>> 
>> We have created our own AGI language (MeTTa) to play a key role in our
>> new OpenCog Hyperon system,
>> 
>> https://wiki.opencog.org/w/Hyperon
>> 
>> but the interpreter for core 

Re: [agi] Re: ISO experienced Rust dev to help build AGI

[James Bowery]

When I was tasked by AT & Knight-Ridder to architect their nationwide
rollout of a mass market information utility starting with electronic
newspapers, it was before TCP/IP had been carved in stone so I went to
David P. Reed (Mr UDP) and talked with him about his PhD thesis regarding a
distributed programming synchronization paradigm that, coincidentally (or
perhaps not so), was isomorphic to the dataflow architecture by the guys
the next floor or two down at the MIT LCS (Arvind and Gostellow's
U-Interpreter). A version finally ended up being implemented as TeaTime
under the now-defunct Croquet system.  I had some additional semantics
sufficing to deal with the memoization (cache) maintenance problem
elegantly that didn't get incorporated into TeaTime.  The main limitation
as I saw it was the focus on functional (N:1) programming as opposed to
relational (N:M) programming since one can get functional programming as a
degenerate case of relational.  The XSB Prolog guys finally got something
done with incremental tabling that handled part of the memoization (cache)
maintenance problem, but the parallelization and distributed atomic action
problems remain. My focus on relational semantics was reinforced by my
interactions with Backus regarding his seminal Turing Lecture about FFP
when he admitted that would be an afterthought.

While it is true that we live in a world where there is an apparent unitary
state transition going on, hence N:1 is a kind of underlying assumption,
this is only true in the case of an atomic action "commit".  Up until that
point in time, the atomic action can be undone in a quasi-reversible
programming sense.  So, despite getting to know not only Backus, but also
Curry and Church toward their end of their lives, I saw relations as the
cornerstone of any programming paradigm for which I would be responsible
since I could have affected the lives of billions by failing to
so-discipline my architecture.

This obviously leads directly into quantum information systems, which
Federico Faggin attempted to explore with my colleagues at Boundary
Institute -- refugees from Paul Allen's Interval Research -- by
resurrecting Russell's Relation Arithmetic as the proper formal language of
the quantum core.

But here's the thing that everyone seems to miss about quantum information
systems:

If we accept that they are at the basis of the empirical world (as Russell
said of Relation Arithmetic) then physical dimensions should naturally fall
out of the structure.  By "physical dimensions" I mean stuff of the
physical world that any programming language dealing with artificial
intelligence must necessarily deal with in order to be considered MODELs of
reality.

Other than Relation Arithmetic (as revived at Boundary), I've seen
absolutely NOTHING in the SIGPLAN-proximate world that remotely
accomplishes this except as a bricolage kludge.  This is quite frustrating
and, to be quite honest, I don't think ANY new programming language
deserves to exist that doesn't perform this feat as an inevitability of its
structure.

This isn't just an autistic demand for a pet project.  It gets to the
foundation of the way computers model reality.



On Sun, Mar 5, 2023 at 12:06 AM Ben Goertzel  wrote:

> On Sat, Mar 4, 2023 at 6:06 AM stefan.reich.maker.of.eye via AGI
>  wrote:
> >
> > I'd be very curious to hear what you see as the role of Rust in AGI if
> you'd be willing to expand on it a little bit. (Trade secret?! :)
> >
> > Stefan
> 
> It's not very secret, see e.g.
> 
> https://github.com/trueagi-io/hyperon-experimental
> 
> We have created our own AGI language (MeTTa) to play a key role in our
> new OpenCog Hyperon system,
> 
> https://wiki.opencog.org/w/Hyperon
> 
> but the interpreter for core MeTTa has to be written in something else
> and that is Rust (which we chose over C++ or Haskell for this purpose
> for fairly familiar reasons...)
> 
> ben

--
Artificial General Intelligence List: AGI
Permalink: 
https://agi.topicbox.com/groups/agi/Ta26ae6adc3928674-Mf2b83f83e75bc21ed0a9e360
Delivery options: https://agi.topicbox.com/groups/agi/subscription

Re: [agi] Re: ISO experienced Rust dev to help build AGI

[Arnold Müller]

speed yip ..WebAssembly WASM ..using Rust in [an] existing web apps
https://developer.mozilla.org/en-US/docs/WebAssembly/Rust_to_wasm

porting [legacy] c/c++ to web apps.. https://github.com/nrc/r4cppp
[Hopefully,] Rust is a pretty intuitive language for C++ programmers.



On Sun, 05 Mar 2023, 06:05 Mike Archbold,  wrote:

> Probably strong typing and speed
>
> On Sat, Mar 4, 2023, 6:07 AM stefan.reich.maker.of.eye via AGI <
> agi@agi.topicbox.com> wrote:
>
>> I'd be very curious to hear what you see as the role of Rust in AGI if
>> you'd be willing to expand on it a little bit. (Trade secret?! :)
>>
>> Stefan
>>
> *Artificial General Intelligence List *
> / AGI / see discussions  +
> participants  +
> delivery options 
> Permalink
> 
>

--
Artificial General Intelligence List: AGI
Permalink: 
https://agi.topicbox.com/groups/agi/Ta26ae6adc3928674-Mce32435a70adb18a72615267
Delivery options: https://agi.topicbox.com/groups/agi/subscription

Re: [agi] Re: ISO experienced Rust dev to help build AGI

[Ben Goertzel]

> but the interpreter for core MeTTa has to be written in something else
> and that is Rust (which we chose over C++ or Haskell for this purpose
> for fairly familiar reasons...)

We nearly chose C++ but went with Rust for reasons like greater
maintainability and greater ease of having the code more bug-free ...
and because down the road there is more prospect of having Rust code
formally verifiable than C++, and we'd like the infrastructure for the
first AGI to be formally verifiable

Haskell was my first thought but when one looks closely at what one
needs to do to make this sort of Haskell code extremely fast/scalable
it's not that pretty ... and from my work with Cardano smart contracts
in SingularityNET I'm aware of the difficulty of recruiting strong
Haskell devs ... (though we are now training a bunch in our Addis
Ababa office...)

-- ben

--
Artificial General Intelligence List: AGI
Permalink: 
https://agi.topicbox.com/groups/agi/Ta26ae6adc3928674-Mdf7123fc47379a2e943727c9
Delivery options: https://agi.topicbox.com/groups/agi/subscription

Re: [agi] Re: ISO experienced Rust dev to help build AGI

[Ben Goertzel]

On Sat, Mar 4, 2023 at 6:06 AM stefan.reich.maker.of.eye via AGI
 wrote:
>
> I'd be very curious to hear what you see as the role of Rust in AGI if you'd 
> be willing to expand on it a little bit. (Trade secret?! :)
>
> Stefan

It's not very secret, see e.g.

https://github.com/trueagi-io/hyperon-experimental

We have created our own AGI language (MeTTa) to play a key role in our
new OpenCog Hyperon system,


https://wiki.opencog.org/w/Hyperon


but the interpreter for core MeTTa has to be written in something else
and that is Rust (which we chose over C++ or Haskell for this purpose
for fairly familiar reasons...)

ben

--
Artificial General Intelligence List: AGI
Permalink: 
https://agi.topicbox.com/groups/agi/Ta26ae6adc3928674-M425c2a177e84e6a0969b716c
Delivery options: https://agi.topicbox.com/groups/agi/subscription

Re: [agi] Re: ISO experienced Rust dev to help build AGI

[Mike Archbold]

Probably strong typing and speed

On Sat, Mar 4, 2023, 6:07 AM stefan.reich.maker.of.eye via AGI <
agi@agi.topicbox.com> wrote:

> I'd be very curious to hear what you see as the role of Rust in AGI if
> you'd be willing to expand on it a little bit. (Trade secret?! :)
>
> Stefan
> *Artificial General Intelligence List *
> / AGI / see discussions  +
> participants  +
> delivery options 
> Permalink
> 
>

--
Artificial General Intelligence List: AGI
Permalink: 
https://agi.topicbox.com/groups/agi/Ta26ae6adc3928674-M4e5f04bdf08d50f33699dff1
Delivery options: https://agi.topicbox.com/groups/agi/subscription