The hash table/balanced tree problem is an important one. One of my most
important data structures is a priority queue that can have any element in it
modified at any time. Simple to do if you fuse a heap and any balanced tree
implementation into one data structure, but hard if the borrow checker is
fighting you. That said, after quickly reading through the relevant sections
of the Rust book, I think it's something that can be done easily at this point.
Something else to test out though...
Thanks,
Cem Karan
-----Original Message-----
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Jason E. Aten
Sent: Monday, March 13, 2017 6:52 PM
To: nanomsg <nanomsg@xxxxxxxxxxxxx>
Subject: [nanomsg] Re: [nanomsg] RE: [Non-DoD Source] [nanomsg] status of
nng… another update
All active links contained in this email were disabled. Please verify the
identity of the sender, and confirm the authenticity of all links
contained within the message prior to copying and pasting the address to a
Web browser.
________________________________
Rust is an experiment still in progress. I haven't looked at Rust since I
realized this a couple years ago. At the time the borrow checker
made it impossible to simple things like having a hash table and a balanced
tree that both pointed (indexed) the same set. I don't want to
fight with a language when I'm trying to build stuff on top of it.
You can read more current reviews with a simple search. e.g.
Caution-https://news.ycombinator.com/item?id=11774850 ;< Caution-
https://news.ycombinator.com/item?id=11774850 ;> where people like it, but
say:
It's confusing, as hell.
Sometimes Rust's type system is too limited to understand why something is
safe.
Others don't consider languages which do not handle OS signals a "systems"lang/rfcs/issues/1368 < Caution-https://github.com/rust-lang/rfcs/issues/1368 ;
language: Caution-https://github.com/rust-
On Mon, Mar 13, 2017 at 4:51 PM, Karan, Cem F CIV USARMY RDECOM ARL (US)
<cem.f.karan.civ@xxxxxxxx < Caution-
mailto:cem.f.karan.civ@xxxxxxxx ;> > wrote:
Does Rust fall into the 'immature' category?
Thanks,
Cem Karan
> -----Original Message-----
> From: nanomsg-bounce@xxxxxxxxxxxxx <
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> [Caution-mailto:nanomsg-
bounce@xxxxxxxxxxxxx < Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> ] On
Behalf Of Jason E. Aten
> Sent: Monday, March 13, 2017 5:33 PM
> To: nanomsg <nanomsg@xxxxxxxxxxxxx <
Caution-mailto:nanomsg@xxxxxxxxxxxxx ;> >
> Subject: [Non-DoD Source] [nanomsg] status of nng… another update
>
> All active links contained in this email were disabled. Please verify
the identity of the sender, and confirm the authenticity of all
links
> contained within the message prior to copying and pasting the address
to a Web browser.
>
>
> ________________________________
>
>
>
> My 2 cents, because its fun to talk about languages...
>
> Go: mature, productive. Conservative design that removes language
issues as blockers from getting things done. Best
concurrency support
> bar none. Very mature tooling: profiler, race detector. No working
debugger, but concurrent code quickly convinced me that
printf is
> better anyway.
>
> Swift: llvm based so very strong compiler. Not garbage collected
(automatic reference counts) so probably slower than Go on
true
> multicore code where you really need GC to avoid trashing your cache
hierarchy.
>
> The rest: immature research ideas that should not be messed with you
have time to waste.
>
>
>
> On Mar 13, 2017 16:08, "Karan, Cem F CIV USARMY RDECOM ARL (US)"
<cem.f.karan.civ@xxxxxxxx < Caution-
mailto:cem.f.karan.civ@xxxxxxxx ;> < Caution-
> Caution-mailto:cem.f.karan.civ@xxxxxxxx ;<
Caution-mailto:cem.f.karan.civ@xxxxxxxx ;> > > wrote:
>
>
> Yeah, language-wise, that was the conclusion I was coming to.
I have a simulator that I've written in C (needed the
performance),
> but it was a pain to write simply because the standard library was so
small. I've had others suggest that I look into Rust, which
suggests to
> me that I need to sit down and really go over the features of both Go
and Rust. I may also look into Julia further...
>
> Thank you for your opinion on this, it really helps!
>
>
> Thanks,
> Cem Karan
>
> > -----Original Message-----
> > From: nanomsg-bounce@xxxxxxxxxxxxx <
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> < Caution-Caution-
mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> >
[Caution-Caution-mailto:nanomsg- ;<
Caution-mailto:nanomsg- ;>
> bounce@xxxxxxxxxxxxx < Caution-mailto:bounce@xxxxxxxxxxxxx ;> <
Caution-Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> > ] On Behalf Of Garrett
D'Amore
>
> > Sent: Monday, March 13, 2017 3:09 PM
> > To: nanomsg@xxxxxxxxxxxxx <
Caution-mailto:nanomsg@xxxxxxxxxxxxx ;> <
Caution-Caution-mailto:nanomsg@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg@xxxxxxxxxxxxx ;> >
>
> > Subject: [nanomsg] Re: [nanomsg] RE: [nanomsg] Re: [nanomsg]
RE: [Non-DoD Source] [nanomsg] status of nng… another
> update
> >
> > All active links contained in this email were disabled.
Please verify the identity of the sender, and confirm the authenticity
of all
> links
> > contained within the message prior to copying and pasting the
address to a Web browser.
> >
> >
> > ________________________________
> >
> >
> >
>
> > From my perspective, for “control plane” type of software, I
prefer Go, if you can use it. It has all the developer
friendliness /
> productivity
> > benefits of languages like Python, while being strongly typed
and very efficient. It isn’t ideal for every circumstance (for
> example if you
> > have to embed it directly into a kernel, or if your
environment has real-time constraints, or simply doesn’t support Go), but
> frankly for
> > most of my day-to-day programming I find it is preferable.
However, I come at this from a background mostly in C, and I’m
fairly
> > opinionated about design and languages, and those opinions
come from my UNIX and C background, and are often at odds
with
> opinions
> > from people working in more dynamic languages like Python.
> >
> > Rust looks promising but I have no direct experience with it.
I think it probably outperforms Go, since it has no garbage
> collection, but I
> > am not sure if it is as pleasant to work with as Go. I would
reach for C only if you can’t reach for Go first; the biggest
problem
> with C is
> > that the standard library is rather tiny, and consequently
you wind up having to either implement or import a lot of stuff
that
> really should
> > be “standard” (e.g. linked lists, etc.)
> >
> > If performance is your primary concern, go for C. If you
have to be real-time compliant (industrial automation, etc.) then
reach
> for C.
> >
> >
>
> > On Mon, Mar 13, 2017 at 10:36 AM, Karan, Cem F CIV USARMY
RDECOM ARL (US) <cem.f.karan.civ@xxxxxxxx < Caution-
mailto:cem.f.karan.civ@xxxxxxxx ;> < Caution-
> Caution-mailto:cem.f.karan.civ@xxxxxxxx ;<
Caution-mailto:cem.f.karan.civ@xxxxxxxx ;> > < Caution-
> > Caution-Caution-mailto:cem.f.karan.civ@xxxxxxxx ;<
Caution-mailto:cem.f.karan.civ@xxxxxxxx ;> < Caution-Caution-
mailto:cem.f.karan.civ@xxxxxxxx ;< Caution-mailto:cem.f.karan.civ@xxxxxxxx ;>
> > wrote:> >
> >
> > Well, considering your experience in this area, I'd
**HIGHLY** suggest you write one! ;)
> >
> > I appreciate your advice, it makes some of what I was
thinking much more concrete. I'm fortunate that I have a very
narrow
> set of
> > devices that I have to support, and all of which I have
control over. If the research pans out, then it may be time to rewrite
it in
> a more
> > portable language for further refinement and testing. For
right now, I'll do some research into what languages there are
that
> support
> > what I'm doing, and select the best one for the job (Rust?
Go? Julia? C? Something else entirely? Who knows...)
> >
> > Thanks,
> > Cem Karan
> >
> > > -----Original Message-----
>
> > > From: nanomsg-bounce@xxxxxxxxxxxxx <
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> < Caution-Caution-
mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> > < Caution-Caution-
> Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> < Caution-Caution-
mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> > > [Caution-Caution-Caution-
mailto:nanomsg- ;< Caution-mailto:nanomsg- ;> <
> Caution-Caution-mailto:nanomsg- ;< Caution-mailto:nanomsg- ;> >
> > bounce@xxxxxxxxxxxxx < Caution-mailto:bounce@xxxxxxxxxxxxx ;>
< Caution-Caution-mailto:bounce@xxxxxxxxxxxxx ;< Caution-
mailto:bounce@xxxxxxxxxxxxx ;> > <
Caution-Caution-Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-
bounce@xxxxxxxxxxxxx > <
> Caution-Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> > > ] On Behalf Of
Garrett D'Amore
>
> > > Sent: Monday, March 13, 2017 11:49 AM
>
> > > To: nanomsg@xxxxxxxxxxxxx <
Caution-mailto:nanomsg@xxxxxxxxxxxxx ;> < Caution-Caution-
mailto:nanomsg@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg@xxxxxxxxxxxxx ;> > <
Caution-Caution-Caution-mailto:nanomsg@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg@xxxxxxxxxxxxx ;> <
> Caution-Caution-mailto:nanomsg@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg@xxxxxxxxxxxxx ;> > >
> > > Subject: [nanomsg] Re: [nanomsg] RE: [Non-DoD Source]
[nanomsg] status of nng… another update
> > >
> > > All active links contained in this email were
disabled. Please verify the identity of the sender, and confirm the
authenticity
> of all
> > links
> > > contained within the message prior to copying and
pasting the address to a Web browser.
> > >
> > >
> > > ________________________________
> >
> > >
> > >
> > >
> > > Sadly I don’t have any such paper already written.
For my own use cases, I’d probably write in Go first, and indeed
the Go
> > version
> > > (mangos) has worked out really really well.
> > >
> > > If I was not worried about interoperability I might
consider something like libdill as foundation layer, and then writing
the
> same
> > way I’d
> > > have done with Go. Unfortunately, I don’t think the
state of C is such that one can safely use any of the various
coroutine
> > libraries in a
> > > library intended for broad consumption — there are
simply too many caveats (no interop with real threads, limits on
stack
> > analysis tools,
> > > compiler optimizations, etc.) Really we need
coroutines in C itself, and I’ve come to believe that the C committee
would
> do us
> > all a big
> > > favor by adding coroutine support into the language
properly. It seems to me that this would not be very onerous for
> compiler
> > folks to
> > > add, and frankly the cost of doing so would be
smaller than the cost of creating the real C11 threads.
> > >
> > > I’m not a big fan of writing in another language and
providing C bindings…. that may make it easier for you to work
with,
> but it
> > makes the
> > > library more complex for your consumers, and can
limit portability to other platforms. For example, Rust isn’t
available on
> > many
> > > embedded targets. In fact, even going the other way,
where a C core is used and FFI bindings are used to map the
library
> to
> > other
> > > languages, feels kind of dirty to me. I’d far rather
have good RFCs for what the protocols are, and native language
> > implementations. This
> > > is more work for sure, but for the languages where
the native code exists, I believe the result is superior for all parties
> > concerned.
> > >
> > > In terms of shim vs. going native to the OS target —
the latter is generally preferable if you have a comfortable
> development
> > environment.
> > > Sometimes you don’t, or need to work with parties who
don’t have access to real hardware. (This comes up in
embedded
> work.)
> > In
> > > *those* cases simulation layers can allow progress to
be made. That said, it also helps if you can isolate your access
to OS-
> > specific services
> > > into a portability layer. This allows the greatest
portability, and allows work to be done on multiple platforms. For
> example, I
> > primarily
> > > work on macOS (my desktop) these days, but the
ability to quickly run the code on Linux gives me access to some
extra
> tooling
> > (valgrind in
> > > particular), which is immensely helpful.
> > >
> > > The main thing I’d say, if you’re planning to
undertake such a project, is start by determining what your goals are.
> nanomsg has
> > a pretty
> > > broad set of goals which makes a lot of what we had
to do harder (interop with ~everything, wide portability, high
> scalability,
> > use in
> > > environments to which I likely will never have
access, etc.) If your goals are more limited in scope, you can probably
take a
> > greatly
> > > simplified approach — for example if I didn’t have to
worry about portability or coexistence with OS threads, I’d have
been
> able
> > to use a
> > > coroutine library pretty darn easily, and saved
myself many hours of work.
> > >
> > > - Garrett
> > >
> > >
> > >
> >
> > > On Mon, Mar 13, 2017 at 6:25 AM, Karan, Cem F CIV
USARMY RDECOM ARL (US) <cem.f.karan.civ@xxxxxxxx <
Caution-mailto:cem.f.karan.civ@xxxxxxxx ;> < Caution-
> Caution-mailto:cem.f.karan.civ@xxxxxxxx ;<
Caution-mailto:cem.f.karan.civ@xxxxxxxx ;> > < Caution-
>
> > Caution-Caution-mailto:cem.f.karan.civ@xxxxxxxx ;<
Caution-mailto:cem.f.karan.civ@xxxxxxxx ;> < Caution-Caution-
mailto:cem.f.karan.civ@xxxxxxxx ;< Caution-mailto:cem.f.karan.civ@xxxxxxxx ;>
> < Caution->
> > >
Caution-Caution-Caution-mailto:cem.f.karan.civ@xxxxxxxx ;<
Caution-mailto:cem.f.karan.civ@xxxxxxxx ;> < Caution-
Caution-mailto:cem.f.karan.civ@xxxxxxxx ;<
Caution-mailto:cem.f.karan.civ@xxxxxxxx ;> > < Caution-Caution-
> Caution-mailto:cem.f.karan.civ@xxxxxxxx ;<
Caution-mailto:cem.f.karan.civ@xxxxxxxx ;> < Caution-Caution-
mailto:cem.f.karan.civ@xxxxxxxx ;< Caution-mailto:cem.f.karan.civ@xxxxxxxx ;>
> > > wrote:> > >
> > >
> > > Garrett, this is not a request to change how
nng works, it's just a request for your opinion if you had to do it all
over
> again,
> > so
> > > please take it in that grain.
> > >
> > > If you had to do it all over again with all of
the knowledge you now have, would you use callbacks, or would you
use
> > something
> > > else (green threads, coroutines, etc.)? Would you
write it all in C, or would you write the core in another language
and
> provide
> > bindings in
> > > C (and other languages)? Would you make the core
work directly with calls the OS provides, or would you develop
some
> kind of
> > shim
> > > layer so that you could test the core in simulation
before making it live? I'm thinking about various methods of
writing my
> own
> > > communications library, and would like to get your
opinions on what you think worked well, and what would need to
be
> > changed.
> > >
> > > For those wondering why I would consider
writing my own, it's because my target is unreliable and semi-reliable
> > communications
>
> > > similar to what the Licklider transmission protocol
(Caution-Caution-
> >
Caution-Caution-https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol ;
< Caution-
https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol ;> < Caution-
> Caution-https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol ;
< Caution-
https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol ;> > <
Caution-Caution-
> Caution-https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol ;
< Caution-
https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol ;> <
Caution-Caution-
https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol ;<
Caution-https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol ;>
> >
> > < Caution-
>
> > >
Caution-Caution-Caution-https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol
< Caution-
https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol ;> < Caution-
> Caution-https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol ;
< Caution-
https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol ;> > < Caution-
> >
Caution-Caution-https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol ;
< Caution-
https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol ;> < Caution-
> Caution-https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol ;
< Caution-
https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol ;> > > > )
was designed to handle, but over networks whose topology is
> > constantly
> > > in flux. In my ideal world the heart of the code
could be ported over to real networks after being tested out on a
> simulator, but
> > this
> > > requires some careful design and planning, which is
why I wanted to see what Garrett has learned.
> > >
> > > Actually, now that I think about it, Garrett,
if you have a 'lesson's learned' type of paper or article that you've
written,
> I'd
> > love to
> > > have a pointer to it so I can see the lay of the land
before I get there...
> > >
> > > Thanks,
> > > Cem Karan
> > >
> > >
> > > > -----Original Message-----
>
> > > > From: nanomsg-bounce@xxxxxxxxxxxxx <
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> < Caution-Caution-
mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> > < Caution-Caution-
> Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> < Caution-Caution-
mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> > > < Caution-Caution-
> > Caution-Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> < Caution-
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> > < Caution-Caution-
> Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> < Caution-Caution-
mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> > > >
[Caution-Caution-Caution-
> Caution-mailto:nanomsg- ;< Caution-mailto:nanomsg- ;> <
Caution-Caution-mailto:nanomsg- ;< Caution-mailto:nanomsg- ;> > <
> > Caution-Caution-Caution-mailto:nanomsg- ;<
Caution-mailto:nanomsg- ;> < Caution-Caution-mailto:nanomsg- ;< Caution-
mailto:nanomsg- ;> > >
> > > bounce@xxxxxxxxxxxxx <
Caution-mailto:bounce@xxxxxxxxxxxxx ;> <
Caution-Caution-mailto:bounce@xxxxxxxxxxxxx ;<
Caution-mailto:bounce@xxxxxxxxxxxxx ;> > <
Caution-Caution-Caution-mailto:bounce@xxxxxxxxxxxxx ;<
Caution-mailto:bounce@xxxxxxxxxxxxx
< Caution-> Caution-mailto:bounce@xxxxxxxxxxxxx ;<
Caution-mailto:bounce@xxxxxxxxxxxxx ;> > > <
Caution-Caution-Caution-Caution-
mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> <
Caution-Caution-mailto:nanomsg- ;< Caution-
mailto:nanomsg- ;>
> bounce@xxxxxxxxxxxxx < Caution-mailto:bounce@xxxxxxxxxxxxx ;> > <
> > Caution-Caution-Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> <
Caution-Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> > > > ] On Behalf Of
> Garrett D'Amore
> > > > Sent: Saturday, March 11, 2017 12:07 AM
> >
>
> > > > To: nanomsg@xxxxxxxxxxxxx <
Caution-mailto:nanomsg@xxxxxxxxxxxxx ;> < Caution-Caution-
mailto:nanomsg@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg@xxxxxxxxxxxxx ;> > <
Caution-Caution-
> Caution-mailto:nanomsg@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg@xxxxxxxxxxxxx ;> < Caution-Caution-
mailto:nanomsg@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg@xxxxxxxxxxxxx ;> > >
< Caution-Caution-Caution-Caution-
mailto:nanomsg@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg@xxxxxxxxxxxxx ;> <
> Caution-Caution-mailto:nanomsg@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg@xxxxxxxxxxxxx ;> > <
>
> > Caution-Caution-Caution-mailto:nanomsg@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg@xxxxxxxxxxxxx ;> < Caution-Caution-
mailto:nanomsg@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg@xxxxxxxxxxxxx ;> > > >
> > > > Subject: [Non-DoD Source] [nanomsg] status of
nng… another update
> > > >
> > > > I’ve finished the first and hardest part of
making all the patterns callback-driven. This also eliminates a number
of
> threads I
> > was
> > > firing up
> > > > per socket.
> > > >
> > > > Things still aren’t ready really, and in
particular the TCP and IPC transports for POSIX need to be altered
significantly.
> Still
> > most
> > > of the
> > > > groundwork for them is already done. Windows
will follow thereafter (and will actually be easier since I
modeled
> much on
> > > IOCP.)
> > > >
> > > > At this point, I think I’m probably only a
week or two from being ready for others to start experimenting with it,
and
> > merging it
> > > into the
> > > > master branch.
> > > >
> > > > Stay tuned.
> > > >
> > > > - Garrett
> > >
> > >
> > >
> >
> >
> >
>
>
>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
