[go-nuts] Re: Adding YAML to the stdlib

[paraiso . marc]

Anybody can write a spec and deem it a standard.

YAML is certainly not a common data serialization format. Adding a YAML 
parser is in my opinion the least of of Go's priorities when one can see 
all the packages pilling up @ /x/ namespace that should have been in the 
stdlib already. More tools supporting XML development might actually make 
more sense, like support for SAX,XML schema,SOAP, XSL,XPath and all these 
API a lot of entreprise developers still need to interact with. Because 
frankly working with XML in Go is a pain in the arse.

Le vendredi 23 septembre 2016 22:02:51 UTC+2, Zachary Gershman a écrit :
>
> Gustavo - it is not jus that YAML is well known, it is also widely used 
> (as I even mentioned). It is a *standard *even though some may not want 
> to consider it as such. If I can read xml in the stdlib why not yaml? And 
> it is widely supported now but are you committed to supporting it for as 
> long as golang is around?
>
> On Friday, September 23, 2016 at 11:28:27 AM UTC-7, Gustavo Niemeyer wrote:
>>
>> Hi Zachary,
>>
>> You have already seen the thread, but for the benefit of others, Zach's 
>> email comes from a thread raised and replied to yesterday on Twitter:
>>
>> https://twitter.com/jvehent/status/778687333956587522
>>
>> As I said there, the yaml spec is big, messy, and I wouldn't encourage 
>> having the package in the distribution of Go. Something being well known 
>> and appreciated is not a reason to have it in the standard library.
>>
>> Also, there's nothing unfair about maintaining go-yaml. This was 
>> developed years ago while porting the first projects of Canonical to Go, 
>> and is by now widely used there, and we remain committed to supporting it. 
>> I also receive regular fixes and contributions from the community, and 
>> nobody seems upset to do so.
>>
>> The most recent change was to replace the LGPL license by Apache, which 
>> was well received. I was able to negotiate that based on requested from the 
>> community, and were were able to do so due to the CLA that is requested for 
>> contributions (ironic that most people CLA's as evil, yet it was used to 
>> open permissions further).
>>
>>
>>
>> On Fri, Sep 23, 2016 at 2:53 PM, Zachary Gershman  
>> wrote:
>>
>>> Hey All,
>>>
>>> I wanted to get feedback here first before I move this over to the 
>>> golang-dev mailing list (or maybe we even just start a change-set).  YAML 
>>> as a spec is not the greatest and some would even describe it as "gross" 
>>> but most if not all config files are written in some form of YAML (see 
>>> kubernetes as a prime example).  YAML was not included in the stdlib and 
>>> luckily for all of us the awesome go-yaml 
>>>  emerged as the de facto standard for 
>>> a majority of developers.
>>>
>>> Now, inclusion into the stdlib must pass a high bar 
>>>  and not everything can / should 
>>> be included but I believe that when you have over 1300 packages 
>>>  depending on an outside 
>>> library, you should at least have the discussion openly about whether it 
>>> should be moved into the stdlib.
>>>
>>> Also, it is slightly unfair to have the expectation that the community 
>>> should support a significant format through independent OSS work.
>>>
>>
>>
>>
>> -- 
>>
>> gustavo @ http://niemeyer.net
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Adding YAML to the stdlib

[Gustavo Niemeyer]

On Fri, Sep 23, 2016 at 5:02 PM, Zachary Gershman 
wrote:

> Gustavo - it is not jus that YAML is well known, it is also widely used
> (as I even mentioned). It is a *standard *even though some may not want
> to consider it as such. If I can read xml in the stdlib why not yaml? And
> it is widely supported now but are you committed to supporting it for as
> long as golang is around?
>

Things don't need to be on the standard library for people to conveniently
benefit from them, whether widely used or not.

And I also don't need to commit my life to yaml. :)  The package is
Canonical's copyright and nicely licensed, and if we drop the ball someone
else can pick it up, as usual in open source. The fact we've been
maintaining it for years and it's widely used as you point out probably
means we're not doing such a bad job, though.


gustavo @ http://niemeyer.net

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Adding YAML to the stdlib

[Zachary Gershman]

