[go-nuts] Re: Short Variable Declarations Are Oversold

[tapi...@gmail.com]

Type inference is not the main purpose (or even the purpose) of short 
declarations.
I do agree that the negative impact of short declarations is larger than 
its positive impact,
for reasons different from the one you described. Some reasons:
* short declarations causes confusions (esp, for new gophers) at some 
situations.
* short declarations overlap too much functionalities with normal 
declarations.
* short declarations indeed hurt readabilities at some situations (but not 
the ones as you described).

On Sunday, April 23, 2023 at 6:31:11 AM UTC+8 jlfo...@berkeley.edu wrote:

> As a beginning Go programmer, I was initially attracted to the short 
> variable declaration syntax.
>
> It’s great for declaring variables of a simple type. What could be wrong 
> with letting the Go compiler infer a variable type by looking at what’s 
> being assigned to the variable, such as:
>
> func main() {
>
> x := 10
>
> }
>
> Nothing. This is trivially the same as
>
> func main() {
>
> var x int
>
> x = 10
>
> }
>
> I didn’t have to waste my precious time by entering an explicit type 
> declaration for “x” when the compiler already knew what it was.
>
> But what about something like
>
> import “os”
>
> func main() {
>
>  file, _ := os.Open(os.Args[1])
>
> }
>
> Again, nothing is wrong, at least not until I have to pass “file” to 
> another function. For example
>
> import “os”
>
> func main() {
>
>  file, _ := os.Open(os.Args[1])
>
> myfunc(file)
>
> }
>
> func myfunc(file ???) {
>
> }
>
> What type should I use to declare “file” in the parameter list for 
> myfunc()? As a new Go programmer I have to admit that I haven’t memorized 
> all the types used in the Go standard library. So, I have to break off 
> working on myfunc() to look up the type returned by os.Open(). This isn’t a 
> huge deal, but it’s a distraction and can waste time. I suppose that as I 
> gain experience with Go, I’ll have to do this less and less.
>
> But, it doesn’t matter how experienced I am with Go when I start using 
> user-defined types from packages that aren’t in the Go standard library. 
> For example (from Ben Hoyt’s excellent goawk program):
>
> import "github.com/benhoyt/goawk/parser"
>
> func main() {
>
> prog, err := parser.ParseProgram(fileReader.Source(), parserConfig)
>
> myfunc(prog)
>
> }
>
> func myfunc(prog ???) {
>
> }
>
> Since I’m going to have to look up the returned types of 
> parse.ParseProgram anyway, what’s the advantage of using a short variable 
> declaration? They just delay the inevitable.
>
> Short definitions detract from one of Go’s primary goals - readability. I 
> started using Go in the first place because I wanted a strongly typed 
> language with explicit type declarations. 
>
> As a result of all this, I’ve started to avoid short variable 
> declarations, except when I’m initializing a variable inside an "if" 
> , "for" 
> , or "switch 
> ” statement, such as
>
> if v := math.Pow(x, n); v < lim {
>
> }
>
> for i := 0; i < 10; i++ {
>
> }
>
> switch os := runtime.GOOS; os {
>
> }
>
> In these cases I have no choice if I want to declare local temporary 
> variables since long declarations aren’t syntactically allowed.
>
> I doubt if this note will change anybody’s mind but it’s something to 
> think about.
>

-- 
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/8c5aeb04-bcd7-45c3-94a1-d128f9cb0834n%40googlegroups.com.

Re: [go-nuts] Why is there no pure StableSort in golang.org/x/exp/slices?

[Uli Kunitz]

I have written the code now and run a benchmark. In the benchmark function 
slices.Sort is 9% faster than slices.SortFunc, which is ca. 9% faster than 
slices.SortStableFunc for my benchmark. I don't need stable sort, but 
assumed that merge sorting would benefit more from presorted runs.

On Sunday, April 23, 2023 at 8:57:59 AM UTC+2 Axel Wagner wrote:

> It has not been added because it is pointless. Stable sorting is generally 
> slower than regular sorting, as it puts extra constraints on the output and 
> keeping to those makes things slower. And for a total order, *every* 
> sorting algorithm produces a stable sort, as stability only matters if you 
> have distinguishable but not ordered elements, which can't happen for total 
> orders. Discounting NaN and ±0 issues, < is a total order and it doesn't 
> seem worth it to add a new API for the sole purpose of promising to sort 
> NaNs stably.
>
> On Sun, Apr 23, 2023 at 8:05 AM Uli Kunitz  wrote:
>
>> I have a use case where I have to sort int32 slices repeatedly that are 
>> already partially sorted.  (Imagine a tree of smaller non-overlapping 
>> segments of the same slice, where sorting starts at the bottom and moves to 
>> the top and the results of the individual sorts are required for the 
>> algorithm.) Speed is critical for the use case. The StableSort method is an 
>> excellent first approach for it, because it uses the SymMerge algorithm and 
>> for small blocks InsertionSort benefiting from pre-sorted runs. Small 
>> performance improvements benefit the use case, so I looked at 
>> golang.org/x/exp/slices which contains a SortStableFunc but not a pure 
>> SortStable method, which I would like to use because I need only the order 
>> implied by the default less-than (<) operator. For non-stable sorting there 
>> is pure Sort function, so I wonder why SortStable has been left out. Has it 
>> not been added because of the NAN issue? 
>>
>> For now I can live with SortStableFunc since I plan a custom sort using 
>> the knowledge of the positions of the sorted sub-segments,  but I'm puzzled 
>> about the lack of a pure SortStable.
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/89ad151a-a604-45d5-a6a4-620c0024060an%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/6f86b936-3149-4f31-800e-0b69cd96a6c5n%40googlegroups.com.

