1. 1

    God, how did we get here?

    1. 24

      This is getting tiresome. It’s always the same points rehashed. Why beat the same dead horse?

      1. 13

        Because they are beating a dead horse and ignoring that Go is an excellent pony.

        Many languages are weak at limiting ever expanding dependencies and build times. Go addresses this, and also has an excellent deployment story.

        Go was created partly out of frustration with C++ within Google and addresses many things that takes years to see that are problems in the first place.

        1. 7

          This. Go does a lot of things wrong, but it got so much things right, ebough to make itself relevant.

          1. 6

            … addresses many things that takes years to see that are problems in the first place.

            Very eloquently said. Throwing the kitchen sink into a language means supporting a ton of problematic patterns and footguns.

            For example, even though I think everyone, even in the Go community, accepts that generics are pretty useful, doing them well means trade-offs. When you’ve seen some of the bizarre ways people abuse them in C++, it should give you pause that they’re always-good-no-caveats. Which is why the Featherweight Go paper that forms the model for Go’s eventual generics plan is heartening — it may not be perfect either, but it applies some wisdom to the right way to go about it without jumping into the deep end.

            1. 5

              C++ templates are also unusually terrible as far as templates go. I don’t think this is a strong argument.

              I think this is less “Templates let you write really bad code” and more “C++ lets you write really bad code with templates.” For instance, D templates are much nicer - and more powerful.

          2. 9

            This is getting tiresome. It’s always the same points rehashed. Why beat the same dead horse?

            As someone who changed languages from PHP to Go, after all these years I … still have no clue why people feel the need to do that.

            But I’ve learned to smile. In my imagination I pat the “smart” developer on the head and just continue with my day. You know, making useful stuff that people like. If people need to vent, let them vent. But don’t take a blog post as gospel, just because it contains a lot of strong opinions.

            1. 7

              Why beat the same dead horse?

              Usually because someone is forcing them to write Go and the terrible pain it causes them squirts out in a blog post.

              1. 3

                I do not see how anybody is “forced” to write Go. The market is so hot right now that anyone can just switch jobs if they are forced to program in a language they do not like.

              2. 2

                It looks like the author is a D-lang person.

                You know the meme, about D programmers, misunderstood who think their language is the best, etc.

              1. 35

                This is a good opportunity to plug a technology that’s been around since well before WebSockets, is widely supported on both the client and server sides, was designed for precisely the kind of use case the article is focused on, and, bizarrely, seems virtually unknown in the developer community: Server-Sent Events.

                1. 8

                  Server-Sent Events are one of my favorite technologies.

                  1. 4

                    SSE is a specific implementation of long-polling, no?

                    1. 9

                      Sort of. The implementations of long-polling I’ve seen are usually, “Keep the connection open until the server has an event to deliver, then deliver it as the response payload and end the request.” The client then immediately makes another long-polling request.

                      SSE is more of a streaming approach. A single connection stays open indefinitely and events are delivered over it as they become available. In that sense it’s more like WebSockets than traditional long-polling.

                      1. 2

                        It is with a different interface and more efficient bandwidth usage.

                        1. 3

                          And a built-in protocol for reconnections and catching up on messages you missed while you were out.

                      2. 1

                        I remember discovering Server-Sent Events and taking great joy in the simplicity of just going one way.

                        1. 1

                          Indeed.

                          You can also get away with implementing an “endless” request dlivering JSON lines, like the Twitter Streaming API.

                        1. 6

                          I guess the author is disappointed by the community having forgotten the core value of the language as a mind expanding tool for exploring concepts and ideas, and being defined by its technical limitations and success cases? Idk.

                          I think that the author should look beyond and acknowledge the massive impact ruby had in this wave of new programming languages: rust, go, swift, zig, they all borrowed something from ruby. It’s a pretty powerful legacy.

                          Also, I think the author should look beyond rails and recognize those values in other tools of the ecosystem. They might not have a conf named after them, and capture less of the overall community, but they are nonetheless rarkavle examples of what can be achieved with ruby with a bit of creativity.

                          1. 4

                            I’m very curious what features you think those languages borrowed from Ruby.

                            Ruby is effectively what happens when you wish Smalltalk could replace Perl. I expect most thngs are at very least borrowed from an ancestor, but even then Ruby and most ancestors are very dynamic and introspective and the languages in your list are all very much the opposite.

                            1. 10

                              For sure Rust “borrowed” closure syntax from Ruby. In early designs for i in iter {} was even written as iter.each |i| {} AFAIK. Also some of the “core Ruby” people went to Rust, for example @steveklabnik.

                              I have no idea what @honeyryderchuck meant in other languages though. Swift maybe with the named arguments, but that comes from common ancestry in Smalltalk, not from Ruby itself.

                              1. 4

                                What @hauleth said from rust. Swift syntax is full of rubyisms, and I felt it was a direct influence at the time of its announcement. Go’s structural typing with implicit interfaces has been many times described as “safe duck typing”; im not saying that it was directly influenced by the duck typing that ruby popularized, but the fact it was advertised as such, makes it suggest that an audience was being targeted. I also left out elixir, which is ruby lipstick on erlang/beam.

                                I might have pushed it with zig though, but I felt some UX brushes of ruby in the tutorials I’ve seen. Bu maybe that was my ruby brain deceiving me.

                                Ruby tooling has also been very influência in other communities. Take a look at bundler, which directly inspired yarn or cargo.

                                1. 1

                                  I know this is all subjective, so I’m just going to ask about the duck typing one. While I don’t know the timeline on the terminology, I feel like it’s so pervasive it can’t be mainly from Ruby, but maybe I’m wrong. Python and Javascript are duck-typed. Smalltalk of course. Any LISP with an object system (CLOS, GLOOP, etc) – and of course Haskell type classes etc are also the “safe duck typing” thing

                                  1. 1

                                    You’re correct, python, and also other dynamic languages also fit the bill of duck typing. I just feel that no one was using it to describe that sort of loose type system before ruby popularized it. I certainly hadn’t before 2007. But it might have come from smalltalk, most definitely.

                            1. 1

                              I was under the impression that OpenID died with the Web 2.0 and its promise of an open connected world.

                              Apparently this OpenID “Connect” is a reboot of the concept on top of OAuth. Good work :)

                              1. 2

                                Thank you. OpenID Connect is a kind of a “2.0” from the original, which aims at being a simple “shim” on top of existing OAuth 2.0 infrastructure. Is what Google uses for its “Sign in with Google” integrations. It’s been getting a lot of adoption. I think in your country (is it Spain?), Talkdesk is a known implementer of the functionality.

                              1. 0

                                Tragedy of the commons

                                1. 2

                                  It doesn’t read as such to me. Can you expand?

                                  1. 3

                                    My whole take on this is on the batteries included mind-set of rails. The number of transitive dependencies grows with each release (how many are they right now? 80 gems?). The long tail of those get unfortunately very little maintenance, usually from one person, who now has to acquiesce to the whims of the community. This situation brings him little recognition or even help, just more complaints with each rails breaking change that might break the integration.

                                    And them something like this happens. Nevermind that a lot of apps handle file uploads via other alternatives like paperclip or shrine, which predate activestorage. Because of the Rais way of shipping everything by default, the build is now broken.

                                    This would not have happened, for instance, with shrine, which supports many strategies for mime type detection, and leaves the choice to you.

                                    This whole situation about to happen. The long tails of rails dependencies is filled of gems that receive very little maintenance or support, and are liable for such situations, like some copied file from a different license years ago (this case), or some maintainer rage quitting and taking the sink with him (leftpad, which didn’t happen yet in rails, but could)

                                    1. 1

                                      Thanks a lot for expanding!

                                      1. 1

                                        Because of the Rais way of shipping everything by default, the build is now broken.

                                        Bundler has built in support for storing your dependencies in-repo so that you do not depend on a third-party service for your CI / deploy pipeline. You didn’t use it, and it bit you when the third-party service didn’t do what you expected. The same technique would also have stopped left-pad from being an issue.

                                        1. 2

                                          You’re preaching the preacher. I know how to set up CI caches. I also know how to use rails and not install activestorage. I prefer not to use rails though, safest option. But I’m not the default in the rails community. And saying “well you shoulda…” is hardly gonna make anyone feel better about it.

                                  1. 2

                                    The Rust of WebGL

                                    1. 2

                                      I think, what OP is saying with this is, “when the hell did we decide that next.js or gatsby setup were necessary to re-do your homepage”?