Re: Smaller binary size

[Ori Bernstein <ori@xxxxxxxxxxxxxx>]

On Fri, 1 Dec 2017 11:10:56 +0800, nml <arumakanil@xxxxxxxxx> wrote:

> Thanks for your comprehensive response!
> 
> Regarding the big-ish design of std, I think more focused package
> organization has merits as well besides easing the link-time dead code GC.
>
> For one thing, the 'use' statements would be spread among many files when
> the package is more complex. So it's less likely to be forced into a long
> 'use' list most of the times.
>
> Secondly, the more fine-grained use list give the programmer an overview of
> what the particular file is about. (Is this file for cli arg parsing? does
> it involve any IO or networking? does it touch the file system?)
> Thirdly, it simplifies the naming of APIs. For example, 'std.htput' can be
> 'ht.put'.

You're not wrong here, although there are caveats. Each package in
the namespace is a potential naming conflict with your variables.
On top of that, webs of dependencies suck. Having one reasonably
complete baseline simplfies the dependency graph, and reduces the
tempation for bullshit like "leftpad.js"

So, sure, most of the time, I try to keep libraries focused. Libstd
is the exception, although I'd still like to keep it fairly lean.
Its goal is to be the common underpinning for all code.  That means
it gets common functions and data structures, as well as commonly
used functions that get sprinkled all over the place, but which I'd
duplicate over adding a dependency. Things like `hasprefix()` and
friends.

That said, libstd has evolved a bit organically, and there are
definitely things that are in there which don't fit the theme.
These seem to cluster in two categories:

- Mistakes: There are things that probably shouldn't have gone in,
  and can be removed with a bit of annoyance to programs. Bit sets
  jump to mind.

- Things that needed to be implemented anyways. Bigint is an example
  of this. I'd love to remove the code, I can't print floats without
  it.  As a result, I figure I might as well let somethign other
  than std.put use the code.

> I am biased here since I am used to the auto-completion of imports provided
> by the vim-go plugin. So I have yet to experience the inconvenience of long
> use/import list.
> For C, yeah, it's kind of annoying and I have seen people just resort to
> copying the entire #includes from the other files of the same program.
> 
> Maybe forbidding unused imports and an import-auto-completion tool be good
> for Myrlang too?
 
No objections if someone wants to implement import auto completion,
and I'd be happy to ship it in the support/ dir, but I don't think
that forbidding unused imports is a good idea, for two reasons.

First off, I've got libraries (eg, libescfmt) that are used entirely
through __init__ installing hooks, combined with casting.

Second, I often comment out chunks of code for debuggng, and it
would be pretty annoying to me to need to comment and uncomment the
use statement as well.

-- 
    Ori Bernstein