1. 4

    Wow. This article is spot on on the need to expose new features of the languages to those whose knowledge about it is outdated.

    I stopped touching PHP more than 15 years ago, maybe 20, and… boy did it change!

    1. 4

      I use the ones I made :p

      • broot for exploring files, navigating, searching content, etc.
      • lfs which more or less adds du and df plus parts of blk and some disk tagging
      • rhit to query nginx logs

      and some I didn’t made

      • scmbreeze which has interesting shortcuts for git
      • neovim, if it counts
      1. 2

        I like the idea of broot, but it glitched out between the UI and rm and I wound up blowing away a lot of files by accident.

        1. 2

          I never got any such report. Would it be possible to have more details (in a GH issue or in the chat if needed) ?

          1. 1

            Chat probably works, its hard to reproduce (and I dont want to :))

            I was using the previous sort by size magics (which seems to now be --sort-by-size), finding dirs and then asking broot to delete.

            That calls rm under the hood which at the time freaked broot out (it tried to refresh and put me in the top level), because of lag I would end up hitting the key combination again and then … toasting the parent (very large dir)

            I might give it another spin and see if it lags out on me again

      1. 2

        It always upsets me that 1 isn’t prime.

        1. 7

          It’s just a convention. It would make a bunch of theorems annoying to state if 1 were prime.

          1. 3

            “1 is a prime” can be the new “tau is superior to pi”.

            On a more serious note, I read a bit about this and apparently for a long time 1 wasn’t even considered a number: https://blogs.scientificamerican.com/roots-of-unity/why-isnt-1-a-prime-number/

            1. 2

              The current ad-hoc definition of a prime is of a natural number with exactly two distinct positive natural divisors. It appeared to be convenient so it was normalized this way about one century ago (but you can still find very old books citing 1 as the first prime number).

              1. 2

                2 being prime is pretty disappointing as well.

                1. 1

                  1 is only divisible by 1 and itself, but then considering it as prime will destroy “sieve of eratosthenes”

                  1. 2

                    This might be misleading: The cd you normally use is still the shell command, not the cd program.

                    1. 1

                      It’s not more misleading than the title of the article TBH.

                      1. 3

                        Why ? The cd you use everyday isn’t a program, and it does matter.

                        1. 3

                          Exactly, but the title implies that there is no cd program, which is untrue. “cd is probably not a program” or “cd is not only a program” is more accurate and less misleading imo.

                    2. 1

                      How new is this? When I left the DOS world decades ago now I remember having to learn chdir instead of cd and adding an alias for cd. No idea what platform that was, could have been a linux or sunos or Digital Unix. Is my memory faulty or was cd really added later?

                      1. 1

                        Until Unix V7 chdir was used indeed.

                    1. 1

                      “So why does it make a difference whether cd is a builtin or a standalone executable? Let me give three examples.”

                      To those 3 examples, I’d like to add a fourth one: it’s harder for other processes launched from the shell to do a cd for the user. Broot, for example, must be launched by a special script or command to change the current directory of the user ( https://dystroy.org/broot/install-br/ ). This isn’t always obvious for users who wonder why broot wants to install a shell function.

                      1. 14

                        It’s also not universally true that the current working directory is a kernel-level abstraction on POSIX systems. It’s entirely possible to implement it in userspace and either do the path expansion for relative paths in userspace or (on more modern systems) use openat and friends with the file descriptor of the current working directory.

                        Linux shells are often in an exciting half-way state to this because the working directory in userspace and the kernel may not match. When you cd to a symlink, the kernel’s idea of the current working directory is the target of the link, but the userspace view is the source. When you cd .., bash (at least, probably other shells) uses the userspace view to go back to the path that you expected. You can see this mismatch in this simple example:

                        $ cd /tmp/
                        $ mkdir foo
                        $ ln -s foo bar
                        $ cd bar
                        $ stat /proc/self/cwd # Look at the kernel's view of current working directory
                          File: /proc/self/cwd -> /tmp/foo
                          ...
                        $ pwd # Look at the userspace view of the current working directory
                        /tmp/bar
                        $ echo $PWD # Look at the userspace view of the current working directory another way
                        /tmp/bar
                        

                        If I were designing a POSIX system from scratch, I’d make the current working directory a purely userspace abstraction. There’s no need for the kernel to know about it (especially not now that openat exists) and if there’s only one copy of it then it can’t get out of sync with itself.

                      1. 2

                        I’ve made UFO in a chat.

                        When somebody types one of the dozen special words, like “plane” or “carrot” or “coffee”, with a few added conditions and if it hasn’t been typed chat-wide in the last few hours, then a high quality svg of the thing flies through the screen of all users in the room at the time.

                        1. 2

                          Lego and snow with the kids. I spent too much time on evenings this week making my nginx log analyzer.

                          1. 3

                            hjson is buggy, the standard has a “bug” that results in an ambiguity in its representation of certain items (at least when converted from json). I could have sworn I filed a bug on github a few years back when I wrote an automated toml <–> hjson converter in rust (via serde), but I cannot find it now.

                            1. 2

                              I noticed ambiguities too. I’ve handled them by 1) not allowing free form parsing but only type guided deserialization into Rust types (my crate is named “deser_hjson” and I won’t write a serializer), 2) not allowing quoteless strings in some positions (that’s why I says Hjson is line oriented even if it doesn’t say it). I don’t think Hjson converters are safe, I wouldn’t go that way in Rust even if I used Hjson -> JSON converters in the past in JavaScript and Java.

                            1. 9

                              I personally enjoy using libucl for config files, and find HCL “ok”.
                              hjson looks pretty interesting though! Going to take a deeper look at it.

                              1. 4

                                UCL looks very interesting, if there’s no trap or ambiguity. The first thing I notice is that you seem to be able to omit the ugly braces around the whole document.

                                I might consider creating a Rust deserializer for it… I’ll have to look more at the language.

                                I guess my blog post will have to be renamed into “Why broot switched from TOML to Hjson then UCL for its configuration files”…

                                1. 2

                                  FreeBSD has adopted ucl from its core OS configuration files. The interesting thing is that it’s a silently supported format for a lot of files that still use either the old conf format or a subset of ucl that resembles the old conf format. For example, the pkg.conf files can be written in one of two different configuration languages and the default is not ucl, but a completely different ucl syntax is available and automatically detected/supported.

                                1. 5

                                  If there is one thing I wish configuration languages would adopt, its to drop commas all together. Clojure’s EDN format does this and its great. Whitespace is a natural separator for lists.

                                  1. 3

                                    i have a config language that i wrote that does that. it converts to json, so for a while i was writing configs with this as a json preprocessor; the moon command converts moon files to json with moon to json; programs would just use the json file. i haven’t used it much recently because it drives other people nuts when you say “hey let’s use this config format that i invented that nobody else has ever seen”. https://github.com/jordanorelli/moon

                                    1. 1

                                      A project with 30 stars isn’t really unknown. It looks like a good configuration language at first glance.

                                      It would be interesting to have a precise comparison of the differences with what looks like the nearest one: Hjson.

                                    2. 2

                                      Hjson lets you totally drop commas if you want. There’s none in my example.

                                    1. 6

                                      Correct me if I’m wrong, but it seems hjson suffers from some of the same bugs that yaml has around type ambiguity. Primarily, in formats where unquoted strings are allowed a human may write 1000 in a field which is supposed to be a string, and they’ll get a number.

                                      1. 9

                                        The main problem with YAML used as a configuration format written by human isn’t that true isn’t interpreted as a string, because you expect it. The real problem in my opinion is those weird rules which makes for example off be interpreted as a boolean. It’s so random most people don’t know it (see the “Norway problem” ( https://hitchdev.com/strictyaml/why/implicit-typing-removed/ ) too). Hjson doesn’t have the same level of insanity (true is only true, not On nor YES or yes).

                                        So I think this problem, for Hjson, isn’t really a problem. Or a small one.

                                        Now, I said, perhaps in a cryptic way, that even the weird rules of YAML “may matter or not”. Because there’s absolutely no problem here if you use Hjson (or YAML) the way I do.

                                        The reason is that the best way to deserialize a configuration, in my opinion, isn’t to use the automatically guessed type but to deserialize into the type required by the strongly typed structure.

                                        And that’s the only public API I’ve put in my deserializer: you can’t use my Hjson deserializer ( https://github.com/Canop/deser-hjson) to read a free form file, you can only use it to deserialize into a Rust type, precisely to avoid the dangers related to type ambiguity. If the human typed 1000 in a field which is expected in Rust to be a string, it will be read as a string.

                                        1. 3

                                          Agreed; deserializing into typed data structures really does make most of the issues with YAML go away in my experience. The other thing that helps when I’m writing YAML to configure code I didn’t write is to always wrap string values in quotes. Yes, it adds a little noise, but it is a pretty easy habit to pick up and then all the “what type is this value, anyway?” problems with YAML become irrelevant. The added noise of quoted strings isn’t too bothersome to me, though that’s obviously subjective.

                                          1. 2

                                            Ah, yes, forcing deserialization to a datatype is a good way to deal with this, vs having some general HJson type and making an arbitrary decision about the types of fields. That said, I still find syntactic ambiguities like this one to be a major downside of these human readable formats.

                                        1. 4

                                          What the user wanted here, when adding the last prop, was to set a top level property.

                                          But what really happens is that the property is added to the second item of the "chars" array.

                                          I have a hard time believing that anyone who has ever written or modified an INI file would be confused about this. Considering that this is the only illustrated criticism of TOML in this entire post, I’m puzzled as to why this person switched away from TOML.

                                          Now, I understand what they mean when they call the language alien and confusing. But so are YAML, XML, etc. when you first encounter them, it’s just that people are accustomed to these decades old languages. Is it possible to create a configuration language that is intuitive to inexperienced newcomers and covers all the use-cases of TOML? Time will tell.

                                          1. 5

                                            The problem isn’t with the software author. Being the author of broot, I wouldn’t have to change the format if I was the sole user. The problem is when people stop trying to configure your software because the changes they do have no effect.

                                            Adding a line to a configuration file is something that linux users do all the time.

                                            People who’ve been told that to achieve an effect they would have to add this line in their config.toml file won’t read the whole file to scan whether there’s a better location, they’re used to add it at the end as they do for example in their .bashrc file. Of course, coming back later they would probably try to organize everything but they won’t because their first reaction is that there’s a bug in the application since the added line did nothing.

                                            I don’t pretend that TOML is bad for everything but that such confusion makes it unsuitable for many programs as it has proven to be for broot.

                                            1. 4

                                              I see. I wish you went into more detail about this in the blog post because it’s a good point.

                                              I think the solution here is not to use the global scope at all in an INI/TOML file, such that it’s always clear what section an attribute belongs to. In addition, your application could throw warnings or even errors if unknown keys are detected (careful with backwards compatibility, though), or it could print the configuration back to the user so that they can check if everything is configured properly. It could also offer a dry run of configuration parsing.

                                              Interestingly, I noticed that many Linux utilities have this configuration problem, and many just “swallow” any nonsensical configuration and exhibit default behaviour, something that has often cost me a lot of time. It’s even worse if they use their own configuration language that is often fraught with parser ambiguities and problems. It’s good to see developers like you caring about how users interact with the configuration file.

                                              1. 2

                                                Thanks, I’m editing my blog post to take this into account, and try to make it clearer.

                                                1. 1

                                                  I think the solution here is not to use the global scope at all in an INI/TOML file

                                                  That seems the obvious solution to me as well, if this single confusion that users have is the only issue with the format. Generally speaking, I also think this is better than this proliferation of almost-but-not-quite JSON formats, each with their own “conveniences” added that might cause more confusion. Especially the unquoted string values and possibly the implicit comma on newline seem like footguns in disguise.

                                                  Comments, optional trailing commas and unquoted string keys seem like much more obvious advantages to me. Especially considering unquoted keys don’t have the ambiguity of “should the key be evaluated?” (which JS actually never does, but for example Python does) and “is this key a reserved JavaScript keyword?” like in JavaScript. But then, if you drop that it’s technically not eval() able anymore in a JS interpreter, which was arguably JSON’s biggest “advantage” (with all the security problems that entailed).

                                            1. 5

                                              It’s fascinating to me that there’s so much diversity in config formats. Maybe it’s just that everyone needs one and they’re easy to quibble with.

                                              That said, I like that HJSON explicitly aims “to be used like a user interface for humans, to read and edit before passing the JSON data to the machine.” This seems similar to Strict YAML, which also focuses on giving humans a low-surprise way to define data structures that computers will eventually treat like JSON.

                                              I would consider using HJSON over Strict YAML next time I need a config.

                                              1. 4

                                                I don’t think there so much diversity. There’s less than a dozen common configuration formats, none of them really good (writing a deserializer for Hjson made me more aware of its shortcomings, especially for the quoteless strings and its indecisiveness regarding whether it’s a line oriented format or not).

                                                I didn’t know about Strict YAML. It’s interesting and I’ll probably amend the document to mention it.

                                                1. 4

                                                  I personally would also be interested in comparision between various human readable JSONs. There are at least:

                                                  1. 2

                                                    In my opinion, Json5, which I do use, is a better JSON, but while it’s suited for data exchange it’s behind Hjson for configuration (which wasn’t probably the main goal). It especially still asks for commas and doesn’t solve the indentation problem for multiline strings.

                                                    Rome-json (which I didn’t know) seems to be an intermediate between JSON and Hjson.

                                                    edit: I’ll edit my blog post to link to those alternatives

                                                2. 1

                                                  I don’t think it’s that many, when being compared to programming languages, image formats, etc. I also wouldn’t call all of these config format, in the sense that they were made to be mostly written by humans. JSON (and to a degree YAML) is a human readable data serialization format, and in many situations is generated vs. hand written. UCL/HCL and TOML are way more frequently touched manually.

                                                  Of course that doesn’t mean you cannot/should under no circumstances use other formats. I think they are tools to choose from and while I would agree there is a lot of “someone trying their own thing” projects, the same is again true for programming languages and many other formats.

                                                  It’s also a good thing that people experiment. In the majority projects you will still end up with a hand full of variation. So I think it’s more that people are interested in this topic and there is a lot of talk about it.

                                                1. 4

                                                  You make a really good case about why Hugo is failing it’s users here, but I’m concerned that you may one day be saying the same about Zola. One thing that comes to mind is missing features. For example, you might decide that you want to be able to add footnotes, but CommonMark doesn’t have that functionality. Because Zola has no extensibility, you’re SOL as far as I can tell. I also have a suspicion that people might start to use themes as a way to emulate plugins. Something like the difficulty of adding graph tags that you talked about could maybe be solved like that. But then it’s getting into the danger zone of finding documentation in multiple places and having to magically override things again. I think that KayodeLycaon was spot on in pointing out that everyone wants something slightly different. I hope Zola works out for you :)

                                                  1. 3

                                                    Yep, the concerns are valid. I don’t have a really good reply to that, but I hope this works out. Ultimately if this required another refactor then I’ll bite the bullet to make my own SSG. Not thinking too much about that situation now, though :)

                                                    1. 3

                                                      I also have a suspicion that people might start to use themes as a way to emulate plugins.

                                                      You said something I had trouble articulating for a long time. The problem with a Turing-complete template processor as a sole extensibility mechanism is that presentation and logic are no longer orthogonal.

                                                      That is why I chose not to use either Zola or Hugo for a refresh of my own site setup, but went for writing an SSG that is statically linked but extensible with Lua plugins via an embedded interpreter. </shamelessPlug> ;)

                                                      Nothing against Zola or its users though, it’s a good project.

                                                      1. 2

                                                        Just as a small note, Zola totally does footnotes. I think there might be a page that lists which extensions pulldown-cmark enables out of the box. But your main point stands with or without this example :)

                                                        1. 1

                                                          As a Zola user who used several other solutions before, I’m 100% sure I’ll get tired of it. I already had to hack around limitations (or my lack of knowledge) while my blog is super simple. But it’s all about gaining some time.

                                                          I know that at some point I’ll have to do the switch to either another existing system or to one I’ll make. But I don’t spend time on that now and having a blog whose content is only in markdown and related images will make it easy if I decide to keep the content.

                                                          Zola is temporary but it’s easy to set up, and should be easy enough to replace when time has come.

                                                        1. 2

                                                          Apart the tools I built myself, I quite like the set of commands of scm_breeze which shortens a lot of git commands and give aliases like $e1 to the files listed in git status.

                                                          1. 2

                                                            I love scm_breeze, but I have to go pretty far out of my way to get it to respect the XDG_BASE_DIR spec and to disable a bunch of it’s non-git wrappers. I mainly use this replacement entrypoint script: https://github.com/sethwoodworth/devenv-setup/blob/master/patches/scm_breeze.sh

                                                          1. 35

                                                            There’s really a problem with this blog post. I don’t know how it’s technically done but having to wait several seconds every time you display the tab is why almost nobody will read it.

                                                            1. 20

                                                              It is actually super-high-level web development. Kudos to @tedu for pulling it off.

                                                              Pages are progressively enhanced using JavaScript if it is available. If it isn’t, users can still read the page. If JS is available, then UX is enhanced with a realtime loading indicator, much like the ten-pixel-bars top bars that are on many pages.

                                                              After all, in this Third Age of JavaScript, we cannot simply trust the browser to render the page. We need to tell the user the progress of that.

                                                              1. 14
                                                                var delay = 100
                                                                switch (progress) {
                                                                	case 70:
                                                                	case 73:
                                                                	case 76:
                                                                		delay = 250
                                                                		progress += 3
                                                                		break
                                                                	case 79:
                                                                		delay = 500
                                                                		progress += 2
                                                                		break
                                                                	case 81:
                                                                		progress += 14
                                                                		break
                                                                	default:
                                                                		progress += 5
                                                                		break
                                                                }
                                                                

                                                                I have to give props for verisimilitude. And for teaching me where to find uBlock Origin’s “disable javascript on this page” function.

                                                                1. 10

                                                                  I wouldn’t be surprised if @tedu spent a good twenty minutes fine tuning that for maximum annoyingness.

                                                                  1. 2

                                                                    You have more patience than me. It taught me where to find uBlock Origin’s domain-level blocklist.

                                                                  2. 9

                                                                    I’m sorta ok with progressive enhancement. What ground my gears was that it triggered every time the window (Chrome on Windows) regained focus. It made it really hard to find my place again in a page with lots of code.

                                                                    1. 19

                                                                      I mean, just so we’re all clear, it’s something between a joke and a protest statement, and what you’re complaining about is entirely the deliberate point: it’s a perfectly fine, instantly rendering webpage that’s being “progressively dehanced” by the presence of annoying JS.

                                                                      1. 4

                                                                        Wow… kids these days 😒

                                                                    2. 5

                                                                      Yeah, I love it. This “protest” is a nice compromise in comparison to sth like “Disable JS to enter the page”. It is annoying but still usable.

                                                                    3. 12

                                                                      The site loads almost instantaneously. Just disable JavaScript ;-)

                                                                      1. 11

                                                                        What’s really weird is all the markup appears to be there, and the loading is just for…giggles?

                                                                        1. 22

                                                                          That sounds like something @tedu would do.

                                                                        2. 2

                                                                          Well, @tedu also had a period with a self-signed certificate, the horror!

                                                                          1. 2

                                                                            When you have a self-signed certificate, you are expected to trust it on first use, and then the web browser remember it.

                                                                            If the web browser remember the certificate of a website, noone, including a MitM possessing the key of a certificate trusted by your web browser, noone can tamper the connection anymore.

                                                                            So you suddenly jump from a situation that looks suspicious security-wise, to one that can face the NSA kind of attack vector.

                                                                            Of course, in the case of a MitM situation, your “accepted security exception” situation (self signed but trusted manually) would turn into a “green padlock” (certificate signed by the MitM) situation, and I doubt many will choose the “padlock with yellow cross” over the “padlock with green check mark”, even if icons barely have any accurate meaning on their own…

                                                                            Simply wandering on an off-topic… Not actually meaning that Cloudflare should switch to self-signed right now… Oh, wait, Cloudflare are self-signing, they are their own trusted certificate authority…

                                                                          2. 2

                                                                            Just use links? ;)

                                                                          1. 4

                                                                            Canonical is taking risks by forcing snap onto his users. Two weeks ago, when an automatic chromium upgrade told me that chromium would switch to snap on my computer, didn’t let me the choice to refuse the new installation, and basically broke apt until I accept, I decided to change distribution. The reason I’m not on Ubuntu anymore and probably won’t be back is only this one: I don’t want to have such change forced on me. This isn’t the linux way.

                                                                            1. 5

                                                                              There are browsers for which !("a" == "a"[0]) evaluates to true ? How ? Which ones ?

                                                                              1. 13

                                                                                To answer how:

                                                                                Accessing characters like "a"[0] was only added in ES5, originally you had to use "a".charAt(0).

                                                                                If a browser does not support this way of accessing characters "a"[0] will be interpreted as trying to access a property with the name ‘0’ which does not exist on a string so it will evaluate to undefined.

                                                                                To answer which ones:

                                                                                Mostly older browsers that do not fully support ES5, I think IE took a really long time to support it.

                                                                                1. 2

                                                                                  Thanks, I didn’t remember about the bracket access being added in ES5.

                                                                              1. 42

                                                                                Why are these kinds of articles almost always predicated on the authors being completely unaware of Option/Result types?

                                                                                It’s the old “beating down the exception strawman” – that no one is even interested in defending.

                                                                                (I wonder what happens to all these similar articles when Go gets generics and people start using Option/Result types?)

                                                                                1. 16

                                                                                  The author does give lip service to Option/Result types:

                                                                                  EDIT: Exceptions are definitely not the only way other languages deal with errors. Rust, for example, has a good compromise of using option types and pattern matching to find error conditions, leveraging some nice syntactic sugar to achieve similar results.

                                                                                  But in a way that suggests they’re something he’s heard of, rather than personally used. If you’re already used to working with ADTs that contain errors, I can’t imagine finding Go’s system of basically mandatory 2-tuple return types for all error-prone functions to be ergonomic.

                                                                                  1. 12

                                                                                    Agreed. Plus all the fun in figuring out whether you actually need to handle the value and error case, because the signature doesn’t tell.

                                                                                  2. 8

                                                                                    As someone who was an adamant gopher for like 7 years. Rust’s Option and Result types changed the way I see programming, especially once I fully grokked that Result is basically a monad.

                                                                                    1. 4

                                                                                      Same, although I had that realization when encountering the equivalents of those types in Haskell, rather than Rust. A lot of what I like about Rust is that it’s a mainstream language (more mainstream than Haskell in any case) that lets you easily define and use ADTs.

                                                                                    2. 12

                                                                                      It’s the old “beating down the exception strawman” – that no one is even interested in defending.

                                                                                      I dunno, having used Go as my main development language for eight years now, I encounter people defending exceptions far, far more often than people advocating for option types.

                                                                                      1. 5

                                                                                        Isn’t it that, at this point in time, most people familiar with option types for errors are developing in Rust and not really in the Go world anymore ?

                                                                                        Somebody coming from a language with exceptions to Go might say he prefers his old way. And there probably aren’t, today, many people coming from Rust to Go.

                                                                                        1. 7

                                                                                          sure, I think there aren’t many people coming from Rust to Go, that’s … kinda my point? soc is mad that the article is not written specifically for him, and is instead written for an audience that is more representative of who the author is actually encountering. The idea that exceptions are a straw-man nobody is defending is … honestly a little ridiculous. People defend exceptions all the time. The majority of programmers work in JS, Python, Java, C#, and PHP, all of which have error-handling semantics built around exceptions. A lot of those programmers really do make arguments defending exceptions. Few of them read lobste.rs for recreation. And you know, the few that DO read lobste.rs for recreation need articles like this to learn about things they haven’t encountered yet.

                                                                                          I also find it so hilarious that someone flagged my prior comment as “incorrect”. I described my lived experience and someone flagged it as “incorrect”. lol

                                                                                          In reality, most people just code because it’s a job. This article is not written for people looking to find self-actualization in a type system.

                                                                                          1. 3

                                                                                            I also find it so hilarious that someone flagged my prior comment as “incorrect”. I described my lived experience and someone flagged it as “incorrect”. lol

                                                                                            Looks like all my comments on this thread have received at least one flag.

                                                                                            I don’t know what it is about Go that induces such rage in some people, it’s completely fine (even reasonable!) to not like Go, but Go threads have a tendency to turn in to dumpster fires in a way that I don’t see in other languages (including PHP and JavaScript).

                                                                                            1. 1

                                                                                              I don’t know what it is about Go that induces such rage in some people

                                                                                              classism.

                                                                                      2. 6

                                                                                        It’s the old “beating down the exception strawman” – that no one is even interested in defending.

                                                                                        It’s not a straw man when a large percentage of competing languages actually do use exceptions. There are very few mainstream languages that use Option/Result types. Actually, I think Swift might be the only one? And maybe Rust, but I’d argue that’s probably not a mainstream language, not yet anyway.

                                                                                        1. 9

                                                                                          Isn’t it a problem in Go culture that it is content in comparing itself with mainstream languages from an earlier century instead of actively investigating what can be done in contemporary non-mainstream languages?

                                                                                          This attitude often leads to solving the wrong problem.

                                                                                          1. 3

                                                                                            That sounds about right. Go is not designed to break any new ground in computer science or language design, but rather to implement concepts that have been proven to work in various languages and are well understood. I think there is value in this: it gives a stable, reliable, and boring language, which may not be optimal in all respects, but it doesn’t have a lot of “sharp edges” and idiomatic Go code from 10 years ago is quite similar to Go code today. Especially if you want to write an application intended to be maintained for a long period of time (>10 years) then the Go approach can give you some good advantages, I think.

                                                                                            I think there’s a lot of value in the more experimental approach in e.g. Rust too, by the way. Not all languages need to be the same.

                                                                                            Either way, I personally wouldn’t call this a “problem”, just a design ethic.

                                                                                            1. 6

                                                                                              That sounds about right. Go is not designed to break any new ground in computer science or language design, but rather to implement concepts that have been proven to work in various languages and are well understood.

                                                                                              Haskell and OCaml have both been around since the 90s, and those are just the two most obvious examples I could come up with of languages that have been used a fair amount in production and which also provide ADTs. So I’m not sure how your assertion makes sense.

                                                                                              1. 9

                                                                                                Seconded. The “experimental” part of Rust is the borrow checker, the rest (a bit of type inference, sum types/enums, match) is extremely well known and robust stuff that has been around for > 40 years. Go ignores a lot of well known things, not just new ground.

                                                                                                1. 2

                                                                                                  And both are also functional programming languages that most people struggle with and see quite little real-world use in the industry.

                                                                                                  1. 2

                                                                                                    Both languages are used extensively in production and have been for a long time, regardless of how their usage compares to C or Java or what-have-you. And ADTs are quite well understood at this point, and Maybe/Option types specifically even moreso; we’re not talking about these languages’ learning curves here. Maybe/Option has been introduced (badly) into Java, for example, and is present in Kotlin, Scala, Rust, etc. So I don’t see how your comment here contradicts my original point.

                                                                                                    1. 2

                                                                                                      We could argue at length on what is and isn’t “well understood” and “widely used”; but it’s not a binary thing, it’s a scale. And it’s also not completely objective either and there is quite some subjectivity involved.

                                                                                                      Go has a very conservative take, which certainly isn’t perfect and you do miss out on some things, but as mentioned I think there is value in this approach too. YMMV.

                                                                                            2. 0

                                                                                              I don’t really feel like defending the 90ies poor error handling approach against a language from the 60ies. ¯\_(ツ)_/¯

                                                                                              The people who care have moved on from such inferior approaches, and those who are still stuck in the last century can’t be helped anyway.

                                                                                          1. 2

                                                                                            The article mentions a few old alternatives but not the more recent Zola which is very similar to Hugo but might have a more approachable templating language.