Gustavo - it is not jus that YAML is well known, it is also widely used (as 
I even mentioned). It is a *standard *even though some may not want to 
consider it as such. If I can read xml in the stdlib why not yaml? And it 
is widely supported now but are you committed to supporting it for as long 
as golang is around?

On Friday, September 23, 2016 at 11:28:27 AM UTC-7, Gustavo Niemeyer wrote:
>
> Hi Zachary,
>
> You have already seen the thread, but for the benefit of others, Zach's 
> email comes from a thread raised and replied to yesterday on Twitter:
>
> https://twitter.com/jvehent/status/778687333956587522
>
> As I said there, the yaml spec is big, messy, and I wouldn't encourage 
> having the package in the distribution of Go. Something being well known 
> and appreciated is not a reason to have it in the standard library.
>
> Also, there's nothing unfair about maintaining go-yaml. This was developed 
> years ago while porting the first projects of Canonical to Go, and is by 
> now widely used there, and we remain committed to supporting it. I also 
> receive regular fixes and contributions from the community, and nobody 
> seems upset to do so.
>
> The most recent change was to replace the LGPL license by Apache, which 
> was well received. I was able to negotiate that based on requested from the 
> community, and were were able to do so due to the CLA that is requested for 
> contributions (ironic that most people CLA's as evil, yet it was used to 
> open permissions further).
>
>
>
> On Fri, Sep 23, 2016 at 2:53 PM, Zachary Gershman  > wrote:
>
>> Hey All,
>>
>> I wanted to get feedback here first before I move this over to the 
>> golang-dev mailing list (or maybe we even just start a change-set).  YAML 
>> as a spec is not the greatest and some would even describe it as "gross" 
>> but most if not all config files are written in some form of YAML (see 
>> kubernetes as a prime example).  YAML was not included in the stdlib and 
>> luckily for all of us the awesome go-yaml 
>>  emerged as the de facto standard for a 
>> majority of developers.
>>
>> Now, inclusion into the stdlib must pass a high bar 
>>  and not everything can / should be 
>> included but I believe that when you have over 1300 packages 
>>  depending on an outside 
>> library, you should at least have the discussion openly about whether it 
>> should be moved into the stdlib.
>>
>> Also, it is slightly unfair to have the expectation that the community 
>> should support a significant format through independent OSS work.
>>
>
>
>
> -- 
>
> gustavo @ http://niemeyer.net
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Adding YAML to the stdlib

[Gustavo Niemeyer]

Hi Zachary,

You have already seen the thread, but for the benefit of others, Zach's
email comes from a thread raised and replied to yesterday on Twitter:

https://twitter.com/jvehent/status/778687333956587522

As I said there, the yaml spec is big, messy, and I wouldn't encourage
having the package in the distribution of Go. Something being well known
and appreciated is not a reason to have it in the standard library.

Also, there's nothing unfair about maintaining go-yaml. This was developed
years ago while porting the first projects of Canonical to Go, and is by
now widely used there, and we remain committed to supporting it. I also
receive regular fixes and contributions from the community, and nobody
seems upset to do so.

The most recent change was to replace the LGPL license by Apache, which was
well received. I was able to negotiate that based on requested from the
community, and were were able to do so due to the CLA that is requested for
contributions (ironic that most people CLA's as evil, yet it was used to
open permissions further).



On Fri, Sep 23, 2016 at 2:53 PM, Zachary Gershman 
wrote:

> Hey All,
>
> I wanted to get feedback here first before I move this over to the
> golang-dev mailing list (or maybe we even just start a change-set).  YAML
> as a spec is not the greatest and some would even describe it as "gross"
> but most if not all config files are written in some form of YAML (see
> kubernetes as a prime example).  YAML was not included in the stdlib and
> luckily for all of us the awesome go-yaml
>  emerged as the de facto standard for a
> majority of developers.
>
> Now, inclusion into the stdlib must pass a high bar
>  and not everything can / should be
> included but I believe that when you have over 1300 packages
>  depending on an outside
> library, you should at least have the discussion openly about whether it
> should be moved into the stdlib.
>
> Also, it is slightly unfair to have the expectation that the community
> should support a significant format through independent OSS work.
>



-- 

gustavo @ http://niemeyer.net

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.