Re: [go-nuts] Re: do you use binary-only packages?
In the past (C/C++ days) we used a lot of third-party binary-only packages like SmartHeap for memory management and LeadTools for imaging. (I like to think of that as the "Programmer's Paradise" era.) I haven't used binary-only packages in many years, but I do wonder how a company like LeadTools might make their offering available to Go developers. Presumably, they don't want to release their source code. It might be informative to get the opinions of companies like that. Mike On Thursday, October 18, 2018 at 7:28:23 PM UTC-4, Ian Lance Taylor wrote: > > On Thu, Oct 18, 2018 at 4:02 PM, Tharaneedharan Vilwanathan > > wrote: > > > > This means source-code is the only way to share the work. When it > companies > > to sharing/selling their work on top of which others can build their > > app/solution, this won't work. Doesn't this seem like a big restriction? > > Particularly, computer industry being heavily dependent on IP rights > (and > > where trust is low)? Wouldn't this deter such companies from adopting > Go? > > For contrast, I have heard of providing binary only distribution even > within > > the same company. > > The question is: is anybody actually doing this? Is anybody seriously > thinking about it? > > Ian > -- 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] Go language should become an ANSI and ISO standard.
The purpose of a standard, in my opinion, is to allow multiple implementations to be compatible. This seems counter to the open-source model, where there is a reference implementation completely in the open that encourages community participation and improvement. JavaScript needs a standard - there are many implementations and browsers. For the moment, there is only one Go, and I like that. Mike On Wednesday, October 17, 2018 at 11:41:36 AM UTC-4, Scott Cotton wrote: > > I think standards have a tendency to end up failing to be standard because > of a plethora of standards, the need to make optional parts which render > the standard impractical for basic tasks (eg open al), the fact that large > market interests tend to have their own version (eg open SL ES android), > etc. > > Small teams can make inspiring designs, such as Go. > > That said, Go lacks standardisation of the memory model and runtime. > These render the qualitative semantic of the language unspecified. To > date, in my opinion, this is a good thing because it has allowed decision > to evolve and be driven by use. > > However, I think now many of us would welcome steps towards specifications > of the memory model and runtime. Full specifications would require a lot > of diverse expertise, coordination, and effort. > > If enough people are interested in contributing to that, maybe a SIG or > two would provide an opportunity for small yet diverse teams to start to > make progress, maybe incrementally specifying these things over time rather > than a formal standards committee imposing full specifications would be > more practical. I would be interested in following that. > > > On Wednesday, 10 October 2018 18:48:57 UTC+2, Michael Jones wrote: >> >> I was the engineering director for OpenGL’s birth and growth at SGI and >> have perspective on that process, and was for a long time a board member of >> the Open Geospatial Consortium (OGC) and have views from those ISO-related >> adventures. >> >> I’m with Ian on this—I quite deeply respect standards but see them best >> as “recognition of standard practice” rather than “political arena to fight >> out new ideas.” The political aspect is not evil, it is simply >> acknowledgement of the need to respect diverse stakeholders; but what is >> bad about it, technically, is that the path finding of a small inspired >> team easily gets lost in the chorus of multitudes wanting everything. >> >> In UNIX you had a small inspired team. In almost every really great, >> lasting technology you have <= 20 people, often <= 2, who are making the >> contentious decisions. That is a critical number. The smallness allows a >> cohesive thought process, which allows spirit and flow. Big groupthink >> tends the other way, often with better individual decisions but with ideas >> that seem almost randomly distributed across the design space. >> >> I would vote to standardize Go 1 when Go 2 is out. >> >> On Wed, Oct 10, 2018 at 8:16 AM Ian Lance Taylor >> wrote: >> >>> On Wed, Oct 10, 2018 at 7:55 AM, Beoran wrote: >>> > >>> > In certain environments, such as for government contracting in certain >>> countries, or for certain large corporations, or for developing safety >>> critical applications using certain international standards, only >>> programming languages that are officially standardized may be used. While >>> Go would be an excellent language for such government or safety critical >>> applications, it's acceptance is hampered due to the lack of an official >>> standard. >>> > >>> > While this is in essence a formality, which would entail submitting >>> the current Go language specification with the ANSI, and then have it >>> propagate to the ISO, I do appreciate that will take quite some time and >>> effort. But to further the acceptance of Go language, I would propose that >>> Google invests the necessary resources to make this happen, with support >>> from the community to edit the standard document if needed. >>> > >>> > The standard should probably be based on Go 1, since Go 2 is still >>> largely undecided and probably 5 years in the future. >>> > >>> > If you are worried about using Go for safety critical applications >>> consider this: it is rare that the compiler builder gives any safety >>> warranty, although there are some safety certified C compilers. But for >>> similar certified Go compilers to be developed, we need an official >>> standard first. >>> > >>> > Even if the compiler is not certified, you can still use it if you >>> validate it yourself. This implementation of go has extensive unit tests >>> which simplifies such validation a lot. >>> > >>> > I know of some safety critical software that is implemented in C and >>> compiled with GCC. As a language, Go is far safer than that, and that is >>> also why we need a standard, to be able to get away from C for some safety >>> applications. >>> >>> There are significant disadvantag
[go-nuts] What version of BoringCrypto is used in the dev.boringcrypto branch?
Hi, we’re needing to use FIPS-validated crypto in a particular deployment. It looks like the dev.boringcrypto branch would meet our needs well. But I’m struggling to verify which BoringCrypto version is actually meant when the Go version is 1.14.1b4. Looking at BoringSSL I’m trying map b4 to a specific *validated* version like https://boringssl.googlesource.com/boringssl/+/refs/tags/fips-20170615. Does anyone know what the mapping is? i.e. what specifically is version 4 of BoringCrypto? Thanks, Mike -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0b0e1779-1f6c-46fb-b570-bd90a02d6dbd%40googlegroups.com.
Re: [go-nuts] What version of BoringCrypto is used in the dev.boringcrypto branch?
Thanks so much for the quick reply. I see where that comes from now. On Tuesday, April 7, 2020 at 12:40:52 PM UTC-4, Filippo Valsorda wrote: > > On Mon, Apr 6, 2020 at 5:45 PM Ian Lance Taylor > wrote: > >> [ + filippo ] >> >> On Mon, Apr 6, 2020 at 2:00 PM ancientlore > > wrote: >> > >> > Hi, we’re needing to use FIPS-validated crypto in a particular >> deployment. It looks like the dev.boringcrypto branch would meet our needs >> well. But I’m struggling to verify which BoringCrypto version is actually >> meant when the Go version is 1.14.1b4. Looking at BoringSSL I’m trying map >> b4 to a specific validated version like >> https://boringssl.googlesource.com/boringssl/+/refs/tags/fips-20170615. >> Does anyone know what the mapping is? i.e. what specifically is version 4 >> of BoringCrypto? >> > > Go 1.14 and earlier ship a module built according to the instructions in > certificate 2964, which maps to BoringSSL tag fips-20170615. > > > https://github.com/golang/go/blob/dev.boringcrypto.go1.14/src/crypto/internal/boring/build/build.sh > > Go 1.15 and later will hopefully ship a module built according to the > instructions in certificate 3318, which maps to BoringSSL tag fips-20180730. > > > https://github.com/golang/go/commit/6c64b188a53afec79563cf4ad3c5bc373036d3ae > > >> > Thanks, >> > >> > Mike >> > >> > -- >> > 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 golan...@googlegroups.com . >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/0b0e1779-1f6c-46fb-b570-bd90a02d6dbd%40googlegroups.com >> . >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/91b8c044-3aa0-415e-b89c-371b135c7671%40googlegroups.com.
[go-nuts] Re: [generics] Thank you Go team
+1. I found the new draft readable and in practice it feels quite natural.
My hope was always that generics would "feel like Go".
On Tuesday, June 23, 2020 at 12:34:30 PM UTC-4 Haddock wrote:
> Also big +1 from my side and kudos to Ian for always answering to this
> storm of objections and suggestions with patience and objectiveness
>
>
> Am Freitag, 19. Juni 2020 04:17:16 UTC+2 schrieb Michael Jones:
>>
>> I doubt this will help, but I have to try...
>>
>> Really smart and accomplished people have worked for a year to refine the
>> generics approach--as the impressive updated design draft and the scholarly
>> FeatherweightGo paper both demonstrate. The design is accompanied with
>> tools to allow development and experience by any interested Go developer.
>> This is marvelous. Thank you Go team and helpers!
>>
>> Let's post about substantial things in the design ("generic type switch
>> necessary at day one" maybe, whatever) and not only about parenthesis. I'm
>> going crazy here seeing all the comments about that. I mean, think of how
>> hard they are working on this; parenthesis posts read like *More Cowbell
>> *to me.
>>
>> Sorry for the outburst,
>> Michael
>>
>> P.S. I challenge you to fully read the Featherweight Go paper and the
>> design draft, as I did, and then come away thinking about the expression of
>> the idea rather than the idea. I just can't comprehend it -- it is the
>> ideas that hold power and beauty, that will transform our daily work.
>>
>> --
>>
>> *Michael T. jonesmichae...@gmail.com*
>>
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/8b476021-c0e3-4a4c-a801-f1ec62558f1cn%40googlegroups.com.
[go-nuts] [generics] Example
One of the first things I wrote in Go (in 2010) was a height-balanced binary tree. I was trying to use a number of Go's features to learn. Recently I converted this project to use generics. I tried not to deviate from the original design too much, so that they could be compared. (That said, I'm sure my design could be improved a lot, and I'll do that when generics are released.) If anyone wants to do a comparison, you can look at: https://github.com/ancientlore/go-avltree (original version) https://github.com/ancientlore/go-avltree/tree/v2 (generics version) Regards, Mike -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9e317699-6272-4fdf-b514-67dfc2f1a00en%40googlegroups.com.
[go-nuts] Re: Webservices with Windows Authentication
I haven't done it, but these two might be a starting point. https://github.com/Azure/go-ntlmssp https://github.com/ThomsonReutersEikon/go-ntlm Mike On Saturday, December 9, 2017 at 5:59:41 PM UTC-5, snmed wrote: > > Hi all > > We are primarly working in a windows environment and developing web > services as well as web applications. At the moment we're using C# as our > main language, but we consider to > switch to go for the web services. There is one major uncertainty which > hinders us to proceed with our idea, we using Group Managed Service > Accounts to authenticate applications and > services. Therefore we need to handle windows authentication on server and > client side. > > Has anyone a similar use case and has already solved it? Is there a well > documented package which can be used to protect a http.Handler and verify a > user with windows authentication? > And is there a package that can be used to authenticate a go client > against a service which is protected with windows authentication. > > Any help or advise is warmly welcome. > > Cheers > -- 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: Go Boring release schedule
In my experience, they lag maybe a week for a minor release like 1.16.6 to 1.16.7. I imagine it takes longer for a major release, especially if it's time to upgrade BoringCrypto (like b5 to b7). Mike On Friday, August 27, 2021 at 7:09:21 PM UTC-4 jonath...@gmail.com wrote: > Hey there, > > Go 1.17 was released last week (Aug 16th), but it appears the > corresponding build of Go + Boring Crypto is not available yet (checking > the Google Cloud Storage bucket as well as Docker Hub). Does anyone know if > these releases typically track the main upstream Go closely, or if releases > lag some period of time? > > I understand some folks might be on summer vacation, so wanted to check if > there's an expected publication date for this so I can plan accordingly. :) > > Thanks, > > Jonathan > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/60440880-2e81-406b-b130-c73a5626e547n%40googlegroups.com.
