[clug] Watercooler - was Open Source Developers in CBR

Mon Sep 7 05:53:37 UTC 2020

+CLUG <linux at lists.samba.org> this time :-)


> Cool sounds like you have a handle on things!  For me rapid prototype
> means definitely not C++, maybe python but golang is more future proof
> since it is as fast to write as python but very close to c++ in execution
> speed so i wont have to rewrite it past the MVP stage.
>
> I also love that dev support is built into the language - I have written
> this blog post
> https://medium.com/velociraptor-ir/profiling-the-beast-58913437fd16
> recently - All Golang binaries have built in profiling and introspection
> tools - this means that in practice I can collect useful profiles and call
> stacks from all production binaries. I do not have to do special "debug"
> build and I dont take a performance hit to expose this feature to my users.
> This is an awesome dev experience :-) Heck I dont even have to restart the
> binary in "debug" mode - I just enable profiling for a short time and
> capture what is going on in the binary right now in production! I can not
> overstate how cool that is!
>
> I also love how the build system just works on all platforms - we actually
> run the same CI builds on windows and linux with no major code difference.
> I shudder to think of the horror of getting autotools to work on windows!
> (Although I have not tried WSL maybe this is fixed now?).
>
> Thanks
> Mike
>
>
> Mike Cohen
> Digital Paleontologist,
> Velocidex Enterprises
> M  ‭+61 470 238 491‬  <‭+61+470+238+491‬>
> E mike at velocidex.com  <mike at velocidex.com>
>
>
> On Mon, Sep 7, 2020 at 3:24 PM Brenton Ross <rossb at fwi.net.au> wrote:
>
>> Mike,
>> thanks for your thoughts.
>>
>> My project is in its early prototype / feasibility study phase at the
>> moment. Hence my focus is to get enough stuff working to be able to use
>> it to tackle the core problems which are still some way down the track.
>> Stopping to learn a new language might get a final result sooner, but
>> it would feel like an unnecessary diversion at the moment.
>>
>> You are definitely correct about the language ecosystem. I have always
>> found setting up a build environment to be an order of magnitude more
>> difficult than learning the language itself. For now I am happy with
>> autotools and C++.
>>
>> I am aware that there are many graph databases available as an
>> alternative to RDF. Perhaps one will make it into the final design, but
>> that is a problem for when I get past this feasibility study. For now
>> it appears to have a good match for the requirements.
>>
>> Brenton
>>
>> On Mon, 2020-09-07 at 12:19 +1000, Michael Cohen wrote:
>> > Hi Brenton,
>> >    I have been maintaining a C++ RDF based project for some years now
>> > (https://github.com/Velocidex/c-aff4) and while this is not meant to
>> > be a language flame war would like to share my experiences with you.
>> > Back in the old days the choice of languages was always a tradeoff
>> > between slow but fast to develop (Python/Java) or fast but harder to
>> > develop (C++/C).
>> >
>> > However in recent years a number of languages have emerged which make
>> > this tradeoff moot - specifically Golang and Rust both provide fast
>> > to
>> > execute **and** easy to develop. The choice is now a no-brainer IMHO
>> > -
>> > unless you have a legacy project to maintain C++ is rarely my first
>> > choice (I have been a professional C++ dev for many years so I am
>> > **very** familiar with the language- yet I find development velocity
>> > to be much lower than golang). These days I prefer Golang because I
>> > want to have my cake and eat it too :-).
>> >
>> > The other aspect of c++ dev which a lot of people don't mention is
>> > the
>> > poor state of portability and the build system. Go and rust have made
>> > great strides with built in cross compilers, reproducible builds out
>> > of the box and a great package management (even better than Python's
>> > pip). I always found C++ build system difficult and unmaintainable -
>> > without a docker file to completely reproduce the dev's build system
>> > it is virtually impossible for anyone to build the thing. Portability
>> > and building and packaging are a critical part of any successful
>> > software project and go beyond just the language. The language
>> > ecosystem is very important.
>> >
>> > Finally my experience with RDF was poor at best - it is a nice
>> > theoretical technology but as you point out not well supported and
>> > certainly not popular. If I had to do it all again I would not pick
>> > RDF as a standard but possibly just make my own data structures with
>> > json/protobuf . RDF adds a lot of complexity to the design which is
>> > not often needed and too much abstraction for the problem set. Unless
>> > you have to interoperate with another RDF system I would be wary of
>> > using it in a new design.
>> >
>> > At present, I find myself rewriting the above project in golang
>> > because I just had enough of maintaining that C++ mess. YMMV.
>> >
>> > Thanks
>> > Mike
>> >
>> >
>> > On Sun, 6 Sep 2020 at 17:27, Brenton Ross via linux
>> > <linux at lists.samba.org> wrote:
>> > >
>> > > Thought I might kick this thread off.
>> > >
>> > > I am currently working on a C++ wrapper for a C RDF library.
>> > >
>> > > I have a very large project in mind, one that has many different
>> > > components. The details are a story for another day, but at the
>> > > bottom
>> > > of the stack is RDF. My preferred language for the project is C++
>> > > for
>> > > its combination of speed and ability to model objects which are my
>> > > preferred way to solve programming problems.
>> > >
>> > > I intend to use as many third party open source components as I can
>> > > for
>> > > the project, mostly just to save my time. I could not find a C++
>> > > library for RDF, just the Redland C library. I did find a C++
>> > > project
>> > > that was attempting to create a wrapper for Redland but it was
>> > > looking
>> > > a bit abandoned and had some problems.
>> > >
>> > > Hence my first sub-project is to build a C++ wrapper for the
>> > > Redland C
>> > > library. I started with the source from the existing project, but
>> > > ended
>> > > just keeping one of its core design features and rewriting most of
>> > > it
>> > > using C++ features that are more recent than what the original
>> > > author
>> > > used.
>> > >
>> > > Since a database is a really boring object I am also building a GUI
>> > > program that I use to try out its functionality.
>> > >
>> > > Links:
>> > > https://sourceforge.net/p/ocratato-sassy/rdfxx/
>> > > https://sourceforge.net/p/ocratato-sassy/rdfgui/
>> > >
>> > > Brenton
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > linux mailing list
>> > > linux at lists.samba.org
>> > > https://lists.samba.org/mailman/listinfo/linux
>>
>>