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> 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-----On Behalf Of Garrett D'Amore
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx]
Sent: Monday, March 13, 2017 11:49 AMof nng… another update
To: nanomsg@xxxxxxxxxxxxx
Subject: [nanomsg] Re: [nanomsg] RE: [Non-DoD Source] [nanomsg] status
the identity of the sender, and confirm the authenticity of all links
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.
cases, I’d probably write in Go first, and indeed the Go version
________________________________
Sadly I don’t have any such paper already written. For my own use
(mangos) has worked out really really well.like libdill as foundation layer, and then writing the same way I’d
If I was not worried about interoperability I might consider something
have done with Go. Unfortunately, I don’t think the state of C is suchthat one can safely use any of the various coroutine libraries in a
library intended for broad consumption — there are simply too manycaveats (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 seemsto 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 ofcreating the real C11 threads.
bindings…. that may make it easier for you to work with, but it makes the
I’m not a big fan of writing in another language and providing C
library more complex for your consumers, and can limit portability toother platforms. For example, Rust isn’t available on many
embedded targets. In fact, even going the other way, where a C core isused 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 forwhat the protocols are, and native language implementations. This
is more work for sure, but for the languages where the native codeexists, I believe the result is superior for all parties concerned.
generally preferable if you have a comfortable development environment.
In terms of shim vs. going native to the OS target — the latter is
Sometimes you don’t, or need to work with parties who don’t have accessto real hardware. (This comes up in embedded work.) In
*those* cases simulation layers can allow progress to be made. Thatsaid, it also helps if you can isolate your access to OS-specific services
into a portability layer. This allows the greatest portability, andallows work to be done on multiple platforms. For example, I primarily
work on macOS (my desktop) these days, but the ability to quickly runthe code on Linux gives me access to some extra tooling (valgrind in
particular), which is immensely helpful.is start by determining what your goals are. nanomsg has a pretty
The main thing I’d say, if you’re planning to undertake such a project,
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 yourgoals are more limited in scope, you can probably take a greatly
simplified approach — for example if I didn’t have to worry aboutportability or coexistence with OS threads, I’d have been able to use a
coroutine library pretty darn easily, and saved myself many hours ofwork.
<cem.f.karan.civ@xxxxxxxx < Caution-
- Garrett
On Mon, Mar 13, 2017 at 6:25 AM, Karan, Cem F CIV USARMY RDECOM ARL (US)
mailto:cem.f.karan.civ@xxxxxxxx ;> > wrote:a request for your opinion if you had to do it all over again, so
Garrett, this is not a request to change how nng works, it's just
please take it in that grain.now have, would you use callbacks, or would you use something
If you had to do it all over again with all of the knowledge you
else (green threads, coroutines, etc.)? Would you write it all in C, orwould you write the core in another language and provide bindings in
C (and other languages)? Would you make the core work directly withcalls the OS provides, or would you develop some kind of shim
layer so that you could test the core in simulation before making itlive? I'm thinking about various methods of writing my own
communications library, and would like to get your opinions on what youthink worked well, and what would need to be changed.
because my target is unreliable and semi-reliable communications
For those wondering why I would consider writing my own, it's
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 ;> ) wasdesigned to handle, but over networks whose topology is constantly
in flux. In my ideal world the heart of the code could be ported overto real networks after being tested out on a simulator, but this
requires some careful design and planning, which is why I wanted to seewhat Garrett has learned.
'lesson's learned' type of paper or article that you've written, I'd love to
Actually, now that I think about it, Garrett, if you have a
have a pointer to it so I can see the lay of the land before I getthere...
nanomsg-bounce@xxxxxxxxxxxxx > [Caution-mailto:nanomsg-
Thanks,
Cem Karan
> -----Original Message-----
> From: nanomsg-bounce@xxxxxxxxxxxxx < Caution-mailto:
bounce@xxxxxxxxxxxxx < Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> ]On Behalf Of Garrett D'Amore
> Sent: Saturday, March 11, 2017 12:07 AMpatterns callback-driven. This also eliminates a number of threads I was
> To: 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
firing upIPC transports for POSIX need to be altered significantly. Still most
> per socket.
>
> Things still aren’t ready really, and in particular the TCP and
of thethereafter (and will actually be easier since I modeled much on
> groundwork for them is already done. Windows will follow
IOCP.)being ready for others to start experimenting with it, and merging it
>
> At this point, I think I’m probably only a week or two from
into the
> master branch.
>
> Stay tuned.
>
> - Garrett
