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 > <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. > > -- > 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 "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/9E81A7A3-4479-4E2E-B04B-E5EFFD00239C%40ix.netcom.com.