Re: [go-nuts] ¿ Where is the source code of atomic.AddInt32?

[Eli Lindsey]

Hi Victor,

This shows that the code you linked is a shim over runtime/internal/atomic: 
https://cs.opensource.google/go/go/+/refs/tags/go1.20.3:src/sync/atomic/asm.s;l=40

In runtime/internal/atomic you’ll find asm implementations specific to the 
various supported architectures. For example, here is the implementation for 
x86_64: 
https://cs.opensource.google/go/go/+/refs/tags/go1.20.3:src/runtime/internal/atomic/atomic_amd64.s;l=83

> If the burden of what is happening implies to assambly code I will be 
> satisfied with any shallow explanation.

What the assembly does will vary by architecture, so it depends on which one 
you’re interested in. 
Many arches have built-in support for atomics, so the asm will look like a 
regular exchange-and-add with some additional prefix to say “do this 
atomically” (eg. on the above x86-64 this is LOCK XADD, 
https://www.felixcloutier.com/x86/xadd).

aarch64/arm64 is a good example of how this may vary though - 
https://cs.opensource.google/go/go/+/refs/tags/go1.20.3:src/runtime/internal/atomic/atomic_arm64.s;l=228
In this case it’s detecting if atomics are supported and using them if so 
(LDADD, similar to x86’s LOCK XADD). But not all arm64 revisions support atomic 
arithmetic, so if unavailable it falls back to a load/add/store loop, retrying 
the add until it succeeds without conflict.

-eli

> On Apr 23, 2023, at 3:23 PM, Victor Giordano  wrote:
> 
> Hi there! 
> 
> Hope you are having a great weekend (This is actually friendly greeting and 
> you may greet me as well, it will be more than welcome)
> 
>  I reach this line 
> 
>  and that is folks!
> 
> 
> I was expetecting to find something like
> 
> mutex.Lock()
> (*intParam)++
> mutex.Unlock()
> 
> Can anyone give a little insight of this. If the burden of what is happening 
> implies to assambly code I will be satisfied with any shallow explanation. If 
> the first time I saw code in golang that reseembles the code in Java prefixed 
> with native keyword.
> 
> Thanks!
> 
> 
> -- 
> 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/c4c2a754-b282-4905-9cbe-19fe8f5355a6n%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/319CBFCB-C5EA-4653-A62E-E5407CA91E39%40siliconsprawl.com.

Re: [go-nuts] ¿ Where is the source code of atomic.AddInt32?

[Ian Lance Taylor]

On Sun, Apr 23, 2023 at 12:23 PM Victor Giordano 
wrote:

> Hi there!
>
> Hope you are having a great weekend (This is actually friendly greeting
> and you may greet me as well, it will be more than welcome)
>
>  I reach this line
> 
>  and
> that is folks!
>
> I was expetecting to find something like
>
> mutex.Lock()
> (*intParam)++
> mutex.Unlock()
>
> Can anyone give a little insight of this. If the burden of what is
> happening implies to assambly code I will be satisfied with any shallow
> explanation. If the first time I saw code in golang that reseembles the
> code in Java prefixed with native keyword.


The implementation is written in assembler, in the file asm.s.  In the
current implementation it just jumps to the implementation in the
runtime/internal/atomic package.  In that package, for most targets, look
at the atomic_GOARCH.s file.

It's not normally implemented using a mutex, it's normally implemented
using processor-specific atomic instructions.

And I'll add that actually the implementation in runtime/internal/atomic
isn't normally used, normally the function is implemented directly by the
compiler.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWhiEDuygWwn8wab-jki9pG5R3a4zu67OzWFGiAum8eyw%40mail.gmail.com.

[go-nuts] ¿ Where is the source code of atomic.AddInt32?

[Victor Giordano]

Hi there! 

Hope you are having a great weekend (This is actually friendly greeting and 
you may greet me as well, it will be more than welcome)

 I reach this line 

 and 
that is folks!
[image: That's All Folks! | Warner Bros. Entertainment Wiki | Fandom]

I was expetecting to find something like

mutex.Lock()
(*intParam)++
mutex.Unlock()

Can anyone give a little insight of this. If the burden of what is 
happening implies to assambly code I will be satisfied with any shallow 
explanation. If the first time I saw code in golang that reseembles the 
code in Java prefixed with native keyword.

Thanks!

-- 
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/c4c2a754-b282-4905-9cbe-19fe8f5355a6n%40googlegroups.com.

Re: [go-nuts] Short Variable Declarations Are Oversold

[Robert Engels]

I wouldn’t have don’t it that way. I would have made := mean all variables must 
be new. And = mean any new variable requires a decoration. 

So in this case,

var x,err = means x is new and err is reused. The variable clauses are 
segregated by a ,  



> On Apr 23, 2023, at 9:07 AM, Axel Wagner  
> wrote:
> 
> 
> 
> On Sun, Apr 23, 2023 at 4:01 PM Robert Engels  wrote:
>> Personally that syntax has always bothered me with readability. It requires 
>> lots of previous knowledge in some cases. A syntax like
>> 
>> x, var y int = blah
>> 
>> Is more explicit that x is reused and y is declared. 
> 
> That specific suggestion would not work. It would mean it is ambiguous 
> whether `var x, err = fmt.Println()` is mean to be a declaration of only x, 
> or both - and note that this specific order is the more relevant, as `err` is 
> the specific variable that tends to be re-used by `:=`.
> There probably could be alternatives though. But that seems a moot point now.
> 
>  
>> 
>> Go is all about being explicit until it isn’t. 
>> 
>> 
>> 
>>> On Apr 23, 2023, at 8:28 AM, 'Axel Wagner' via golang-nuts 
>>>  wrote:
>>> 
>>> Just to nit-pick everyone: Short variable declarations are not there to 
>>> omit type information. You can do that with a regular variable declaration:
>>> https://go.dev/play/p/6XePFCh-6G2
>>> Short variable declarations exist to 1. be shorter and 2. allow you to 
>>> avoid re-declaration errors when assigning multiple variables:
>>> https://go.dev/play/p/bgbU9mTunhL
>>> So, IMO short variable declarations definitely increase readability, just 
>>> by that latter effect. Type-inference is a bonus.
>>> 
>>> On Sun, Apr 23, 2023 at 3:09 PM Jesper Louis Andersen 
>>>  wrote:
 On Sun, Apr 23, 2023 at 12:31 AM jlfo...@berkeley.edu 
  wrote:
> 
> Short definitions detract from one of Go’s primary goals - readability. I 
> started using Go in the first place because I wanted a strongly typed 
> language with explicit type declarations. 
 
 Your claim of readability is not held by everyone. Some people prefer 
 there be no type information in a program because the type information 
 "detracts from what the program is doing". Hence, it becomes rather hard 
 to please everybody.
 
 Short variable declarations are a poor man's type inference. In fully 
 type-inferred languages, you can omit types everywhere, and the compiler 
 will deduce an appropriate type for each declaration. It will typically 
 pick the most general type for an expression. The type information is 
 still there, but it is generated on-demand by the compiler, and programs 
 which fail the type check are rejected. Haskell and OCaml are good 
 examples of programming languages following this style. Yet in both 
 languages, you often see type declarations sprinkled throughout the code 
 base to guide the reader. You sort-of assume a certain amount of 
 experience, and add types as you see fit to capture that experience. 
 Often, you end up with your interfaces being type-annotated, but your 
 internal code avoiding annotation.
 
 The grand advantage of type inference is that the types can vary easily. 
 If you change a fundamental type, the compiler will check that your change 
 is sound. And you don't have to go around the code base and change every 
 occurrence. That's a really nice boon.
 
 We are slowly moving into a world where the compiler and the programmer 
 are working on the code at the same time. You ask the compiler to fill out 
 gaps in the programs you are writing. The result is that your editor can 
 live-annotate the appropriate types of declarations and expressions 
 because it can be lifted from the compiler. When I write OCaml, for 
 instance, my editor annotates functions with types for me by adding a line 
 above the function declaration in a smaller font. These lines only occur 
 virtually in the buffer, and aren't present in the program file.
 
 For some languages, such as Agda, the interaction is even stronger: you 
 can ask the compiler to fill in parts of the program based on the types 
 they have. That is, types and terms coalesce and there is no 
 stratification between them. Writing a term makes the compiler deduce the 
 type. Writing a type makes the compiler deduce and fill in the term. 
 Coming strong into this are large language models from machine learning. 
 You can fill in lots of gaps in programs via LLMs. Programming often 
 contains a lot of janitorial tasks around a computational kernel and LLMs 
 can accelerate the janitor. In the future, I hope someone takes an LLM and 
 starts exploiting type information. I have a hunch it's going to be far 
 more effective for languages which have static type systems (inferred or 
 not) because there's a much richer set of information you can exploit.
 

Re: [go-nuts] Short Variable Declarations Are Oversold

['Axel Wagner' via golang-nuts]

On Sun, Apr 23, 2023 at 4:01 PM Robert Engels  wrote:

> Personally that syntax has always bothered me with readability. It
> requires lots of previous knowledge in some cases. A syntax like
>
> x, var y int = blah
>
> Is more explicit that x is reused and y is declared.
>

That specific suggestion would not work. It would mean it is ambiguous
whether `var x, err = fmt.Println()` is mean to be a declaration of only x,
or both - and note that this specific order is the more relevant, as `err`
is the specific variable that tends to be re-used by `:=`.
There probably could be alternatives though. But that seems a moot point
now.



>
> Go is all about being explicit until it isn’t.
>
>
>
> On Apr 23, 2023, at 8:28 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> 
> Just to nit-pick everyone: Short variable declarations are not there to
> omit type information. You can do that with a regular variable declaration:
> https://go.dev/play/p/6XePFCh-6G2
> Short variable declarations exist to 1. be shorter and 2. allow you to
> avoid re-declaration errors when assigning multiple variables:
> https://go.dev/play/p/bgbU9mTunhL
> So, IMO short variable declarations definitely increase readability, just
> by that latter effect. Type-inference is a bonus.
>
> On Sun, Apr 23, 2023 at 3:09 PM Jesper Louis Andersen <
> jesper.louis.ander...@gmail.com> wrote:
>
>> On Sun, Apr 23, 2023 at 12:31 AM jlfo...@berkeley.edu <
>> jlforr...@berkeley.edu> wrote:
>>
>>>
>>> Short definitions detract from one of Go’s primary goals - readability.
>>> I started using Go in the first place because I wanted a strongly typed
>>> language with explicit type declarations.
>>>
>>>
>> Your claim of readability is not held by everyone. Some people prefer
>> there be no type information in a program because the type information
>> "detracts from what the program is doing". Hence, it becomes rather hard to
>> please everybody.
>>
>> Short variable declarations are a poor man's type inference. In fully
>> type-inferred languages, you can omit types everywhere, and the compiler
>> will deduce an appropriate type for each declaration. It will typically
>> pick the most general type for an expression. The type information is still
>> there, but it is generated on-demand by the compiler, and programs which
>> fail the type check are rejected. Haskell and OCaml are good examples of
>> programming languages following this style. Yet in both languages, you
>> often see type declarations sprinkled throughout the code base to guide the
>> reader. You sort-of assume a certain amount of experience, and add types as
>> you see fit to capture that experience. Often, you end up with your
>> interfaces being type-annotated, but your internal code avoiding annotation.
>>
>> The grand advantage of type inference is that the types can vary easily.
>> If you change a fundamental type, the compiler will check that your change
>> is sound. And you don't have to go around the code base and change every
>> occurrence. That's a really nice boon.
>>
>> We are slowly moving into a world where the compiler and the programmer
>> are working on the code at the same time. You ask the compiler to fill out
>> gaps in the programs you are writing. The result is that your editor can
>> live-annotate the appropriate types of declarations and expressions because
>> it can be lifted from the compiler. When I write OCaml, for instance, my
>> editor annotates functions with types for me by adding a line above the
>> function declaration in a smaller font. These lines only occur virtually in
>> the buffer, and aren't present in the program file.
>>
>> For some languages, such as Agda, the interaction is even stronger: you
>> can ask the compiler to fill in parts of the program based on the types
>> they have. That is, types and terms coalesce and there is no stratification
>> between them. Writing a term makes the compiler deduce the type. Writing a
>> type makes the compiler deduce and fill in the term. Coming strong into
>> this are large language models from machine learning. You can fill in lots
>> of gaps in programs via LLMs. Programming often contains a lot of
>> janitorial tasks around a computational kernel and LLMs can accelerate the
>> janitor. In the future, I hope someone takes an LLM and starts exploiting
>> type information. I have a hunch it's going to be far more effective for
>> languages which have static type systems (inferred or not) because there's
>> a much richer set of information you can exploit.
>>
>>
>>
>> --
>> 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/CAGrdgiVd3BMOKE6ohRbwTmC_AhSY3Zht4LxK%3DFQjqj_YocoZAg%40mail.gmail.com
>> 

Re: [go-nuts] Short Variable Declarations Are Oversold

[Robert Engels]

To clarify, the semantics of a go statement from a language perspective changes 
based on earlier statements. That is simply weird - and hurts readability. 

> On Apr 23, 2023, at 9:01 AM, Robert Engels  wrote:
> 
> 
> Personally that syntax has always bothered me with readability. It requires 
> lots of previous knowledge in some cases. A syntax like
> 
> x, var y int = blah
> 
> Is more explicit that x is reused and y is declared. 
> 
> Go is all about being explicit until it isn’t. 
> 
> 
> 
>>> On Apr 23, 2023, at 8:28 AM, 'Axel Wagner' via golang-nuts 
>>>  wrote:
>>> 
>> 
>> Just to nit-pick everyone: Short variable declarations are not there to omit 
>> type information. You can do that with a regular variable declaration:
>> https://go.dev/play/p/6XePFCh-6G2
>> Short variable declarations exist to 1. be shorter and 2. allow you to avoid 
>> re-declaration errors when assigning multiple variables:
>> https://go.dev/play/p/bgbU9mTunhL
>> So, IMO short variable declarations definitely increase readability, just by 
>> that latter effect. Type-inference is a bonus.
>> 
>>> On Sun, Apr 23, 2023 at 3:09 PM Jesper Louis Andersen 
>>>  wrote:
 On Sun, Apr 23, 2023 at 12:31 AM jlfo...@berkeley.edu 
  wrote:
 
 Short definitions detract from one of Go’s primary goals - readability. I 
 started using Go in the first place because I wanted a strongly typed 
 language with explicit type declarations. 
 
>>> 
>>> Your claim of readability is not held by everyone. Some people prefer there 
>>> be no type information in a program because the type information "detracts 
>>> from what the program is doing". Hence, it becomes rather hard to please 
>>> everybody.
>>> 
>>> Short variable declarations are a poor man's type inference. In fully 
>>> type-inferred languages, you can omit types everywhere, and the compiler 
>>> will deduce an appropriate type for each declaration. It will typically 
>>> pick the most general type for an expression. The type information is still 
>>> there, but it is generated on-demand by the compiler, and programs which 
>>> fail the type check are rejected. Haskell and OCaml are good examples of 
>>> programming languages following this style. Yet in both languages, you 
>>> often see type declarations sprinkled throughout the code base to guide the 
>>> reader. You sort-of assume a certain amount of experience, and add types as 
>>> you see fit to capture that experience. Often, you end up with your 
>>> interfaces being type-annotated, but your internal code avoiding annotation.
>>> 
>>> The grand advantage of type inference is that the types can vary easily. If 
>>> you change a fundamental type, the compiler will check that your change is 
>>> sound. And you don't have to go around the code base and change every 
>>> occurrence. That's a really nice boon.
>>> 
>>> We are slowly moving into a world where the compiler and the programmer are 
>>> working on the code at the same time. You ask the compiler to fill out gaps 
>>> in the programs you are writing. The result is that your editor can 
>>> live-annotate the appropriate types of declarations and expressions because 
>>> it can be lifted from the compiler. When I write OCaml, for instance, my 
>>> editor annotates functions with types for me by adding a line above the 
>>> function declaration in a smaller font. These lines only occur virtually in 
>>> the buffer, and aren't present in the program file.
>>> 
>>> For some languages, such as Agda, the interaction is even stronger: you can 
>>> ask the compiler to fill in parts of the program based on the types they 
>>> have. That is, types and terms coalesce and there is no stratification 
>>> between them. Writing a term makes the compiler deduce the type. Writing a 
>>> type makes the compiler deduce and fill in the term. Coming strong into 
>>> this are large language models from machine learning. You can fill in lots 
>>> of gaps in programs via LLMs. Programming often contains a lot of 
>>> janitorial tasks around a computational kernel and LLMs can accelerate the 
>>> janitor. In the future, I hope someone takes an LLM and starts exploiting 
>>> type information. I have a hunch it's going to be far more effective for 
>>> languages which have static type systems (inferred or not) because there's 
>>> a much richer set of information you can exploit.
>>> 
>>> 
>>> 
>>> -- 
>>> 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/CAGrdgiVd3BMOKE6ohRbwTmC_AhSY3Zht4LxK%3DFQjqj_YocoZAg%40mail.gmail.com.
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop 

Re: [go-nuts] Short Variable Declarations Are Oversold

[Robert Engels]

Personally that syntax has always bothered me with readability. It requires 
lots of previous knowledge in some cases. A syntax like

x, var y int = blah

Is more explicit that x is reused and y is declared. 

Go is all about being explicit until it isn’t. 



> On Apr 23, 2023, at 8:28 AM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> 
> Just to nit-pick everyone: Short variable declarations are not there to omit 
> type information. You can do that with a regular variable declaration:
> https://go.dev/play/p/6XePFCh-6G2
> Short variable declarations exist to 1. be shorter and 2. allow you to avoid 
> re-declaration errors when assigning multiple variables:
> https://go.dev/play/p/bgbU9mTunhL
> So, IMO short variable declarations definitely increase readability, just by 
> that latter effect. Type-inference is a bonus.
> 
>> On Sun, Apr 23, 2023 at 3:09 PM Jesper Louis Andersen 
>>  wrote:
>>> On Sun, Apr 23, 2023 at 12:31 AM jlfo...@berkeley.edu 
>>>  wrote:
>>> 
>>> Short definitions detract from one of Go’s primary goals - readability. I 
>>> started using Go in the first place because I wanted a strongly typed 
>>> language with explicit type declarations. 
>>> 
>> 
>> Your claim of readability is not held by everyone. Some people prefer there 
>> be no type information in a program because the type information "detracts 
>> from what the program is doing". Hence, it becomes rather hard to please 
>> everybody.
>> 
>> Short variable declarations are a poor man's type inference. In fully 
>> type-inferred languages, you can omit types everywhere, and the compiler 
>> will deduce an appropriate type for each declaration. It will typically pick 
>> the most general type for an expression. The type information is still 
>> there, but it is generated on-demand by the compiler, and programs which 
>> fail the type check are rejected. Haskell and OCaml are good examples of 
>> programming languages following this style. Yet in both languages, you often 
>> see type declarations sprinkled throughout the code base to guide the 
>> reader. You sort-of assume a certain amount of experience, and add types as 
>> you see fit to capture that experience. Often, you end up with your 
>> interfaces being type-annotated, but your internal code avoiding annotation.
>> 
>> The grand advantage of type inference is that the types can vary easily. If 
>> you change a fundamental type, the compiler will check that your change is 
>> sound. And you don't have to go around the code base and change every 
>> occurrence. That's a really nice boon.
>> 
>> We are slowly moving into a world where the compiler and the programmer are 
>> working on the code at the same time. You ask the compiler to fill out gaps 
>> in the programs you are writing. The result is that your editor can 
>> live-annotate the appropriate types of declarations and expressions because 
>> it can be lifted from the compiler. When I write OCaml, for instance, my 
>> editor annotates functions with types for me by adding a line above the 
>> function declaration in a smaller font. These lines only occur virtually in 
>> the buffer, and aren't present in the program file.
>> 
>> For some languages, such as Agda, the interaction is even stronger: you can 
>> ask the compiler to fill in parts of the program based on the types they 
>> have. That is, types and terms coalesce and there is no stratification 
>> between them. Writing a term makes the compiler deduce the type. Writing a 
>> type makes the compiler deduce and fill in the term. Coming strong into this 
>> are large language models from machine learning. You can fill in lots of 
>> gaps in programs via LLMs. Programming often contains a lot of janitorial 
>> tasks around a computational kernel and LLMs can accelerate the janitor. In 
>> the future, I hope someone takes an LLM and starts exploiting type 
>> information. I have a hunch it's going to be far more effective for 
>> languages which have static type systems (inferred or not) because there's a 
>> much richer set of information you can exploit.
>> 
>> 
>> 
>> -- 
>> 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/CAGrdgiVd3BMOKE6ohRbwTmC_AhSY3Zht4LxK%3DFQjqj_YocoZAg%40mail.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/CAEkBMfFtaM2KMPxRYdaFS79O0vf91RPzQBHwHa2CLJWB6r5DJQ%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 

Re: [go-nuts] Short Variable Declarations Are Oversold

['Axel Wagner' via golang-nuts]

Just to nit-pick everyone: Short variable declarations are not there to
omit type information. You can do that with a regular variable declaration:
https://go.dev/play/p/6XePFCh-6G2
Short variable declarations exist to 1. be shorter and 2. allow you to
avoid re-declaration errors when assigning multiple variables:
https://go.dev/play/p/bgbU9mTunhL
So, IMO short variable declarations definitely increase readability, just
by that latter effect. Type-inference is a bonus.

On Sun, Apr 23, 2023 at 3:09 PM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

> On Sun, Apr 23, 2023 at 12:31 AM jlfo...@berkeley.edu <
> jlforr...@berkeley.edu> wrote:
>
>>
>> Short definitions detract from one of Go’s primary goals - readability. I
>> started using Go in the first place because I wanted a strongly typed
>> language with explicit type declarations.
>>
>>
> Your claim of readability is not held by everyone. Some people prefer
> there be no type information in a program because the type information
> "detracts from what the program is doing". Hence, it becomes rather hard to
> please everybody.
>
> Short variable declarations are a poor man's type inference. In fully
> type-inferred languages, you can omit types everywhere, and the compiler
> will deduce an appropriate type for each declaration. It will typically
> pick the most general type for an expression. The type information is still
> there, but it is generated on-demand by the compiler, and programs which
> fail the type check are rejected. Haskell and OCaml are good examples of
> programming languages following this style. Yet in both languages, you
> often see type declarations sprinkled throughout the code base to guide the
> reader. You sort-of assume a certain amount of experience, and add types as
> you see fit to capture that experience. Often, you end up with your
> interfaces being type-annotated, but your internal code avoiding annotation.
>
> The grand advantage of type inference is that the types can vary easily.
> If you change a fundamental type, the compiler will check that your change
> is sound. And you don't have to go around the code base and change every
> occurrence. That's a really nice boon.
>
> We are slowly moving into a world where the compiler and the programmer
> are working on the code at the same time. You ask the compiler to fill out
> gaps in the programs you are writing. The result is that your editor can
> live-annotate the appropriate types of declarations and expressions because
> it can be lifted from the compiler. When I write OCaml, for instance, my
> editor annotates functions with types for me by adding a line above the
> function declaration in a smaller font. These lines only occur virtually in
> the buffer, and aren't present in the program file.
>
> For some languages, such as Agda, the interaction is even stronger: you
> can ask the compiler to fill in parts of the program based on the types
> they have. That is, types and terms coalesce and there is no stratification
> between them. Writing a term makes the compiler deduce the type. Writing a
> type makes the compiler deduce and fill in the term. Coming strong into
> this are large language models from machine learning. You can fill in lots
> of gaps in programs via LLMs. Programming often contains a lot of
> janitorial tasks around a computational kernel and LLMs can accelerate the
> janitor. In the future, I hope someone takes an LLM and starts exploiting
> type information. I have a hunch it's going to be far more effective for
> languages which have static type systems (inferred or not) because there's
> a much richer set of information you can exploit.
>
>
>
> --
> 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/CAGrdgiVd3BMOKE6ohRbwTmC_AhSY3Zht4LxK%3DFQjqj_YocoZAg%40mail.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/CAEkBMfFtaM2KMPxRYdaFS79O0vf91RPzQBHwHa2CLJWB6r5DJQ%40mail.gmail.com.

Re: [go-nuts] Short Variable Declarations Are Oversold

[Jesper Louis Andersen]

On Sun, Apr 23, 2023 at 12:31 AM jlfo...@berkeley.edu <
jlforr...@berkeley.edu> wrote:

>
> Short definitions detract from one of Go’s primary goals - readability. I
> started using Go in the first place because I wanted a strongly typed
> language with explicit type declarations.
>
>
Your claim of readability is not held by everyone. Some people prefer there
be no type information in a program because the type information "detracts
from what the program is doing". Hence, it becomes rather hard to please
everybody.

Short variable declarations are a poor man's type inference. In fully
type-inferred languages, you can omit types everywhere, and the compiler
will deduce an appropriate type for each declaration. It will typically
pick the most general type for an expression. The type information is still
there, but it is generated on-demand by the compiler, and programs which
fail the type check are rejected. Haskell and OCaml are good examples of
programming languages following this style. Yet in both languages, you
often see type declarations sprinkled throughout the code base to guide the
reader. You sort-of assume a certain amount of experience, and add types as
you see fit to capture that experience. Often, you end up with your
interfaces being type-annotated, but your internal code avoiding annotation.

The grand advantage of type inference is that the types can vary easily. If
you change a fundamental type, the compiler will check that your change is
sound. And you don't have to go around the code base and change every
occurrence. That's a really nice boon.

We are slowly moving into a world where the compiler and the programmer are
working on the code at the same time. You ask the compiler to fill out gaps
in the programs you are writing. The result is that your editor can
live-annotate the appropriate types of declarations and expressions because
it can be lifted from the compiler. When I write OCaml, for instance, my
editor annotates functions with types for me by adding a line above the
function declaration in a smaller font. These lines only occur virtually in
the buffer, and aren't present in the program file.

For some languages, such as Agda, the interaction is even stronger: you can
ask the compiler to fill in parts of the program based on the types they
have. That is, types and terms coalesce and there is no stratification
between them. Writing a term makes the compiler deduce the type. Writing a
type makes the compiler deduce and fill in the term. Coming strong into
this are large language models from machine learning. You can fill in lots
of gaps in programs via LLMs. Programming often contains a lot of
janitorial tasks around a computational kernel and LLMs can accelerate the
janitor. In the future, I hope someone takes an LLM and starts exploiting
type information. I have a hunch it's going to be far more effective for
languages which have static type systems (inferred or not) because there's
a much richer set of information you can exploit.



-- 
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/CAGrdgiVd3BMOKE6ohRbwTmC_AhSY3Zht4LxK%3DFQjqj_YocoZAg%40mail.gmail.com.

Re: [go-nuts] Short Variable Declarations Are Oversold

[Shulhan]

23 Apr 2023 05:31:25 jlfo...@berkeley.edu :


> Short definitions detract from one of Go’s primary goals - readability. I 
> started using Go in the first place because I wanted a strongly typed 
> language with explicit type declarations. 
>
> As a result of all this, I’ve started to avoid short variable declarations, 
> except when I’m initializing a variable inside an 
> "if"[https://go.dev/ref/spec#If_statements], 
> "for"[https://go.dev/ref/spec#For_statements], or 
> "switch[https://go.dev/ref/spec#Switch_statements]” statement, such as
>
...
>
> I doubt if this note will change anybody’s mind but it’s something to think 
> about.
>

I agree with OP and probably this is one of the unpopular opinion about Go 
style.

My reasoning is based on three things [1]. First, readability, as also pointed 
out by OP.  Given the following statement

t := f()

If you are new to code base, you need to know the signature of f to know the 
type of t. To minimize back and forth when reading code, it is better to 
declare the type of t before or along with assignment. Yes, some advanced IDE 
may provide clickable link, unfortunately not all of us use IDE when developing 
Go.

Second, minimize local, temporary variables.

Third, prevent subtle bugs [2][3][4] caused by shadowing.

For a long term code base, I try to enforce the variable to be declared 
explicitly with downside more line of codes.

[1] 
https://kilabit.info/journal/2017/05/Go_Informal_Coding_Style#avoid__if_possible
[2] https://github.com/golang/go/issues/377
[3] https://github.com/golang/go/issues/20733
[4] https://github.com/golang/go/issues/21291

-- 
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/3110d5fb-37e5-4654-a373-df9b480832b5%40gmail.com.

Re: [go-nuts] Re: Home directory?

[Amnon]

Ok Jan, you are right. They do still play a part under the hood.
So external modules get cached under $GOMODCACHE which is $GOPATH/pkg/mod 
by default
and go install installs executables under $GOBIN which is $GOPATH/bin by 
default.

But my point is that (apart from $GOBIN), this is something that the 
end-user no longer needs to bother themselves with.
Unlike the earliest go versions, you no longer need to set GOPATH in order 
to compile your code.
And you no longer need to insert your code into a directory tree under 
GOPATH. 

On Sunday, 23 April 2023 at 09:49:40 UTC+1 Jan Mercl wrote:

> On Sun, Apr 23, 2023 at 10:28 AM Amnon  wrote:
>
> > Yes GOPATH and GOROOT have been deprecated.
>
> Both are alive and well. They are essential for the build system/go
> command to work as required.
>
> tl;dr: There's a default value of GOPATH so one does not have to set
> it. A much longer version can be obtained by '$ go help gopath'.
>

-- 
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/de5284b3-2a85-4870-9229-51db75f062ffn%40googlegroups.com.

Re: [go-nuts] Re: Home directory?

[Jan Mercl]

On Sun, Apr 23, 2023 at 10:28 AM Amnon  wrote:

> Yes GOPATH and GOROOT have been deprecated.

Both are alive and well. They are essential for the build system/go
command to work as required.

tl;dr: There's a default value of GOPATH so one does not have to set
it. A much longer version can be obtained by '$ go help gopath'.

-- 
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/CAA40n-V%2BR6o9XNN%3DXwoOt3t6WABe0ch69Pc3%2BV-S8QPW7dGRoQ%40mail.gmail.com.

[go-nuts] Re: Home directory?

[Amnon]

I looked at https://go.dev/doc/tutorial/create-module 
it only has two mentions of, which are just suggestions regarding where to 
create your working directory.
But it is just a suggestion, and you can choose any location which is 
convenient for you. 

Yes GOPATH and GOROOT have been deprecated. Any tutorials which tell you to 
put your code under $GOPATH are ancient history
and should be ignored. 

On Sunday, 23 April 2023 at 09:16:59 UTC+1 joseph.p...@gmail.com wrote:

> In the ‘Create a Go Module’ documentation, it keeps referencing ‘home 
> directory’ and uses the unix command ‘cd’.
>
> Do they literally mean my unix home directory or do they mean my GOPATH 
> directory?
>
> Have GOPATH and GOROOT been deprecated?
>
> Thanks,
>
> Hoe
>

-- 
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/ac730909-ba56-49d9-86a7-a743d5a801f5n%40googlegroups.com.

[go-nuts] Home directory?

[joseph.p...@gmail.com]

In the ‘Create a Go Module’ documentation, it keeps referencing ‘home 
directory’ and uses the unix command ‘cd’.

Do they literally mean my unix home directory or do they mean my GOPATH 
directory?

Have GOPATH and GOROOT been deprecated?

Thanks,

Hoe

-- 
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/adf24fcc-3530-4e7c-8e74-b48f3b54933cn%40googlegroups.com.

Re: [go-nuts] Why is there no pure StableSort in golang.org/x/exp/slices?

['Axel Wagner' via golang-nuts]

It has not been added because it is pointless. Stable sorting is generally
slower than regular sorting, as it puts extra constraints on the output and
keeping to those makes things slower. And for a total order, *every*
sorting algorithm produces a stable sort, as stability only matters if you
have distinguishable but not ordered elements, which can't happen for total
orders. Discounting NaN and ±0 issues, < is a total order and it doesn't
seem worth it to add a new API for the sole purpose of promising to sort
NaNs stably.

On Sun, Apr 23, 2023 at 8:05 AM Uli Kunitz  wrote:

> I have a use case where I have to sort int32 slices repeatedly that are
> already partially sorted.  (Imagine a tree of smaller non-overlapping
> segments of the same slice, where sorting starts at the bottom and moves to
> the top and the results of the individual sorts are required for the
> algorithm.) Speed is critical for the use case. The StableSort method is an
> excellent first approach for it, because it uses the SymMerge algorithm and
> for small blocks InsertionSort benefiting from pre-sorted runs. Small
> performance improvements benefit the use case, so I looked at
> golang.org/x/exp/slices which contains a SortStableFunc but not a pure
> SortStable method, which I would like to use because I need only the order
> implied by the default less-than (<) operator. For non-stable sorting there
> is pure Sort function, so I wonder why SortStable has been left out. Has it
> not been added because of the NAN issue?
>
> For now I can live with SortStableFunc since I plan a custom sort using
> the knowledge of the positions of the sorted sub-segments,  but I'm puzzled
> about the lack of a pure SortStable.
>
> --
> 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/89ad151a-a604-45d5-a6a4-620c0024060an%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/CAEkBMfF4VzZx%3DGR6%3DfNFrgjKuzEtLrOEn9UduwqUrotJhq%2BeHA%40mail.gmail.com.

[go-nuts] Why is there no pure StableSort in golang.org/x/exp/slices?

[Uli Kunitz]

I have a use case where I have to sort int32 slices repeatedly that are 
already partially sorted.  (Imagine a tree of smaller non-overlapping 
segments of the same slice, where sorting starts at the bottom and moves to 
the top and the results of the individual sorts are required for the 
algorithm.) Speed is critical for the use case. The StableSort method is an 
excellent first approach for it, because it uses the SymMerge algorithm and 
for small blocks InsertionSort benefiting from pre-sorted runs. Small 
performance improvements benefit the use case, so I looked at 
golang.org/x/exp/slices which contains a SortStableFunc but not a pure 
SortStable method, which I would like to use because I need only the order 
implied by the default less-than (<) operator. For non-stable sorting there 
is pure Sort function, so I wonder why SortStable has been left out. Has it 
not been added because of the NAN issue? 

For now I can live with SortStableFunc since I plan a custom sort using the 
knowledge of the positions of the sorted sub-segments,  but I'm puzzled 
about the lack of a pure SortStable.

-- 
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/89ad151a-a604-45d5-a6a4-620c0024060an%40googlegroups.com.