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