[go-nuts] Where to find documentation for old Golang releases

[Leo R]

Hi ALL,
For several reasons I have to stay with Go-1.12.x. But after Go-1.13 has 
been released I cannot find 1.12 documentation online any longer. Official 
Golang portal https://golang.org only provides documentation for the latest 
release. Are there any online resources that have older versions of Go 
Language Specification and Standard Library documentation?

Thanks,
--Leo

-- 
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/8c9037a8-c8f5-41f8-8edf-b7f7e62878f6%40googlegroups.com.

Re: [go-nuts] time.Format vs. fmt.Sprintf

[Leo R]

Dan is the only one in this thread who pays attention to the actual value 
of the timestamp not just to its format :-)

--Leo

On Tuesday, July 23, 2019 at 7:45:37 PM UTC-4, Robert Engels wrote:
>
> Funny. Did you remember it or just pay close attention to these things? 
>
> > On Jul 23, 2019, at 6:38 PM, Dan Kortschak  > wrote: 
> > 
> > This thread is 7 years old. 
> > 
> >> On Tue, 2019-07-23 at 12:03 -0700, chrisho...@gmail.com  
> wrote: 
> >> Sometimes projects have upstream requirements that you can't change, 
> >> avoid, 
> >> or redefine. Sometimes you don't have a choice in how or what data 
> >> you're 
> >> providing downstream to other consumers. 
> >> 
> >> 
> >>> On Thursday, April 5, 2012 at 3:24:09 PM UTC-4, Russ Cox wrote: 
> >>> 
> >>> Maybe you should look into why you are logging in a tight loop. 
> >>> 
> >>> Russ 
> >>> 
> >>> 
> >> 
> >> 
> > 
> > -- 
> > 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/fa535c9348925f7d5fbc01c924e2569abd967eb9.camel%40kortschak.io.
>  
>
>
>

-- 
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/39f4d312-267d-41b7-a4cc-d54a4a5c7f07%40googlegroups.com.

[go-nuts] Re: Need help to learn go lang

[Leo R]

