13 ms·

Comments like this are what drives me away from Go; comments that enforce a particular belief about how or what features you should or should not use/introduce

• AnonymousPlanet 2y ago
  Go is a very opinionated language from it's inception. We could probably argue for all eternity about code formatting, for instance. But Go went and set it in stone. Maybe it's part of good engineering to keep things simple and not allow hundreds of ways to do something. Maybe the people who use Go are the ones who just want to write and read simple and maintainable code and don't want it to be cluttered with whatever is currently the fashion. You could look at Lisp. It's kind of the opposite of Go in this regard. You can use whatever paradigm you like, generate new code on the fly, use types or leave them. It even allows you to easily extend the language to your taste, all the way down to how code is read. But Lisp might violate your set of absolutes.
  • callc 2y ago
    Thanks for your response AnonymousPlanet. I agree there is value in the pursuit of a minimal set of features in a PL which brings many benefits. And of course the opposite - an overly feature packed and/or extensible PL as a core feature has tradeoffs. Over this range of possibilities my preference probably falls somewhere in the middle. I see an effect where the languages whose primary goal is a particular set language design choices (such as strict memory safety over all else) grow a cult following that enforces said design choices. Maybe in the pursuit of an opinionated language, even if the designers are reasonable at the language's inception, the community throws out logic and "opinionated" becomes a in-group out-group tribal caveman situation.
    • derefr 2y ago
      > Maybe in the pursuit of an opinionated language, even if the designers are reasonable at the language's inception, the community throws out logic and "opinionated" becomes a in-group out-group tribal caveman situation. I think you've got this backward. It's not that the particular choices are important. It's a thing happening on a higher meta level than that. Some programming languages are, by design intent, "living" languages, evolving over time, with features coming and going as the audience for the language changes. "Living" languages are like cities: the population changes over time; and with that change, their needs can shift; and they expect the language to respond with shifts of its own. (For example: modern COBOL is an object-oriented language. It shifted to meet shifting needs of a new generation of programmers!) If you were able to plot the different releases of a living language in an N-dimensional "language-design configuration space", these releases would appear to arbitrarily jump around the space. Other languages, though, are, by their design intent, "crystallized" languages — with each component or feature of the language seeing ever-finer refinement into a state of (what the language maintainers consider) perfection; where any component that has been "perfected" sees no further work done, save for bugfixes. For such languages, creating a language in this way was always the designers' and maintainers' goal — even before they necessarily knew what they were creating. "Crystallized" languages are like paintings: there was an initial top-down rough vision for the language (a sketch); and at some early point, most parts of the design were open for some degree of change, when paint was first being applied to canvas. But as the details were filled in in particular areas, those areas became set, even varnished over. If you plot the successive releases of a crystallized language in design configuration space, the releases would appear to converge upon a specific point in the space. The goal with a crystallized language is to explore the design space to discover some interesting point, and then to tune into that interesting point exactly — to "perfect" the language as an expression of that interesting concept. Every version of the language since the first one has been an attempt to find, and then hit, that point in design space. And once that point in design space is reached, the language is "done": the maintainers can go home, their jobs complete. Once a painting says what it "should" say, you can stop painting it! If a crystallized language is small, it can achieve this state of being entirely "finished", its spec set in stone, no further "core maintainer" work needed. Some small crystallized languages are even finished the moment they start. Lua is a good example. (As are most esolangs — although they're kind of a separate thing, being created purely for the sake of "art", rather than sitting at the intersection of "work of art" and "useful tool" as crystallized languages do.) But large crystallized languages do exist. They seek the same fate as small crystallized languages — to be "finished" and set in stone, the maintainers' job complete. They just rarely get there, because of how large a project it is to refine a language design. You might intuitively associate a "living" language with democratic control, and a "crystallized" language with a Benevolent Dictator For Life (BDFL) figure with an artistic vision for the language. But this is not necessarily true. Python was a "living" language even when it had a BDFL. And Golang is a "crystallized" language despite its post-1.0 evolution being (essentially) directed by committee. --- The friction you're describing, comes from developers who are used to living languages, trying to apply the same thinking about "a language changing to serve the needs of its users" to a crystallized language. Crystallized languages do not exist primarily to serve their users. They exist to be expressions of specific points in design space, quintessences of specific concepts. Those points in design space likely are useful (esolangs excluded); but the expectation is that people who don't find that point in design space useful, should choose a different language (i.e. a different point in design space) that's more suited to their needs, rather than attempting to shift the language's position in design space. Adding a bridge is a sensible proposal for a city. You can get entire streets of buildings torn down to make way for the bridge, if the need is there. But adding a bridge is not not a sensible proposal for a (mostly-finished) painting. If you want "this painting but with a bridge in it", that's a different painting, and you should seek out that painting. Or paint it yourself. Or paint the bridge on some kind of transparent overlay layer, and hang that overlay in front of the painting. Conveniently for this discussion, Borgo here is exactly an example of a language that's "someone else's painting, but now with the bridge I wanted painted on an overlay in front of it." :)
  • littlestymaar 2y ago
    > Go is a very opinionated language from it's inception. True. > We could probably argue for all eternity about code formatting, for instance. But Go went and set it in stone. This is part of the story that Rob Pikes uses to justify how opinionated Go is, but it's a bit stupid given that most language do fine and I've never seen any debates about the code formatting after the very beginning of a project (where it's always settled quickly in the few case where it happens in the first place). The real reason why Go is opinionated is much more mundane: Rob is an old man who think he has seen it all and that the younger folks are children, and as a result he is very opinionated. (remember his argument against syntax coloring because “it's for babies” or something). It's not bad to be opinionated when designing a language, it give some kind of coherence to it (looking at you Java and C++) but it can also get into the way of users sometimes. Fortunately Go isn't just Rob anymore and isn't impervious to changes, and there is finally generics and a package manager in the language!
    • AnonymousPlanet 2y ago
      Seriously, if you feel patronised by how someone designs a programming language, it might be best to move on. It's obviously not for you. Especially when you feel compelled to bad faith assumptions and ageism over it. For those who want to feel the wind of coding freedom blow through their hair, I can recommend to spend some time learning Lisp. It offers the most freedom you can possibly have in a programming language. It might enlighten you in many other ways. It won't be the last language you learn, but it might be the most fruitful experience.
      • SomeoneFromCA 2y ago
        Most of people who tend to brag about Lisp's (Common Lisp) superiority, never actually used it. It is not as impressive as many legends claim.
        • AnonymousPlanet 2y ago
          Can you name a language that provides more freedoms? I used Lisp as an example for that side of the spectrum because I'm familiar with it, having used it for many years in the past. But maybe there are better examples.
  • pjmlp 2y ago
    It baffles me that so many developers are unable to use pre-comit hooks for their code formatting tools, that exist since the 1990's, to the point go fmt became a revelation.
    • leononame 2y ago
      That's hardly the point. The point is that there is a single format for the language itself and you don't have to argue about spaces vs tabs vs when to line break, whether you want trailing commas and where to put your braces. You can format on save or in a pre commit hook. But that the language has a single canonical format makes it kind of new.
      • pjmlp 2y ago
        Yes, because there is no one in the room able to configure the formating tool for the whole SCM. A simple settings file set in stone by the CTO, such a hard task to do. The fact that is even a novelty unaware of, only confirms the target group for the language.
        • utrack 2y ago
          IMHO it's not about the standards in your company, it's more about being able to parse any random library on GitHub etc with your eyeballs.
          • pjmlp 2y ago
            I use compilers and IDEs for that.
        • geodel 2y ago
          > A simple settings file set in stone by the CTO, such a hard task to do. It does seem hard thing to do. Working over dozens of enterprise shops in last 15 years I have not see such setting done or dictated at all. So whole codebase used to be mishmash of person styles.
  • tomjen3 2y ago
    We have completely lost the plot by assuming that just because there are disagreements on somethings then any choice is equally as good as any other. Go is opinionated and it is opinion is wrong. Not having exceptions (but then having them anyway through panic, but whatever) is a choice - but the other reasonable alternative is the Maybe monad. What Go did is not reasonable. I might be okay if they had been working on getting monads in, but they haven't. I have a specific hatred for Go because it seems perfectly suited to make me hate programming: it has some really good ideas like fast compile time speeds, being able to cross-compile on any platform and being a systems language without headers. But then I try to write code in it and so. much. boilerplate.
    • knighthack 2y ago
      > But then I try to write code in it and so. much. boilerplate. If boilerplate is cause for you to dislike the language, fine. But your unnecessarily strong language "Go is opinionated and it's opinion is wrong", "What Go did is not reasonable", "I have a specific hatred for Go" speaks more about you than Go. Go's choice of trade-off much was practical and reasonable, engineering-wise. Your opinion is entirely wrong.
• Mawr 2y ago
  You're reading way too much into what the parent poster said. He just correctly stated the overall sentiment of the community. That said, suggesting adding exceptions to Go is about as reasonable as adding a GC to Zig. How much effort would you spend arguing against someone bringing that up as a serious proposal?
  • randomdata 2y ago
    > That said, suggesting adding exceptions to Go is about as reasonable as adding a GC to Zig. Suggesting the addition of exceptions to Go is as reasonable as suggesting the addition of loops to Rust. Which is to say that it already has exceptions, and always has. Much of the language's design is heavily dependent on the presence of exceptions. Idioms dictate that you probably shouldn't use exceptions for errors (nor should you in any language, to be fair), but even that's not strictly adhered to. encoding/json in the standard library famously propagates errors using the exception handlers.
    • Mawr 2y ago
      Go doesn't use exceptions as a primary way of handling errors, which is what we're talking about here. Pedantry is not welcome.
      • randomdata 2y ago
        It doesn't not use exception handlers as a primary way of handling errors either, though. Go doesn't specify any error handling mechanism. Using exception handlers is just as valid as any other, and even the standard library does it, as noted earlier. The only error-related concept the Go language has is the error type, but it comes with no handling semantics. Which stands to reason as there is nothing special about errors. Originally, Go didn't even have an error type, but it was added as a workaround to deal with the language not supporting cyclic imports. Your pedantry is hilarious and contradictory.
        • Mawr 2y ago
• VS1999 2y ago
  Why would you not enforce a particular belief about how a language should be designed? There are languages designed around being able to do anything you want at any time regardless of if it makes sense, and then you end up with everyone using their own fractured subset of language features that don't even work well together. Not every language needs to be the same feature slop that supports everything poorly and nothing well.
• smt88 2y ago
  You have the same PL preferences as me. I haven't tried Rust yet, but Kotlin, modern C#, and F# all fit your requirements. Kotlin is closest because it uses the enormous Java ecosystem.
  • bbkane 2y ago
    I haven't had time to really try to write anything in it, but https://gleam.run/ https://gleam.run/ looks really good too. Like Elm for backend + frontend!
    • airstrike 2y ago
      "+ frontend" only if you squint really hard, I think
    • fire_lake 2y ago
      F# is Elm for front end and backend
• rendaw 2y ago
  Aside from "not ancient" Java has everything you want! I'd consider the best tooling (Intellij), static, strongly typed, has enums now (sealed interfaces), composeable error handling, null safety with new module flags, etc. Not sure about the community, but the maintainers I've worked with seemed nice enough. I imagine the community has a lot less ego than rust/go due to the general perception of the language.
  • 4star3star 2y ago
    What does Java offer that dotnet does not?
    • mdaniel 2y ago
      libraries, and I thank God I don't have to work on Windows and thus don't know how smart Visual Studio Enterprise is, but IJ is world class in the number of bugs it'll catch
      • paddim8 2y ago
        What? You don't have to work on Windows with .net either and there is an IntelliJ IDE for C#.
        • mdaniel 2y ago
          Apologies, I meant to draw the Windows distinction due to VS Enterprise, since I doubt very seriously VSE runs elsewhere (I'm aware of 2022 for Mac but it doesn't cite its "feature level"). Since I'm not a .NET-er, nor a VS-er, I can't say how smart their top-tier IDE is with their in-house language in order to have an apples-to-apples bake-off
  • tomjen3 2y ago
    I would argue that .NET is better than Java, unless Java has gotten something like Linq since last I used it (which is entirely) possible. For those who do not know: .NET is cross platform, MS has official documentation on how to deploy it in Docker, and it is MIT licensed. And if you want to deploy a backend for your webapp the tersenes can now rival Flask - plus the compiler can cross compile it to any supported platform, even in a form that works without .NET installed. And of course it has Jetbrains support through Rider.
• deleted 2y ago
  [deleted]
• valenterry 2y ago
  I'd say Scala. It has its flaws, but the latest version (Scala 3) is really really good. The community is open to different styles of programming - from using it as a "better Java" to "pure functional programming like in Haskell".
  • anthonyskipper 2y ago
    Scala is the perfect example of why you want to limit expressivity. It's seems so cool and awesome at first, but then you have to support a code base with other engineers and you quickly come to the view that go's limited expressivity is a blessing. Hilariously I was using a gen AI (phind) and asked it to generate some scala code and it no joke suggested the code in both implematic scala and in java style, and all you had to do is look at it and you could see java style was 1000X easier to read/maintain.
    • valenterry 2y ago
      Well, flexibility has its price. And yeah, if you need to work in a team that uses a very different style, then you won't like it. On the other hand, if you carefully select your team or work alone, then this is not a problem at all. Btw, there isn't really "one" idiomatic scala style - therefore I tend to believe that you are not familiar with the language and the community.
      • Capricorn2481 2y ago
        > Btw, there isn't really "one" idiomatic scala style That is their point. There's too many styles.
        • valenterry 2y ago
          What "point" is that though? That's like saying "there is too many programming languages".
          • Capricorn2481 2y ago
• adamlett 2y ago
  I read somewhere something to the effect of this: Some languages solve deficiencies in the language by adding more features to the language. This approach is so common, it could be considered the norm. These are languages like C++, Swift, Rust, Java, C#, Objective C, etc. But two mainstream languages take different approach: C and Go strongly prefer to solve deficiencies in the language simply by adding more C and Go code. One of the effects of this preference is that old (or even ancient in the case of C) codebases tend to look not that different from new codebases, which as one might imagine can be quite beneficial in certain cases. There is a reasonable argument to be made that at least some of the enduring success of C has to do with this approach.
• icholy 2y ago
  Suggesting try/catch indicates that you have virtually no experience using Go. You're standing on the side lines yelling stupid/non-sensical feature requests and getting upset when you're not taken seriously.
  • usrnm 2y ago
    Adding exceptions to golang doesn't make any sense for a very simple reason: they're already there. The fact that they're called differently doesn't change anything, panics walk like exceptions, swim like exceptions and they quack like exceptions.
• kazinator 2y ago
  > ostracize the non-believers It is rather the non-believers in exception handling who are the lunatic fringe that benefits from a healthy dose of ostracism.