Compatibility: How Go Programs Keep Working - Russ Cox

Поділитися
Вставка
  • Опубліковано 5 гру 2024

КОМЕНТАРІ • 20

  • @me000
    @me000 2 роки тому +44

    This video's URL ends in "Go"!!!

    • @jabuci
      @jabuci 2 роки тому

      nice catch

    • @EskoLuontola
      @EskoLuontola 2 роки тому

      I wonder how many times they had to reupload the video to get that url. 😂

  •  2 роки тому +6

    There will be no Go 2.0. Yay! Appreciated.

  • @nosuchtim
    @nosuchtim 2 роки тому +7

    Those last 2 slides make me SO happy!

  • @esra_erimez
    @esra_erimez 2 роки тому +15

    I'm so glad to hear every word spoken. As a developer, it is good to know my code will be stable with regard to the tool chain

  • @pleggli
    @pleggli 2 роки тому +32

    I like how nothing of this is new to me. Props to the Go team for having created a very easy to follow public process of change proposals/management. Excellence in boring.

  • @bredtape
    @bredtape 2 роки тому +3

    Really glad to hear that go stays at 1.x. Got spooked about non-compatible proposals to the language circulating on various forums...

  • @adamsribz
    @adamsribz 2 роки тому +4

    great stuff. i love boring code :D looking forward to more of the talks being uploaded!

  • @minhluudinh5522
    @minhluudinh5522 2 роки тому +9

    Great talk!

  • @wMwPlay
    @wMwPlay 2 роки тому +4

    23:49 such a relieve

  • @EskoLuontola
    @EskoLuontola 2 роки тому +8

    22:00 That for loop bug trap was obvious to me already in the first few months after Go's release. I complained around 20 Feb 2010 on golang-nuts, but the devs preferred the old behaviour. I'm glad that they are coming to the same realization after nearly 13 years. 😜😜

    • @kamilziemian995
      @kamilziemian995 Рік тому +1

      Yeah, they often need SOME time to response to golang-nuts threads.

  • @kamilziemian995
    @kamilziemian995 Рік тому +1

    Very good talk.

  • @jarrettvee
    @jarrettvee 2 роки тому +3

    Many other langs evolved just fine without any major backwards compatibility issues. This slow pace of innovation is not a feature IMHO. Iterators, string interpolation, opt-in/opt-out nil, better in-the-box standard libraries, the list goes on. It isn't just boring, it is painful at times. I want _go_ to succeed, but we only hear about decisions to shackle the language and almost every suggested improvement dies by committee. If _go_ is basically the same in 2032, senior engineers will just move to a language that has proper contains/map/filter support out of the box. Go is losing most of it's advantages as other languages surpass it with AOT compilation.

  • @abraham7966
    @abraham7966 2 роки тому +5

    Honestly, this is BS. A language and its maintainers should get out of the comfort zone from time to time and push the language to the next level. And I AM NOT TALKING ABOUT GO 2.0
    Who uses Go 1.0 anyways? A new language comes with a new community behind it, those using it in production may be 2 or 3 major version behind but not more than that. Specially with the release of generics. I bet everyone is upgrading to it. So much standardization ends up in stagnation. Go is easy to use, yes, but hey, why so many articles about running out of memory, or dealing with the GC or tweaking the GC. Or generics not actually using monophormism, etc. What about we make go runtime execution even faster? Why do I learn a language in a week but I then need to read 3 books about GOTCHAS in the language? If you read the book 100 Go mistakes and how to avoid them you will see how many of these you have probably made and still make today.
    I feel a bit let down here. A bunch of promises but the work has just been shifted in another direction.
    Russ Cox is slowing down the development of this language. Things truly happen when he decides it. He now wants to fix one of the major gotchas in the language after over a decade of existence.
    Why can't go have a production build process that focuses on writing the best machine code rather than being fast? I wouldn't mind waiting for 10 seconds to get a super optimized production build. Most of us on the web and directly maintaining servers need to wait for NPM/YARN to finish their production build anyways.
    Go maintainers also dread anything that has to do with performance. That list keeps getting bigger and bigger. They have fallen in the comfort zone of tackling small little issues here and there.

    • @abraham7966
      @abraham7966 2 роки тому

      Not to mention that Go is somewhat memory safe but there is a billion ways of leaking memory. Specially if you end up referencing a piece of slice that expands it's lifetime...

    • @livelypanda2195
      @livelypanda2195 Рік тому

      Lot's of companies use Go 1.x.
      Memory safety doesn't mean memory leaks cannot happen. Memory leaks can happen in Python or Java or any other language (due to objects on the heap being referenced for longer than they're needed) if the programmer does understand the data structure semantics properly. A language cannot determine the programmer's intent, only the programmer can

  • @andydufresne9387
    @andydufresne9387 Рік тому

    Too much consideration, maybe Rust's option is better.