> In Go, so far changes were for the better and I'm glad to change my learning if it benefits the mass of my fellow developers.
Maybe. Let's see how times handle it. TD;DR; I praise for changes but it is not easy.. I mean, look at our society (the final reflection of us as an unique aggregated being)... there is room for improvement. We want a better place, we want changes... but ¿do I wanna change? This is a very complex affair to discuss with mate 🧉 and facturas 🥐. Dog and cats allowed too of course El dom, 1 oct 2023 a las 4:10, TheDiveO (<harald.albre...@gmx.net>) escribió: > actually, language changes happen all the time. In German, there is quite > some "misuse" esp. by journos that change or follow change in German, not > necessarily improving clearness. In Go, so far changes were for the better > and I'm glad to change my learning if it benefits the mass of my fellow > developers. > On Saturday, September 30, 2023 at 11:59:36 PM UTC+2 Victor Giordano wrote: > >> *Alex*, your second reply was even more powerful in terms of feelings >> and ideas to work with in order to embrace the change. Probably I'm >> struggling with an unexpected change... and let's see with time how it goes. >> >> *DiveO*, thanks you very mucho for your insight... I see your point. For >> me... the matter would be like ¿ what happens if a given language you know >> well suddenly changes the rules for implicit or tacit subject? Where the >> subject would be the variable and the rules for implicit or tacit subject >> would be the scope. People may wonder. Again... I guess time will answer us >> all. >> >> Greetings >> >> El sábado, 30 de septiembre de 2023 a las 16:55:24 UTC-3, TheDiveO >> escribió: >> >>> Switching between human languages, such as for me, German and English, >>> required me to learn English at a level that I think in it. Even with their >>> shared ancestry, I don't expect these languages to use the same structure >>> and concepts, like loop variable scoping. Admittedly, Go doesn't allow me >>> to switch in and out into a different language mid sentence, which in human >>> languages sometimes causes quite some hilarious reactions with my >>> colleagues. >>> >>> On Saturday, September 30, 2023 at 6:35:54 PM UTC+2 Victor Giordano >>> wrote: >>> >>>> Thanks Alex, your insight was very helpful. >>>> >>>> Allow me to share the feeling I have => I still struggle a little in my >>>> mind... I craft web fronts in javascript, and back in golang (and scala or >>>> java). With this change I will have two different scoping rules... and I >>>> feel I don't need it (because I learn how to use it well) nor ask for >>>> them... but it is okay.. changes work that way. The bottom line is: I was >>>> already comfortable with the language scope rules. >>>> >>>> El sáb, 30 sept 2023 a las 12:37, Axel Wagner (< >>>> axel.wa...@googlemail.com>) escribió: >>>> >>>>> This has come up during the discussion already. I don't know enough >>>>> about other languages to speak with confidence, but apparently there >>>>> already is precedent for this and/or some languages are at least >>>>> considering making a similar change. >>>>> >>>>> Note that scoping rules already vary between languages - in some >>>>> cases, pretty widely. For example, Python is not block scoped - this >>>>> works: >>>>> def f(): >>>>> if True: >>>>> x = 42 >>>>> print(x) >>>>> And Perl has dynamic scoping, where variables can be scoped to a call >>>>> stack, instead of any lexical element of the source code. Javascript, as >>>>> far as I know, is pretty notorious for having extremely idiosyncratic >>>>> scoping rules (e.g. it is a common confusion how `this` is scoped in >>>>> different contexts) and also has several different kinds of declarations >>>>> with AFAIK slightly different scoping rules. >>>>> In C, a symbol is only scoped to a single file (as far as the >>>>> processor is concerned) and in there, only from its declaration onwards, >>>>> while in Go, a package-scoped definition can appear in any file of any >>>>> package. And speaking of C, it doesn't have closures at all, so the >>>>> scoping >>>>> rules of loop variables are *already* very different. >>>>> >>>>> So I think the case that you *currently* don't have to be aware of how >>>>> a language is using scoping is pretty vastly overstated. What's more, the >>>>> majority of programs won't actually be affected by this - and for those >>>>> that are, it seems that empirically, the new rules will align more closely >>>>> with what people expect subconsciously. >>>>> >>>>> I don't think you should worry too much. Run your tests with the new >>>>> loop variable semantics in Go 1.21 to see if everything still works. Most >>>>> likely, it will - or you will discover a bug in your current code. >>>>> >>>>> On Sat, Sep 30, 2023 at 4:58 PM Victor Giordano <vituc...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi gophers! How you doing? >>>>>> >>>>>> In my work we recently discuss with a buddy about this article >>>>>> <https://go.dev/blog/loopvar-preview>. I need to talk about this.... >>>>>> >>>>>> I appreaciate that golang makes a lot of effort on this. Working with >>>>>> clousures cames with perils and the go vet tool emiting a warning is a >>>>>> great thing. >>>>>> >>>>>> Althought I do not think that chaning language semantics is something >>>>>> 100% good, see my point: As long I use several languages for making a >>>>>> system this "scope rule" will mismatch with other languajes, for example, >>>>>> javascript. >>>>>> >>>>>> So from now onwards I shall be aware that for loops have variables >>>>>> scopes in one fashion in Golang and in other fashion in another >>>>>> languages... so at the end of the day, I feel like is adding some burden. >>>>>> If for development we can use a single and sole language (Sauron don't >>>>>> read >>>>>> this :P !) I would think this change is good, but that is not the case in >>>>>> now-a-days. I try to think that with time, perhaps other languages >>>>>> evolves >>>>>> it this way... but.. ¿what if I wanna have my "for loop" with legacy >>>>>> scope >>>>>> (block scope, not per iteration scope)? >>>>>> >>>>>> So... I expect to the readers to talk with me, showing what they see >>>>>> and feel. Is not my intention to generate hard feelings at all. I'm a >>>>>> person that work crafting system in group with others.. I have had >>>>>> terrible >>>>>> nightmares working with Scala where implicits and invoking methods as >>>>>> they >>>>>> were feilds were terrible ideas for working in group (perhaps not if you >>>>>> work solo). And this feature recalls me those feelings. >>>>>> >>>>>> Greetings >>>>>> Víctor. >>>>>> >>>>>> -- >>>>>> 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/5f31be67-d246-4778-a373-69d525772974n%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/golang-nuts/5f31be67-d246-4778-a373-69d525772974n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> >>>> >>>> -- >>>> V >>>> >>> -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/okbLcVOBLAU/unsubscribe. > To unsubscribe from this group and all its topics, 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/7dcf1819-b6e3-4daf-a7b6-b753903eef18n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/7dcf1819-b6e3-4daf-a7b6-b753903eef18n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- V -- 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/CAPUu9svxknQu_ES%3DjFEMH5PqSDDtpiZ%2B5MLTUUxC%3Dy%3DDQp0B_g%40mail.gmail.com.