[GTALUG] A find alternative: fselect

[ac]

On Thu, 13 Jun 2019 11:20:17 -0400
Alvin Starr via talk <talk at gtalug.org> wrote:
> On 6/13/19 10:40 AM, David Mason via talk wrote:
> > My preface: 40 years of C programming is enough! I don’t plan to
> > write any more C; where I need that low-level efficiency, I’ll use
> > Rust. Ditto no C++; if I want objects, I’ll do it right with
> > Smalltalk.
> > With that said, Hugh makes a legitimate point (if we were talking 
> > apples and apples).  
> >> On Thu, Jun 13, 2019 at 1:12 AM (actually, earlier) D. Hugh 
> >> Redelmeier wrote:  
> >  |   Rust culture and practice doesn’t seem to like shared
> > libraries.. I do.
> >
> > Rust does tend to create static code from crates (its packaging 
> > system). But C does too, for source code that you compile into your 
> > code. The difference is that, because crates are understood by the 
> > compiler it is *much* easier to make decisions about what version
> > you want in Rust.
> >
> > Rust also *does* use dynamic libraries for C/system code. I have a
> > web server that uses sqlite3 and the generated executable includes
> > the sqlite3, resolve, and system dynamic libraries.
> >
> > So the static part is the crates, and it is trivial to discard the 
> > previously frozen versions and compile with the latest versions.
> >
> > HOWEVER, since Rust code is intrinsically much, much safer than C 
> > code, stability of API is much more legitimate a characterizer of
> > the version that you want than bug-fixes (and bug-fixes are almost
> > never security/safety related). Rust uses semantic versioning of
> > crates, so you can specify, e.g. version 2.3.* of a crate, to get
> > any bug-fixes without any breaking changes.
> >  
> Your mixing issues here.
> 
> C defiantly has a number of shortcomings and features that can shoot
> you in the foot but that has nothing to do with shared libraries.
> 
> Shared libraries are not a "feature" of C and any programming 
> environment can be designed to have shared runtime linkable modules.
> 
> The first reason to not have runtime linkable modules is because
> doing it right is complex and it has take the unix world decades to
> get the current reliable and stable environment working.
> 
> As for versioning most times versions are to keep track of bug fixes
> and no matter how safe and rigorous  a programming language is
> programmers are much smarter and find ways to introduce bugs into
> their code.
> 
> Having to recompile your programs whenever there is a version change
> to a sub sub sub module is a major pain in the ass and just imagine
> you had to rebuild your whole linux system any time there was a
> software change.
> 
> There are lots of reasons to not use runtime linkable libraries but
> none of those reasons is the perceived "safety" of the language.
> 

Well stated Alvin, I had to delete my reply after reading yours :)
so now I can just economically add : +1

Andre