run.{bash,bat,rc} in Go - golang-nuts

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion run.{bash,bat,rc} in Go
Received-SPF: pass (google.com: domain of speter....@gmail.com designates 209.85.217.181 as permitted sender) client-ip=209.85.217.181;
MIME-Version: 1.0
In-Reply-To: <326B6C07B23245A999F024EDDD670...@gmail.com>
References: <CAK=G1Tg3ouhx49qWrDLgGCHTbL=qQJmfJwzF_grm+EkzCrU...@mail.gmail.com>
	<CAA8EjDRHPck19BxiVsqPA+gvhSFNiWE2sR0KQXvqC+fjw6x...@mail.gmail.com>
	<821cc93b-aa13-4913-b61b-1bdf45342a6f@googlegroups.com>
	<6f0504e5-b983-4b1e-bfc5-41fdbd37558d@googlegroups.com>
	<CAK=G1Tg4BFva-5XgxewOau4-9h+oHnswr0=TbfGChFx87m_...@mail.gmail.com>
	<326B6C07B23245A999F024EDDD670...@gmail.com>
Date: Sat, 1 Sep 2012 13:02:52 +0900
Message-ID: <CAK_MaNsZUPnmzGB0SNst6d0vDR9vjjQe_7qqu4-XeAag9z=...@mail.gmail.com>
Subject: Re: [go-nuts] run.{bash,bat,rc} in Go
From: Peter S <speter....@gmail.com>
To: Hans Stimer <hans.sti...@gmail.com>
Cc: golang-nuts@googlegroups.com
Content-Type: multipart/alternative; boundary=e89a8f23451792fdba04c89bfb64

--e89a8f23451792fdba04c89bfb64
Content-Type: text/plain; charset=ISO-8859-1

I'd add to Cons:
* Time spent by the Go team working on (reviewing, testing, merging etc)
functionally equivalent changes is time spent not working on bug fixes,
performance optimizations, and feature additions

Just looking at this single change, I might actually personally prefer Go
versions over bash scripts, but on the other hand I think there are many
other higher priority things to be done with Go (e.g. most issues marked
ASAP/Soon/Later<https://code.google.com/p/go/issues/list?q=priority%3AASAP+OR+priority%3ASoon+OR+priority%3ALater>),
so I prefer if the Go team works on those.

Peter


On Sat, Sep 1, 2012 at 12:49 PM, Hans Stimer <hans.sti...@gmail.com> wrote:

>  The topic is the pros and cons of getting rid of shell script from the
> build system:
>
> Pros:
> * Potentially more portable
> * Improved maintainability
> * Shows off Go's flexibility
>
> Cons:
> * Bootstrapping more complicated?
> * Replacing working code can lead to a temporary regression in stability
> and functionality
>
>
> On Friday, August 31, 2012 at 8:01 PM, Uriel wrote:
>
> On Sat, Sep 1, 2012 at 4:04 AM, Steven Degutis <sdegu...@8thlight.com>
> wrote:
>
> I've noticed that the majority of people with this kind of response just
> like yours are usually the same kind of people who wish to change Go to
> allow every feature that goes against its principles and are upset that
> they
> can't, for instance "Go shouldn't complain about my unused
> variables/imports" or "Go really needs generics and is unusable without it"
> or "Go should let me obtain function values from a given string which I can
> derive at runtime" or "Go needs to have an interpreter" or "Go is useless
> because it doesn't have real exceptions". And that's cool. Hey, fork it and
> add those features man, make the world a better place. It's open source :)
>
>
>
> I think you are confusing two very different groups of people.
>
> First there are those who want Go to have all the bells and whistles
> of other mainstream systems, and miss that the main point of Go (as
> Rob put it) is that it has so much less, but offers so much more. And
> that if Go added all those "features", then Go would become precisely
> what it was meant to avoid.
>
> But there is another (much smaller) camp. I know it is difficult for
> some to understand, but Go's minimalism (both as language and as
> implementation) is not radical enough to please some fundamentalist
> followers of the Unix/C/Plan 9 traditions.
>
> The Go maintainers have the difficult task of handling all this
> contradictory external expectations while trying to preserve their own
> view of what Go should be.
>
> My aim was to propose a change as minimal and uncontroversial as
> possible (there would be no functional changes, and code would be
> simpler and more maintainable) that would help make Go more palatable
> to this second camp. (There are also functional benefits, but not very
> significant beyond convenience for people running rather marginal
> platforms).
>
> I believe the change I proposed had no downsides, yet, it is the job
> of the Go maintainers (as in any other large project) so say "No!" by
> default unless they can be convinced that there is enough
> justification for a change.
>
> Where to set this bar is a tricky question, and the rather
> conservative approach by the maintainers, combined with a perhaps not
> very transparent decision making process, has discouraged people like
> Jason from being involved, which is extremely unfortunate.
>
> Anyway, sorry for turning this into a philosophical dissertation about
> software design an development.
>
> Uriel
>
>
>