Two books immediately come to mind 
(1)  Donovan & Kernighan "The Go Programming Language", 2016
(2) Tapir Liu "Go 101", 2019   [https://go101.org/]

Book (1) is to Go what K is to C. The book (2) is a useful complementary 
exposition. Both books assume some familiarity with programming in general.

Hope it helps,
--Leo

On Friday, July 19, 2019 at 9:39:03 AM UTC-4, veeres...@gmail.com wrote:
>
> would anyone help me out how to learn go lang more practically , may be 
> some resources . I want to understand go lang more practically , with some 
> great examples.
>
> thank you!
>

-- 
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/3312a693-b9ca-47e9-a445-471fe0acfb47%40googlegroups.com.

Re: [go-nuts] Re: Go for Data Science

[Leo R]

Regarding REPL in Go, it is complicated. Currently, lgo seems to be broken 
as of go-1.12 (and go-1.13), see README.md in their repo 
https://github.com/yunabe/lgo. Until there is an official REPL blessed by 
the Go core team and included as part of tools, a random unexpected 
breakage of REPL is a sad possibility. 

gonum is a  very interesting project which plays in the same space as 
numpy. But is there anything that can replace pandas in the Go-universe?

--Leo

On Tuesday, July 16, 2019 at 6:29:50 PM UTC-4, kortschak wrote:
>
> We'd (gonum-dev) likely advise not to use julia for reasons that I 
> won't go into here. 
>
> However, I can suggest that the OP checks out the data-science channel 
> on https://gophers.slack.com/ 
>
> Also note that gorgonia does data-flow graph compilation described 
> Jesper, and there are REPLs that are available for this kind of work in 
> Go. 
>
> On Tue, 2019-07-16 at 13:07 -0700, Anca Emanuel wrote: 
> > Use the right tool for the job. https://julialang.org/ 
> >  or ask on gonum-dev 
>
>

-- 
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/37bd4e7f-ed85-45cf-b496-8ca985ad48ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go for Data Science

[Leo R]

My point is that contemporary Data Science stack is using too many 
different languages all way from scripting (R, Python) to statically 
compiled C/C++ and sometimes Fortran (R, some scipy algos are in Fortran) 
and even JVM based Scala. This creates artificial barriers -- data 
scientists play the Python/R game but struggle with Scala, software 
engineers write pipelines in Spark/Scala but have no interest in R. Often 
deploying to production requires recoding from one language to another. I 
hope as the field matures there would be more consolidation and unification 
across the language zoo. Language barriers in scientifically heavy fields 
are not healthy. In Statistics, Python's stats.models is a pale shadow of 
R's CRAN. Science community is split along the language lines that spreads 
already thin resources even further.
--Leo

On Tuesday, July 16, 2019 at 4:45:39 PM UTC-4, Jesper Louis Andersen wrote:
>
> On Tue, Jul 16, 2019 at 7:18 PM Slonik Az > 
> wrote:
>
>> REPL in a static AOT compiled language is hard, yet Swift somehow managed 
>> to implement it.
>>
>>
> I must disagree. The technique is somewhat well known and has a long 
> history. See e.g., various common lisp, and standard ml implementations. If 
> you are willing to accept a hybrid of a byte-code interpreter with a native 
> code compiler at your disposal, then ocaml and haskell will suffice in 
> addition. When a function is defined in the REPL you just call the 
> compiler, and it emits assembly language. You then mark this region as 
> executable in the memory, and you just jump to this when the function is 
> invoked. In some cases, a dispatch table is used so a function can be 
> replaced post-facto. It has fallen somewhat out of favor for the hybrid 
> approaches. Probably because modern computers are fast enough when you are 
> exploring.
>
> In my experience, most data science is about processing of data, so it is 
> suitable for doing science. Exploratory tools are good for understanding 
> the model you are working in. However, real world data processing can 
> require you to work on several terabytes of data (or more!). There is a 
> threshold where it starts becoming beneficial to optimize the processing 
> pipeline, especially the pre-processing parts. And lower level languages, 
> such as Go, tend to fare really well here. These lower level tools can then 
> be hooked into e.g., R and Python, empowering the exploratory part of the 
> system.
>
> Another important point is that modern computational kernels, for instance 
> TensorFlow, are really compilers from a data-flow graph representation to 
> highly optimized numerical routines. Some of which executes on specialized 
> numerical hardware (8-32bit floating point SIMD hardware). You can define 
> such a graph in Python, but then export it and use it in other systems and 
> pipelines. As such Python, your exploratory vehicle, provides a plug-in for 
> a more low-level processing pipeline. This also allows part of the graph to 
> run inside a mobile client. The plug in model is also followed by parallel 
> array processing language, see e.g., Futhark (https://futhark-lang.org/). 
> You embed your kernel in another system. If you read Michael Jones post, 
> there are important similarities.
>
> -- 
> J.
>

-- 
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/274c9e47-5034-489b-9ce6-f8c8bde33815%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go for Data Science

[Leo R]

Hi Michael,
thanks for your reply. The current problem with Data Science ecosystem 
(from Data Analysis all way to GPU based ML) is that it employs a whole 
stack of languages from low-level like C (and sometimes assembler) all way 
to scripting like Python or R. In parallel, there are Big Data tools, 
Spark/Scala being most popular that can process massive data sets but only 
provided a computation nicely fits its computation model (Map-Reduce and 
friends). Working with pandas or scipy or R does not feel like programming 
any longer:-) You are calling into massive APIs written by other people in 
other languages. There is realization in Deep Learning community that 
Python does not quite cut it. A proverbial saying is that "the worst thing 
about Pytorch is Python". Thus, attempts to create monolingual stacks like 
Julia, or more recently Swift TensorFlow - not quite monolingual - but with 
an ambition to gradually eat into the territory of  C++ based TF kernel. 
The same goes for Scala/Spark -- JVM with its high memory pressure is not 
the best choice for near-bare-metal calculations (a possible opening for 
Go).

I am curious whether Go will toss its hat in the ring or will leave the 
field to other players.

--Leo

On Tuesday, July 16, 2019 at 3:31:12 PM UTC-4, Michael Jones wrote:
>
> Leo,
>
> R is implemented in C and FORTRAN plus R on top of that. SAS is in C (and 
> some Go here and there) plus the SAS language in top of that. Mathematica 
> is implemented in C/C++ with the "Wolfram Language" on top of that. PARI/GP 
> is implemented in C plus some GP-language code. Macsyma, Maple, Octave, 
> Python,... follow this pattern too:
>
> 3 [glue-like meta-tools that combine various "full stack" tools]: Sage
>   :
> 2 [interactive exploration environment with scripting]: many and various, 
> including R, SAS, MMA, GP, Macsyma, Axciom, Maple, Python, ...
>   :
> 1 [performant heavy duty computation in compiled language]: C/C++
>   :
> 0 [ultra-performant kernels in C/Assembler/..]: GMP, LAPACK, BLAS, ATLAS, 
> ...
>
> You say Data Science is an application domain where Level 2 features make 
> sense, where they facilitate understanding by providing an interactive 
> environment. The evidence supports you, though understand that none of your 
> examples (or in my expanded set) actually do much at that level: this is 
> where the "convolve a with b" is specified, but the actual doing is lower, 
> in Level 0 and 1, where Go-like compiled software in C, C++, or FORTRAN 
> does the heavy lifting. (I make this point only to clarify what some people 
> seem not to understand in blogs where they write "my Python giant matrix 
> solver is just as fast as C/C++/Go, I don't see why C/C++/Go is not faster" 
> or "I don't see advantage in compiled languages.")
>
> If Go has a place in interactive, interpretive data science it seems to me 
> that it would be as the substrate language (Levels 0 and 1). Go certainly 
> has a place in statistics, applied mathematics, and other realms related to 
> data science if you want to include apps that do work and act on 
> results--control systems, analysis tools, etc. But to create an interactive 
> "play" space I'd (again, just me) be inclined to follow the PARI/GP model 
> with a Go kind of PARI and a domain-friendly GP. 
>
> The high-level GP (Mathematica, Maple, GP, SAS, ...) in the existing 
> systems often seems to me to be weak, not designed as a first-class 
> programming language but more like an endless accretion of script enabling 
> fixes and patches. I feel this especially in the way local variables are 
> defined which often feels brutish and awkward, but that extends to many 
> subtleties. It is natural that it tends this way--developers were focused 
> on the core and just needed "a way" to bind it all together. The successful 
> projects span decades and unanticipated new application domains so have 
> accumulated the most duct tape.
>
> Another goodness of this two-level scheme is that the top language can be 
> "faulty" in ways that are comfortable. For example, think how many scalar 
> variables you see in C/C++/FORTRAN/Go: "i:= 3" is the bulk of variables. 
> But in R, there are (at least when I last looked) no scalar variables(!), 
> but you can get by with vectors of length 1. This would not do, generally, 
> but for R, it may be perfect. The two-level strata design of which PARI/GP 
> is one of the best implementations, makes this kind of field-of-use 
> tailoring work fine in practice. That's important, it is matching the 
> language's exposed concepts to the problem domain.
>
> I don't see any of this as a weakness or strength of Go, or as something 
> to address in the case of