1. 79
  1.  

  2. 22

    I think part of Go’s success is that it answered a lot of these questions very early on in the language’s life. The standard library, blog, go get, docs, and testing were better fleshed out within a few years of it’s being released than many languages have after a decade. We can argue all day about how good they were, what should change and how all of that came into existence, but it did exist very earlier in the life of the language.

    1. 20

      So I am in kind of a similar situation, just in regards to Python. With all the virtualenv and pip stuff, I usually give up. This is especially annoying when I want to contribute to a larger Python project, but it assumes this or that workflow. A site or a wiki that collects this frequently assumed answers would be really nice.

      1. 7

        +1. It seems like the preferred method for packaging software in Python changes monthly – and, of course, each open source project has their own way of doing things. Pipenv? Poetry? Good ’ol requirements.txt? Very frustrating.

        1. 5

          This, not just in python, is probably one of the reasons that LSP is gaining popularity. Not that I am a fan of it, but I understand that one big chunk of black-box code handling whatever environment one lands is in attractive.

        2. 2

          I feel like Python is high-DIY culture. There’s one way to do things but low conventions. Pretty weird. Add in a mix of domains (now with machine learning and data science), the background and needs of authors is changing. I’ve tried to bring in a minimum of quality-of-life tooling from Ruby/Go/Elixir times and found only a few laterals. Poetry for dependencies. ipdb for a REPL. Pytest for tests. asdf for switching language versions. These have worked for me but they aren’t universal answers (and they needed bespoke config and hackery to me). Every project is different. This is the problem with an older language like python who had to add in some modern tooling after the popularity explosion.

          1. 1

            Have you tried in Python 3? It’s got virtualenv baked in, and many projects already have their packaging decisions made.

            That said, no doubt packaging is Python’s achilles heel.

            However I’ve yet to encounter any sufficiently rich ecosystem that doesn’t have packaging foibles. I seem to recall Perl having a fair number of hoops to jump through to get something into CPAN, and ditto for Ruby and gems.

          2. 17

            I tried playing around with elm last week; but immediately ran in to the problem that the CLI emits colours which are hard to read on my light background. I spent some time find a way to disable them, couldn’t find it, and spent some time reading the source code to confirm there is no way to disable it. Over an hour spent, 0 lines of elm code written.

            “Screw this, I’m going back to Python regular JavaScript”

            I find the value of learning more programming languages is hugely diminished after you’ve learned a bunch anyway. These days I’d rather be building stuff than mucking about with new languages.

            1. 8

              I think there are three possible cases:

              • the tooling suits you so well that you don’t need to fight it
              • the language solves your problems so well that even making missing tools from scratch is worthwhile
              • it’s not worth the time.
              1. 6

                Even something like elm make | cat doesn’t disable coloured output?

                1. 3

                  Yeah, it does; just annoying to type all the time. I’ll make an alias/function if I decide to continue looking at it.

                  1. 1

                    I was thinking export TERM=dumb should have the same effect without having to repeat it every time, hopefully.

                    1. 2

                      Sadly, many apps just assume that if stdout is a tty, it must be vt220-compatible tty, without bothering to look up $TERM in the terminfo database. This is more common in code that’s written in a language where C FFI is difficult (because no terminfo bindings), and apps that are intended to be cross-platform (because Windows doesn’t provide terminfo).

                  2. 3

                    Side note: Some CLIs support the NO_COLOR environment variable to disable coloured output. Judging by your investigation I’d say elm isn’t one of them but it’s worth knowing about for other programs. There’s a small list available to view at https://no-color.org/

                    1. 8

                      Design note: beware NO_FOO flags. What if you want to add a third option later? COLOR={light,dark,none} would have captured more nuance, as would COLOR={vivid,restrained,none}. If NO_COLOR takes off, you have an awkward backwards-compat problem.

                      Alternatively, you can convince people to special-case their code based on your username.

                      1. 1

                        The same thing was discussed when no-color.org was posted here, but I just see that as a greater hurdle for adoption. Most terminal applications don’t have any distinctions between light or dark modes anyway, requiring them to implement it for an environmental variable that still doesn’t have widespread use, just kills it in the cradle.

                        1. 1

                          You can future-proof the design with COLOR=yes|no default yes if unset, and version the spec.

                  3. 9

                    The part about the “missing stair” and the abuser are so true.
                    Not that many people are willing to recognise that a developer community is not only people gathering together around some technical stuff, and people stuff happen too.

                    1. 10

                      These are perhaps some of the most important questions a “language” should have an answer to, but beware: as soon as a language has an opinion that turns out to be wrong, you’re still going to be stuck with it. It’s perhaps for this reason that most languages don’t have an opinion about these things, and leaves you, if sufficiently motivated, to try them yourself so at least if you fail it is your failing instead of the languages’ failing.

                      Personally, I think that’s a cowards move.

                      1. 4

                        as soon as a language has an opinion that turns out to be wrong

                        • has an opinion you disagree with.

                        I don’t think you can say that people are wrong on this as there’s probably no right answers but a nuance of it, and you might disagree with the whole spectrum.

                        1. 11

                          I think there are plenty of things that can be described as flat-out wrong in languages.

                          “All sides are equal” may make sense on US television, but not much elsewhere.

                          1. 1

                            Python used to think 1/2 was 0, but now they think it is 0.5

                            If you can live in the world where both are right, then congratulations, now you have two languages, but I believe most people live in the world where Python decided one was better than the other and simply changed its mind because this isn’t by a long ways the only example of Python changing their mind over the years.

                            1. 2

                              most languages don’t have an opinion about these things, and leaves you, if sufficiently motivated, to try them yourself so at least if you fail it is your failing instead of the languages’ failing. Personally, I think that’s a cowards move.

                              Python decided one was better than the other and simply changed its mind

                              Most languages support both integer division and fractional/floating point division. Fractional is probably the more common choice for /, but arguably the most important thing is that your users know which it is. If it changes, that makes it harder for people to know, especially if there’s no type system to catch such issues (For example, if a language like haskell decided to swap / and div, things wouldn’t silently break).

                              This would appear to be an example of being too opinionated actually causing problems.

                              Perhaps the original author finds it hard to learn new languages because they’re already worn out from constantly learning new versions of python…

                              1. 1

                                This would appear to be an example of being too opinionated actually causing problems.

                                No. Exactly the opposite. Python does not have an opinion about what 1/2 means: approximately 0.5ish (python3) or 0 (python1,2), and I see no reason python4 might not decide to try exact rationals like ½.

                                Python also doesn’t care if you wash your dog outside or in the bathtub, so it’s not that “not being opinionated enough” is necessarily a problem either.

                                Perhaps the original author finds it hard to learn new languages because they’re already worn out from constantly learning new versions of python…

                                The author is complaining that Python doesn’t have an opinion about how to make a python program, but I feel that Python apologists might complain that what is meant by “making a python program” is too vague, or that the language shouldn’t care about how it is run (separation of concerns). Maybe that’s true, but what about x/y?

                                1. 1

                                  There won’t be a Python 4.

                                  1. 0

                                    https://docs.python.org/3/whatsnew/3.7.html

                                    Says there will be. You know something? Or do you want to bet £1,000 on it?

                                    1. 1

                                      I was imprecise– there will never be an “epoch” 4. That is to say, going from 3.x to 4.0 won’t be anything like 2.7 to 3.0. I would reckon switching up division would not be viewed as an acceptable change in that light.

                        2. 10

                          It’s a bit jarring to me that Pythonistas are so… authoritarian in their views. Maybe as a consequence of “There’s Only One Way To Do It” mentality, but anything remotely out of the ordinary seems to scare them into blogging about how everything else sucks…?

                          Languages and their communities are made up of people, and people are flawed so yes projects will have flaws. So does Python! There’s no standardized way of interacting with a language project, and forums will be all over the place, people on them will be cursed with a number of vices, but eventually you make it out with more knowledge.

                          How do I install it? The docs say brew install, but I’m on Windows.

                          You’ll have a lot of problems outside of Python/C++/C#/Java if you’re on Windows.

                          How do I read from a file? How do I parse JSON? How do I pull environmental variables?

                          Read the docs?

                          How am I supposed to be writing this? Do I download an IDE? Is there a Vim plugin?

                          Use whatever - there’s no single right way you’re “supposed to be writing this”.

                          What are the language quirks that will cost me an hour to discover?

                          Everyone gets tripped up on different things…? And even if not, it won’t be a wasted hour because a language feature (either technical, or of design) is behind the quirk, and you’ll be better off knowing it?

                          I could go on, but the questions are too lazy. Languages are not easy.

                          Screw this, I’m going back to Python.

                          Oh well.

                          1. 24

                            I think you are misunderstanding his point. I don’t think he’s using Python as the gold standard on how to do things (because it sure as hell isn’t even though I love it). He’s using Python as a stand-in for “insert familiar preferred language”.

                            That list is a pretty decent summary of what a tutorial or reference for new programmers should contain. Go to any unfamiliar language and check out their tutorial and see how many of these points they check off. I’m sure there’s quite a lot of the more important points left. You are probably capable of finding out those things yourself, considering the criticism you are levelling at the post, but imagine you are very new to programming; what even is JSON? Why wouldn’t brew install work on Windows? Environmental what? Do I use Word or Notepad to write the code? Why can’t I do if a > b > c?

                            Being familiar with another language does not really mean you are that proficient with it either. It just means you have managed to start coding in it and your programs mostly function when you start them up. Pretending everyone has 10 years of experience with C, Rust, JS, Java, Python and insert your flavor of functional language is absurd and elitist.

                            1. 17

                              How do I read from a file? How do I parse JSON? How do I pull environmental variables?

                              Read the docs?

                              The first time I tried to use Swift, I ran into a bunch of these issues. Swift is a “app developer” language, at least as documented by Apple, so you don’t read files from a path, you read them from a bundle. What’s a bundle? Welcome to Foundation! Don’t know what that is? Down the rabbit hole of Apple specific APIs that don’t map to other languages we go.

                              1. 3

                                Yeah it’s one thing to just ‘read the docs’ when you’re asking simple questions like that and the language you’re using is Yet Another System Call Wrapping Language With A Basic Standard Library And FFI like Python, Ruby, Node.JS, Rust, etc. It’s quite a different issue when you’re learning a new language but where ‘new language’ is code for ‘entirely new set of APIs, things you might want to do, etc.’ like Swift where you’re not just learning a new fairly mundane and simple language but also an enormous API surface, UI paradigm, app development conventions, operating system, etc.

                                1. 1

                                  Pretty sure the docs for Swift cover all that.

                                2. 0

                                  There’s a difference between Swift and the APIs you call with it. You don’t need bundles to work with files:

                                  let file = "file.txt" //this is the file. we will write to and read from it
                                  
                                  let text = "some text" //just a text
                                  
                                  if let dir = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first {
                                  
                                      let fileURL = dir.appendingPathComponent(file)
                                  
                                      //writing
                                      do {
                                          try text.write(to: fileURL, atomically: false, encoding: .utf8)
                                      }
                                      catch {/* error handling here */}
                                  
                                      //reading
                                      do {
                                          let text2 = try String(contentsOf: fileURL, encoding: .utf8)
                                      }
                                      catch {/* error handling here */}
                                  }
                                  

                                  (from StackOverflow)

                                3. 9

                                  To me this post sounded like a bunch of made up reasons to avoid learning a new language. Yes, some languages will have better documentation than others, some languages will have better support for $OS than others, some languages will have better editor support for your favourite editor. But guess what, that’s all because someone put in the effort to make it so. If you believe for example that the editor support is not up to snuff, you can improve it for yourself and everyone else after you.

                                  And yes, there will be “that one package everyone uses” because it’s better than the others, but why should there be an official statement about that anywhere? This is basically a cultural thing. Also, you can’t expect to completely become a native in just a few days. Besides, what’s best today might not be best tomorrow (think e.g. Requests, which is by many people considered the de facto Python library for HTTP, but with the introduction of async/await in the language, it’s no longer so clear that Requests is the way forward). Also, something might be great today but something even better might come along in a few years.

                                  What do you do when you want to become more embedded in a culture? You make some friends and ask people to explain the local customs to you. Or maybe you buy a book about the culture and learn it from that. But mostly, you learn it through osmosis, by spending time in there.

                                  1. 7

                                    I suspect the post is more of a collection of common objections and stumbling blocks for people that might want to try out a new language. Any one of them might be the the thing that turns away a single person, as they pile up, less people are willing to jump over the hurdles.

                                    I don’t think anyone expects to be “native” in a few days, but I know for me, if I can’t find a way to get a foothold in a language or framework within 4-6 hours, my interest moves onward. A foothold here is a basic, but useful (ideally) program that I can use as a base for building greater understanding over time. (Useful being a bit subjective). There are some exceptions to this, especially at $WORK, but yeah.

                                  2. 8

                                    I don’t think this post is Python-specific. I think everything makes sense even if you substitute “Python” for “$MY_LANGUAGE_OF_CHOICE”

                                    1. 2

                                      My point was that looking for the one specific way you’re “supposed to be writing this” is a sentiment I get from a lot of Python coders.

                                      1. 2

                                        Is that so bad though? “You could do X in 10 different ways” would tend to confuse beginners (arguably) even more.

                                        1. 2

                                          Yes, it is bad for a general purpose language to have one specific way of doing things. I have enough of a hard time having to always work with the same cloud provider (AWS), don’t tell me my code doesn’t conform to some standard if it achieves the same result. Coding is a creative endeavor, not paint by numbers.

                                          For me, it’s an excuse to only support code written a certain way, and screw you for thinking differently.

                                          1. 0

                                            Yes, it is bad for a general purpose language to have one specific way of doing things.

                                            In the language camp that you’ve spent the most time in, that advice may apply. But claiming anything to be universally true (or false) is taking things a bit too far.

                                            For instance, Ruby folks are happy having 10 different ways of doing the same thing, and Python folks are happy having one single way. Different people feel productive in different ways. That doesn’t have to mean that one is better than the other one.

                                            1. 1

                                              claiming anything to be universally true (or false) is taking things a bit too far.

                                              We’re in agreement here. Python coders say there’s only one right way to do things, I reject that because different people feel productive in different ways.

                                              1. 0

                                                Python coders say there’s only one right way to do things

                                                … in the Python world

                                    2. 11

                                      It’s a bit jarring to me that Pythonistas are so… authoritarian in their views. Maybe as a consequence of “There’s Only One Way To Do It” mentality, but anything remotely out of the ordinary seems to scare them into blogging about how everything else sucks…?

                                      You’re missing the point. Python isn’t some magical language that has all of these fixed. In particular, the packaging situation on Python is an utter mess. The point is that the learning a language means learning the ecosystem and accidental complexity bundled with using a language in the real world. And that’s hard. Someone switching to Python from Java would have these exact same problems.

                                      You’ll have a lot of problems outside of Python/C++/C#/Java if you’re on Windows.

                                      In the 2018 SO survey, half of all developers said they used windows. Dismissing them out of hand is a great way to show just how little you care about adoption.

                                      I could go on, but the questions are too lazy. Languages are not easy.

                                      Many languages are essentially complex. Most are far more accidentally complex, making it artificially hard for beginners to start using it.

                                      Perhaps this should be another bullet point under community: “Does the community think its the beginner’s fault for struggling?”

                                      1. 3

                                        I’ll stand as a Windows developer who has used quite a few languages on Windows outside of that group. Support varies, for sure.

                                        1. 1

                                          In the 2018 SO survey, half of all developers said they used windows. Dismissing them out of hand is a great way to show just how little you care about adoption.

                                          I didn’t dismiss them. I just pointed out the large majority of them are using Python/C++/C#/Java. I guess I could have added PHP to the list.

                                          Perhaps this should be another bullet point under community: “Does the community think its the beginner’s fault for struggling?”

                                          There’s struggling and there’s I expect every problem to be already fixed for beginners, so I don’t have to struggle. Struggling while learning a new language is always going to happen. To dismiss it with “Screw this, I’m going back to my blanket” is unrealistic.

                                          1. 11

                                            There’s struggling and there’s I expect every problem to be already fixed for beginners, so I don’t have to struggle. Struggling while learning a new language is always going to happen. To dismiss it with “Screw this, I’m going back to my blanket” is unrealistic.

                                            Dude, my job is improving accessibility for formal verification languages. Look how many of the other commenters are talking about the same pain points. These are not “I want my blanket” problems, and you thinking they are is a sign you haven’t had to go through this in a very long time.

                                            1. 0

                                              Dude, my job is a bit immaterial to the point. And I’ve been learning a language that is still in alpha and makes me file Github issues when I use it because it explodes left and right. I don’t say “screw this, I’m going back to $COMFORTABLE_LANGUAGE_I_KNOW” because I realize a) it has future potential and b) creating languages and growing them, along with a community around it, is no easy feat. And it doesn’t have to be for me to consider learning said language worthwhile. The world doesn’t revolve around my needs (or my job). And plenty of other commenters see your post as whining, too.

                                              1. 7

                                                Dude, my job is a bit immaterial to the point.

                                                The point of that statement is that I’m not demanding anything radical, and I’m often the person who’s fixing these issues for formal verification languages. I’m not a no-stakes observer complaining about languages being hard, I’m talking about actual barriers to learning and adoption.

                                                The world doesn’t revolve around my needs (or my job). And plenty of other commenters see your post as whining, too.

                                                Okay, I don’t think this conversation is going to go anywhere. If you think these very real issues are “whining” or a “blanket”, then we don’t have any common ground.

                                                1. 0

                                                  If your point is that you have languages have to:

                                                  • Explain how to install them for every operating system available
                                                  • Tell you how you should be “writing” with it
                                                  • Tell you all the quirks that might cost you (personally) an hour or more to discover
                                                  • How the help is organized (not just where it is)
                                                  • Where to look for your specific problem X they don’t know about (docs, FAQ, community, Google)
                                                  • Teach you how to debug with it
                                                  • How to do unit testing
                                                  • How to build, package, manage your environment
                                                  • Package management
                                                  • Where the language community is, who the abusers are, tell you about the high-profile rivalries, all the in-jokes
                                                  • ….

                                                  for you to figure them out or else you screw back to Python, then yeah I don’t think we have common ground.

                                      2. 4

                                        I have this discussion fairly often at work when people start complaining about languages, tools, frameworks, etc. I have to tell them, “the technology we are using wasn’t build for what we are trying to do. It was built to do what the people who built it want it to do. And since we are not in the business of building languages, tools, or frameworks, we just have to do the work with the best things we can find for the job.” It’s a little cynical, but the mentality has made me more productive.

                                        1. 3

                                          Heh know them feels, just swap out Python for Haskell..

                                          1. 0

                                            I would if:

                                            • it had easy cross-compile features like Rust
                                            • there was a standard way of writing code as opposed to every library using a different style that you need to learn
                                            • operators would be limited so I could read any code immediately instead of mapping out what operators do for a particular library
                                            • there were production-ready libraries for everything we do
                                            • there was an eager version of the language so I could disable the laziness for less obvious use cases when it bites you
                                            • there was much more documentation on how to write concurrent & parallel code

                                            And a few more things. I think Haskell is excellent for learning FP concepts though.

                                          2. 4

                                            And this, kids, is why “polyglot programming” is the biggest scam perpetrated on the American public since the invention of the carpet sweeper!

                                            Learning a language to true proficiency – which includes everything listed here and more – is hard, takes a lot of time, and should be a pre-requisite for writing production code.

                                            1. 5

                                              should be a pre-requisite for writing production code

                                              I’d like to go on a little tangent here: I think we all know that the only way to reach that level of proficiency… is to write production code. All companies with predictable cash flow should get very serious about hiring and mentoring junior programmers. When I’m in a hiring position, I never make knowledge of our precise tech stack the main criterion.

                                              If we don’t take mentoring seriously, there is no way to get the quality programmers we all need. We can’t just leave it up to others to teach and them pick the fruit when it’s ripe.

                                              1. 3

                                                Full ack. Jumping in at the deep end and then having people around you show you the ropes, with good code reviews is the best way to learn. That also fixes the paradox of learning a language at the same time as working on production code; the experienced team members will be able to explain where you hit subtle pitfalls of the language, where you’re not using the language in an idiomatic way and so on, which protects you from actually pushing such mistakes into production.

                                                1. 2

                                                  I don’t disagree with this. I’d just say if that’s what’s going on, you should have a good mentoring and code review system.

                                                2. 1

                                                  I sort of agree, but then I could not have learned about concepts that helped me significantly to write cleaner code. Let’s say my default language is Python and I do most of my work in that. Learning Clojure and Haskell was amazing, even though I cannot use them in production at all, let alone mastering them (obviously without production experience). I think there is large amount of people writing Python or Java (two trendy languages) who are not aware of functional language concepts that are very obvious to people who are coming from Clojure or Haskell. Funnily enough, Java 8 introduced a lot of these concepts, and now the people who 5 years ago were convinced that a for loop is the best for iteration are producly claiming that map / reduce is the best. Earlier in my career, one of my friends, who has a background in CS, explained to me that people think about the CS concepts based on which language they use daily or used for studying programming. This is the reason that universities teach (or at least used to teach) programming with SML, Scheme, etc.

                                                  1. 1

                                                    Oh I’m not saying you shouldn’t learn many languages… as an individual programmer, you should. But you should also be honest about your level of proficiency in each, and learn at least some deeply.

                                                    I’m attacking the idea that encourages a team of software developers to simultaneously do work in multiple languages because…. something, something, “right tool for the job”, something, “hey, i can learn that over the weekend!”

                                                    Sometimes it can’t be avoided, of course. But the idea that you’d choose this path voluntarily, assuming almost 0 cost to each added language, is the insane part.

                                                3. 2

                                                  Funny, having the same experience with python right now coming from a background where I wrote things functionally.

                                                  I’d like to say screw this, I’m going back to javascript, but pyplot & networkx are too good :(

                                                  1. 2

                                                    This is the feeling, his journal of the learning burn. A stranger in a strange land. No one like feeling dumb. Adults hate it so much that we aren’t like kids, sponges. Adults hate it so much we can’t learn new skills unless we get past it. And with computers already making us feel dumb (yes, computer you are correct, I see, my bad [fix]) on an hourly basis, how can you even take on more toopid points?

                                                    I think it’s at least an energy thing. You have to find some downtime between projects. Extra energy. I don’t know how that happens personally. For me, recently, it was having time between jobs. I mean, it’s rare to just “have time” and not “make time”.

                                                    Or another way to look at it. The Seven Stages of the Blub Paradox.

                                                    1. Shock - Python 2 is EOL?!
                                                    2. Denial - Surely they will do an extension for security updates.
                                                    3. Anger - Ugh. I have to change all this stuff!
                                                    4. Bargaining - Maybe I can just 2to3.
                                                    5. Depression - Maybe I’m too old to learn Python 3. I should go into management.
                                                    6. Testing - What if I just start a py3 branch …
                                                    7. Acceptance - Hmm, f strings are pretty neat.

                                                    Hmm, metaphor is very strained and this is not really what burning in a new ecosystem is like. But you can imagine anything you could do in python 3 would be possible in python 2. Turning complete vs neat tricks. All languages are the same but that’s not the point. Each language has taught me something and then diminishing returns like @arp242 said. End of history illusion. This won’t be the last time you face a new ecosystem. I try to understand the world view and reason for existing. Then play around. Then look at that reason for existing again.

                                                    1. 1

                                                      Totally nailed it.

                                                      During my CS studies I spend most time writing C and Ruby. It was a great combination in my opinion. Then I transitioned into operations and found the space was mostly Python (and Perl) and growing with Golang.

                                                      Golang has a fairly simple syntax, great documentation, and is easy to get going, but learning all those new patterns around concurrency was harder than expected. Sure watching Rob Pike presenting them in talks was great, but applying them with all the carefulness you need for business, was another thing.

                                                      Python was even harder. Probably because I thought that coming from Ruby, it’s be easy, but in fact, learning everything that’s on that list is surprisingly hard. One thing that worked well, is following Python advocates and trying to read their code, read their vimrc, etc… it helped a lot.

                                                      1. 1

                                                        This is why JS is my language of choice. Can do frontend, backed and apps too!

                                                        1. 1

                                                          Love the list! Would be cool to go through it and add answers for a couple of languages.

                                                          1. 1

                                                            It amuses the heck out of me given the low opinion a number of users here have of Python that the punch like was “Screw this, I’m going back to Python”.

                                                            1. 3

                                                              That would probably have been “screw this, I’m going back to PHP” 10 years ago. And, indeed, the most popular languages do tend to have the most (if not necessarily the best) tutorials, there’s a lot of knowledge spread about on various sites like Stack Overflow, the documentation gets more love and so on and so forth.

                                                              I guess this just shows you need to make a tradeoff between sticking with the most expedient, popular thing (a million flies can’t be wrong) and the technically best solution which will need more effort to get into it. Then, if you do find something you like better, make an effort to help bring that up to the same level as $POPULAR_THING.

                                                            2. 1

                                                              OP, since you seem to be the author: Is it just me or is the TLS certificate on the website expired?

                                                              1. 1

                                                                I get the same message. Certificate issued by Amazon, expired 2020-04-26 @hwayne.

                                                                1. 1

                                                                  Ugh, this is weird. Amazon is saying that both certifications were renewed on 2020-04-20. But the old certificates expired two days ago. Is there some way to “refresh your cache”? I don’t know certificates very well :(

                                                                  1. 1

                                                                    I had the issue the first time I opened the article, but it’s gone now.

                                                                    1. 1

                                                                      Clearing the cache of my browser (Firefox, macOS) did the job for me (actually I just opened the devtools, checked “disable cache”, refreshed the page, closed devtools pane and that’s it because I’m a browser nerd).

                                                                2. 1

                                                                  I have a similar situation with regards to Javascript. With all the WFH I am getting more time to work on side projects. The thing with JS that I have come across as most baffling is how to decide what runs only in the browser Vs what runs on my CLI, using node? Do I really need jQuery? I am supposed to learn react next but this basic distinction seems to confuse me.