--e89a8f23451792fdba04c89bfb64
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I&#39;d add to Cons:<br>* Time spent by the Go team working on (reviewing, =
testing, merging etc) functionally equivalent changes is time spent not wor=
king on bug fixes, performance optimizations, and feature additions<br><br>
Just looking at this single change, I might actually personally prefer Go v=
ersions over bash scripts, but on the other hand I think there are many oth=
er higher priority things to be done with Go (e.g. most <a href=3D"https://=
code.google.com/p/go/issues/list?q=3Dpriority%3AASAP+OR+priority%3ASoon+OR+=
priority%3ALater">issues marked ASAP/Soon/Later</a>), so I prefer if the Go=
 team works on those.<br>
<br>Peter<br><br><br><div class=3D"gmail_quote">
On Sat, Sep 1, 2012 at 12:49 PM, Hans Stimer <span dir=3D"ltr">&lt;<a href=
=3D"mailto:hans.sti...@gmail.com" target=3D"_blank">hans.sti...@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


                <div>
                    <div>The topic is the pros and cons of getting rid of s=
hell script from the build system:<div><br></div><div>Pros:</div><div>* Pot=
entially more portable</div><div>* Improved maintainability</div><div>

* Shows off Go&#39;s flexibility</div><div><br></div><div>Cons:</div><div>*=
 Bootstrapping more complicated?</div><div>* Replacing working code can lea=
d to a temporary regression in stability and functionality</div></div>
<div>
</div>
                </div><div><div>
                <div></div>
                =20
                <p style=3D"color:#a0a0a8"><br></p><p style=3D"color:#a0a0a=
8">On Friday, August 31, 2012 at 8:01 PM, Uriel wrote:</p>
                <blockquote type=3D"cite" style=3D"border-left-style:solid;=
border-width:1px;margin-left:0px;padding-left:10px">
                    <span><div><div><div>On Sat, Sep 1, 2012 at 4:04 AM, St=
even Degutis &lt;<a href=3D"mailto:sdegu...@8thlight.com" target=3D"_blank"=
>sdegu...@8thlight.com</a>&gt; wrote:</div><blockquote type=3D"cite"><div><=
div>

I&#39;ve noticed that the majority of people with this kind of response jus=
t</div><div>like yours are usually the same kind of people who wish to chan=
ge Go to</div><div>allow every feature that goes against its principles and=
 are upset that they</div>

<div>can&#39;t, for instance &quot;Go shouldn&#39;t complain about my unuse=
d</div><div>variables/imports&quot; or &quot;Go really needs generics and i=
s unusable without it&quot;</div><div>or &quot;Go should let me obtain func=
tion values from a given string which I can</div>

<div>derive at runtime&quot; or &quot;Go needs to have an interpreter&quot;=
 or &quot;Go is useless</div><div>because it doesn&#39;t have real exceptio=
ns&quot;. And that&#39;s cool. Hey, fork it and</div><div>add those feature=
s man, make the world a better place. It&#39;s open source :)</div>

</div></blockquote><div><br></div><div><br></div><div>I think you are confu=
sing two very different groups of people.</div><div><br></div><div>First th=
ere are those who want Go to have all the bells and whistles</div><div>

of other mainstream systems, and miss that the main point of Go (as</div><d=
iv>Rob put it) is that it has so much less, but offers so much more. And</d=
iv><div>that if Go added all those &quot;features&quot;, then Go would beco=
me precisely</div>

<div>what it was meant to avoid.</div><div><br></div><div>But there is anot=
her (much smaller) camp. I know it is difficult for</div><div>some to under=
stand, but Go&#39;s minimalism (both as language and as</div><div>implement=
ation) is not radical enough to please some fundamentalist</div>

<div>followers of the Unix/C/Plan 9 traditions.</div><div><br></div><div>Th=
e Go maintainers have the difficult task of handling all this</div><div>con=
tradictory external expectations while trying to preserve their own</div>

<div>view of what Go should be.</div><div><br></div><div>My aim was to prop=
ose a change as minimal and uncontroversial as</div><div>possible (there wo=
uld be no functional changes, and code would be</div><div>simpler and more =
maintainable) that would help make Go more palatable</div>

<div>to this second camp. (There are also functional benefits, but not very=
</div><div>significant beyond convenience for people running rather margina=
l</div><div>platforms).</div><div><br></div><div>I believe the change I pro=
posed had no downsides, yet, it is the job</div>

<div>of the Go maintainers (as in any other large project) so say &quot;No!=
&quot; by</div><div>default unless they can be convinced that there is enou=
gh</div><div>justification for a change.</div><div><br></div><div>Where to =
set this bar is a tricky question, and the rather</div>

<div>conservative approach by the maintainers, combined with a perhaps not<=
/div><div>very transparent decision making process, has discouraged people =
like</div><div>Jason from being involved, which is extremely unfortunate.</=
div>

<div><br></div><div>Anyway, sorry for turning this into a philosophical dis=
sertation about</div><div>software design an development.</div><div><br></d=
iv><div>Uriel</div></div></div></span>
                =20
                =20
                =20
                =20
                </blockquote>
                =20
                <div>
                    <br>
                </div>
            </div></div></blockquote></div><br>

--e89a8f23451792fdba04c89bfb64--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
