Compare them in your particular scenario. Only you know what is important to you. If choosing for a company, ask the people who will have to work with it.
Maybe one has more responsive developers, or a more helpful community.
The fact you worry about what language they're written in - while you shouldn't need to ever edit any of their code - already implies they're not boring and you're overthinking the decision already.
Pick the one that gets you up and running the fastest, ideally one that doesn't rely on you installing additional runtimes.
In principle you’re absolutely right, but Hugo actually comes with lots of strings attached due to their choice of Go, like having to use Go templates for example - which can be weird if you don’t have a Go background. The more elaborate constructs you’re trying to build, the more you need to research how the Hugo Go runtime works to sort out quirks.
Flip a coin, try the first one out, and if anything pops up in a few days that makes you think the other might be more suitable, evaluate the other one.
I recently started experimenting with Snowpack for JS build. I realized it doesn’t do sourcemaps very will so I grabbed Parcel. That worked great but doesn’t have a testing story and Vite has a couple options there. Vite has been good.
It was work to evaluate each of those and switch between them. But not that much work really since I hadn’t committed a huge codebase yet. But it was worth it because now I know why you might choose one over the other.
I do this. But 1d20 / options. Crit fail means ignore for a week otherwise divide up the space evenly and extra slots mean re-roll. Having the option to punt is useful.
Before you spend much time on a pure (thus limited) SSG, I recommend taking a close look at https://Remix.run. Remix supports a superset of Eleventy or Hugo (or Jekyll or even NextJS export). It's too new to be considered "boring", but it leverages OG web standards and defaults to web platform-native foundations. Given its provenance and the authors' bona fides, I'm betting heavy it sticks around for the long haul. I'm unaffiliated w the project, but I've been doing web-related things for a living since 1998, and for me Remix is a breath of fresh air and the successor to NextJS as my framework of choice.
So? "People" may have said all
kinds of things about Redwood or the price of rice in China. I never promoted Redwood, and (to engage with your off-base "rejoinder") objectively speaking, it didn't offer any advantages over NextJS. Remix, on the other hand, is fundamentally different from any other framework.
Boring is on a scale, and you need a reference to assess the level of boringness. Eleventy, Hugo and Jekyll are all a little to non-boring compared to ssg6 or just throwing txt files in www-root.
I was surprised to find this published on begin.com, which offers an app deployment platform based on AWS Lambda. So are Lambda, API Gateway, and friends considered boring now?
Yes. In theory it would be the same but practically there are lots of gotchas. For a simple example, having a calculated cache on startup that five seconds would be fine on a traditional server but not on lambda.
- hireability: large community of developers to hire from today + years from now
- low risk of abandonment: long history of development, stable funding, and ideally many users+contributors from diff orgs using in commercial contexts
Not easy for startups and new frameworks to achieve 'boring' status!
> large community of developers to hire from today + years from now
I think this is a red herring. The thing that actually matters for most companies is marginal hireability. By the time you're big enough to worry about absolute hireability (because your hiring demands exceed the liquidity at the margins) you can create a hiring pool out of thin air (e.g. if google invents a new language and shills it a bit, tens of thousands of college students will learn it for free).
If you're a small company and you're picking between Java and Elixir (or whatever) your concern should be "how hard will it be to hire 3 developers at a given quality level?", not "are there 1 million developers available?"
No, it is, how hard is it to hire 3 elixer devs at given quality and do an elastic sprint as 6.. 3 years from now. And what is the chance the dependency chain hasn't rotted.
The million means you arent scrambling . Hiring in niche stuff even for 1 person stinks. Replacing/maintaining dead frameworks is 10x+ worse than writing the original.
When you can find and just drop someone in the same/next week and it's not all cruft... And you're sure that'll be true next year too... That's boring code. Super destressor for everyone as folks can easily scale up / down, take paternal leave, onboard junior /senior folks same-day, etc, and not worry about ecosystem churn.
Ex: It's a world of diff when we hire folks to write our django pieces vs GLSL engine, and both of those ecosystems are big. Just django is the way bigger and thus more stress free. When you go down to niche langs with niche frameworks.. unless there is a good reason, I don't want to be in that company nor bet on it 2-4yr from now. For us, we do GPU everything, so careful parts of our stack are weird and constant careful effort, and we try to limit it to just those.
It's 2am and I am desperate to fix a customers problem. What's the chance of me finding the answer on SO? Good documentation is obviously helpful, but SO expresses knowledge in a Q&A format much better.
Weirdly enough I do believe Clojure ticks the boxes from that checklist.
It's familiar in that it both "supports popular language runtimes" (runs on top of the JVM or transpiles to JavaScript) and it's a Lisp dialect (or close enough) and Lisps have been around since a very long time.
It's incredibly stable: so stable some libraries commonly used haven't been updated in years. There's also very little code churn inside Clojure's own codebase.
It is very reliable.
It's limits and trade offs are well known.
Somehow I though my language of choice was "edgy" but I realize it may actually be "boring": a dialect from a very old family of language running on top of a boring tech (the JVM).
How about hiring though? If you have a vacancy for a Clojure developer, how many applicants could you expect?
When it comes to programming languages, I'd stick to the top 10 languages if your company isn't hip enough to attract a certain kind of developer on its own.
No I appreciate that - my point is you can get better engineers that you might deserve at your startup by using a language like Clojure to entice them. I know people who work for a good discount if it’s on a tech stack they enjoy and is fairly rare to find.
That's pretty hyperbolic and also seemingly irrelevant. There are enough companies that don't have this expectation and give new engineers the time and space to become familiar with the company before setting any concrete performance goals.
Of course they can learn new languages. But it takes some time to become really proficient in a language. The question is how many languages do you want to support in your company? Because it's not realistic to think that developers will not need to move from project to project. And in fact when things get busy they may need to swap from one project to another and back on the same day. It's not ideal but that's life. The inefficiency of swapping between languages will often outweigh the efficiency of the new language.
Google were notoriously strict for limiting languages at the start and I think it was very frustrating for some of the developers they hired. If I had a boring technology checklist then "Language we already use" would be top of the list.
- A nonzero number of excellent potential applicants aren't going to work for your company because they don't want to invest their own development into learning the Clojure ecosystem deeply. (This might be somewhat balanced out by folks who are stoked to learn Clojure.)
- Every non-Clojure person you hire will require significantly more ramp-up time. This can be a real problem for small companies where you lose quite a lot of expertise every time a senior developer leaves.
- These problems compound for every "innovative" technology you add.
When hiring / recruiting Clojure devs, there are quite a few second-order effects which are quite unintuitive.
Clojure devs are much more senior - they've typically been burnt by at least one tech stack, often more (Java, JS + React, Fortran, Cobol, punching tape, etc.). Clojure devs also tend to be really passionate about, you guessed it, Clojure, which commonly turns out to be a good thing. People passionate about that level of language-detail tend to be meticulous about many other useful things, like choosing the right tools and building simple and maintainable applications.
There's sometimes a slight tendency towards over-engineering which is understandable. People who dive deep into other programming languages and go through the pain of learning lisp sometimes tend to lose focus of the actual (business) problem to solve. But I wouldn't say this tendency is significantly higher than elsewhere. Still, sometimes, the pragmatism of a rails dev just churning out code is missed.
Also, because Clojure jobs are scarce and there's a high number of "secret Clojurists" (people who code Clojure at night and secretly dream of using it at their day job), you actually get a much higher number of applicants than you would have estimated based on the most recent Stackoverflow survey.
Also, you get a real shot at hiring rockstar devs. This is huge and cannot be overstated. If you're hiring for a standard JS / Python stack, you're suddenly competing with FAANG companies and their salaries. If you're hiring for Clojure, you're hardly competing with anyone. And you get a good pre-selection of senior devs. Like, those which were burned at a FAANG company, who finally came to their senses and now want to code Clojure. What's not to like?
I guess a drawback would be that you couldn't instantly hire a local team of 100+ devs, even if you take secret Clojurists into account. But who would want to work at a place which hires 100+ devs in a short amount of time?
(I interviewed around 200 people, many of them for Clojure roles, sometimes even comparing Python and Clojure applicants for the same role)
All the points you're saying here are the usual arguments for choosing non-boring technology (I think I've seen this argument essentially verbatim for CL, Haskell, Clojure, Elixir, etc.), which is fine in isolation, but doesn't really fit in a thread about Clojure as boring technology.
"because Clojure jobs are scarce . . . you actually get a much higher number of applicants <and> you get a real shot at hiring rockstar devs"
I have felt this to be true for many years. I was an early Clojure adopter, deployed Clojure apps into production shortly after attending the very first Clojure/conj, and did quite a bit of hackerrank and similar competitive programming exercises with Clojure for fun and learning.
I didn't have much luck getting job offers for Clojure positions but was mostly successful in getting job offers for other tech stacks during that same time. It was kind of funny to me - I really wanted to move to a Clojure-only shop but kept getting offers for SQL and Java/C# positions despite not really being an enterprise dev type.
From what I heard, Nubank hired a good deal of Elixir developers when they aqui-hired Plataformatec. I suspect having functional programming experience matters more than having concrete Clojure knowledge. It definitely didn't seem to be a problem in this case anyway.
I'd agree that clojure fits the boring tag, and that's a good thing. Unfortunately it's also dying. While many old libraries and tools are stable and functional, nothing new is really being created with it. The same couldn't be said for boring technologies like Java or Python.
I like Clojure, but it's really the exact opposite of the sort of "boring technology" that this post advocates. If MongoDB costs you 2 innovation tokens, Clojure costs at least 2, perhaps all 3.
The cost of innovation is not so much in the core of Clojure itself, but that once your company gets larger, you will want to integrate with more and more things that have not put effort into Clojure compatibility, just because the language is not very popular. Also hiring.
What is this 'Clojure compatibility' of which you speak? Seriously though, Clojure runs on the JVM so the entire Java ecosystem is available. There are ways to run an external process too of course. I can't really think of an example where 'Clojure compatibility' is something we would require people to have thought about.
A simple example is, let's say you're making a small web service. Are you going to use a Clojure framework or a Java framework via JVM compatibility? If you pick a Clojure framework, then all the subsequent choices you have to make, you'll run into the "non boring tech" issues. Has someone already built a GraphQL plugin, a plugin that integrates with the Twitter preview API, etc etc it depends on your project but you'll run into things. If you pick a Java framework, you'll end up running into a bunch of cases where you can't use the "normal solution" for that framework because you're running Clojure.
It's not the end of the world or anything, and for a smaller project Clojure might be the perfect solution. But if it's something that you're trying to scale into a startup with dozens of engineers then you're probably going to pay a higher incompatibility cost for using Clojure.
Clojure doesn't need FFI, neither does it need anything to run but the JVM, you package your application in a jar and run it the same as always, and you only write Java using your system editor and the JDK in introductory compsci courses.
The problem with Clojure is that it is too good. It gives you, the programmer, too much freedom.
Most people do not have problems that require so much freedom.
Most people do not know what to do with that freedom -- they don't have enough experience actually organising their applications.
Most people benefit from using a language/framework that requires them or at least rewards them to put things in a certain way. For example Java Spring rewards people for following a certain application design -- you can break rules but then you are on your own and Stack[Exchange|Overflow] examples can no longer be copied/pasted directly into your codebase.
As much as I love Clojure, every single corporate Clojure project I have seen in the past was an utterly unmaintainable mess.
I have never actually participated in a Clojure project (I use Clojure mostly for rapid prototyping/PoC-ing), but what I figured is that Clojure requires minimum maturity from the developer and especially drive to be constantly simplifying things -- which is unfortunately very high bar. Most developers I work with / interviewed do not really understand what it means to refactor and simplify. Most people are only focused on the part of the work when they get something to produce expected values and everything else just isn't high priority in a corporate environment.
I'm years out of date on this stuff, but I note the staging URL has found its way into Google as well, you might be able to fix that up by adjusting the <link rel="canonical" href="https://blog.staging.begin.com/..." /> to point to the authoritative URL even when the page is on the staging server.
This article would be enhanced with concrete examples. The "Boring Technology" argument is hard to attack because it's an opinion, an ideal. It's a good ideal, mind you, but it has the problem of being different for each person, even if they're all on the same team looking at the same use case.
Another good extension to the topic would also be defining when Boring Technology becomes Ancient Technology. You need to hit that middle of the tech curve where it's understood and stable but also still being maintained and keeping up with modern needs.
I think the flexibility of the ideal is part of what makes it so attractive. "Boring" may mean some pretty cutting-edge technology because your team is so thoroughly steeped in it that they know it back to front.
For me, "boring" means avoiding things like Kubernetes because it's an ecosystem with which I am woefully unfamiliar and I can more or less achieve with other (possibly less efficient) means.
Ted Dziuba made a point a while back that the three tools for systems engineering are money, time, and code, and they should be used in that order. It's a sort of shorthand for "boring" to just buy a bigger server, or spend the time to leverage existing and know Unix tools, and then if all that fails, use some gimcrack new tech to solve your problems.
(Though, I'd say that the biggest impediment to leveraging "boring" technologies is correctly determining what your problem is. Sometimes we focus on the wrong metrics, or the right metrics at the wrong time, and that skews our decision making.)
The discussion around "boring" technology is an important one. Where to draw the line will be pretty context-dependent. An aerospace firm will put the line here, and a tech startup focusing on a low-risk use case will draw the line somewhere else. And the developers and other stakeholders will be relevant as well. In this context, the checklist at the bottom is interesting food for thought. But I would be wary of relying on it for choices around what technology to adopt, because such decisions will always need to be considered in context. In that sense, the checklist feels well-meaning and even insightful, but a little too concrete.
In aerospace engineering you would usually select technologies based on a concept of technology readiness level, which provides a framework for evaluating new technology and make sure you are in control of their maturity.
If the ability to keep the site up is any indication, it looks like boring tech does not work as well in practice as the theory would have you believe.
I feel like I've spent the last 10 years seeing "boring" in headlines and thinking mundane, when actually it was referring to tunneling. Now I'm finally conditioned to think tunneling first, and this.
It's like BLM, whether I think Black Lives Matter or Bureau of Land Management, the reference is bound to be about the other one, sure as the the USB is always backwards.
> friendly community (Code of Conduct, blogs, chats, podcasts, etc.)
In my experience, most of these things negatively correlate with stuff I actually want (like software quality or stability). It indicates a software ecosystem that exists mostly as an ersatz social outlet for a certain kind of person. The best softwares I use tend to have none of this stuff - maybe just a mailing list and a bug tracker.
So one (albeit large) backward compatibility break every few decades is too much?
I wonder how you'd classify JavaScript since the language is very backward compatible, yet the popular libraries built upon it break compatibility often.
Amen. An abundance of these things signal (to me) developers concerned with themselves, not the technology.
People in this scene are going to be the first to switch languages/frameworks or introduce drama into what should otherwise be pedestrian problem solving exercises.
And on a more concrete note, when it's 3AM and your pagerduty is lit up like a Christmas tree, are blogs, chats, podcasts what you're interested in? No way! You want cold hard documentation and crusty "tell-it-like-it-is" engineers or consultants. They're seldom bubbly, but they command respect and get it done.
Familiarity
supports popular language runtimes, tools, and idiomatic APIs
experience deploying this technology to production today
Stability
follows a predictable release and versioning scheme (note: NOT frequent is fine and in some ways more desirable. security patches are always welcome of course.)
biases for non-breaking changes easing long term maintainability
publishes a regular changelog
open-source and/or open-source backed service
ideally public governance: roadmap, issue tracking, and decision making all visible
Reliability
can be trusted to work as expected; ideally does one thing well
social proofs exist (careful!)
Well understood limits, and trade-offs
accessible docs
objective benchmarks and/or published service quotas
friendly community (Code of Conduct, blogs, chats, podcasts, etc.)
I wonder, how many engineers will switch their jobs because they have to work with boring tech?
Sure, the stack you're using isn't everything and other parts of a project can be just as exciting. But I often heard engineers complain about their company being stuck in the past and they wish to use all the cool tech they see in the news.
> But I often heard engineers complain about their company being stuck in the past and they wish to use all the cool tech they see in the news.
This is becoming my go-to filter for determining if I would want to hire someone in the first place. Hypothetically, if someone told me they left their prior job because they wanted to "use cool tech" on an interview, I would be providing a strong "No" input to the process.
The honest reality is that a lot of people are doing a job they probably should not be doing. If you want to be really good at writing software for other people, you should enjoy delivering experiences to your actual users. I find many developers can't even enumerate who their end users are these days.
I've worked at companies where many of the devs were not remotely excited about any new technologies and just wanted to do their 9-5 and get home to the wife and kids, which is a totally valid career choice. These guys just wanted to stick with what worked and what they knew. They LOVED boring.
Personally I believe that even more important than picking boring technology is limiting the number of different technologies in your tech stack. That will allow you to collect more best practices, build better tooling and monitoring and develop operational experience in those few technologies than if it was spread across multiple similar stacks.
Example: React is great for starting with smaller and/or progressively enhanced websites, but if you were to develop a large monolithic SPA you might benefit more from something like Ember. However it would be better to use one stack which can cover both use-cases, so you should probably go with React for both, otherwise you'll forever be rewriting the same code for both stacks and figuring out build and tooling issues twice.
Another example: You might need a lightweight message queue for smaller background processing needs, and you might also need a proper distributed log. The former could be solved by any number of queues, while the latter calls for something like Kafka. If Kafka can also reasonably cover the first use-case you should try to use it for both.
Exactly. Choose boring technology, but more importantly choose technology that works within your org and keep it consistent.
Say your company chooses risky, bleeding edge tech and uses it everywhere. You'll build institutional knowledge that can be transferred across projects, lowering the risk.
If every single app or microservice uses a different "boring technology" - one team is using Python and Postgres, another team is using Ruby and MySQL, etc - the knowledge gets siloed quickly which increases risk, no matter how "boring" those individual choices may seem.
A boring technology is one with which a large number of developers have previous production experience with. Or probably even "of the developers you can realistically expect to hire".
Better yet, hire developers who enjoy and excel at selecting and utilizing emerging technologies that will be a better long-term fit for the problem at hand. This is of course more difficult, but makes for a better team and product. I want my competitors to be afraid of technology and to de-prioritize hiring generalists.
I think commentators are missing that a big part of boring technology is, well, that it's boring. If developers are excited to use that technology, instead of just thinking "meh just another one of those companies using X" then it's probably not boring.
If your technology gets developers excited then it's not boring.
As per the original article that introduced the term, that doesn't mean that it's a priori a bad thing, but it does mean that the bar for the other things it brings to the table needs to be higher and that most startups only get a limited number of technologies to be excited about.
118 comments
[ 2.6 ms ] story [ 194 ms ] threadFor example I’m debating between Eleventy and Hugo (because I know both JS and Go, but not Ruby so I will skip Jekyll)
Maybe one has more responsive developers, or a more helpful community.
Pick the one that gets you up and running the fastest, ideally one that doesn't rely on you installing additional runtimes.
I recently started experimenting with Snowpack for JS build. I realized it doesn’t do sourcemaps very will so I grabbed Parcel. That worked great but doesn’t have a testing story and Vite has a couple options there. Vite has been good.
It was work to evaluate each of those and switch between them. But not that much work really since I hadn’t committed a huge codebase yet. But it was worth it because now I know why you might choose one over the other.
Granted the “boring” choice would be Webpack.
That's what people said for Redwood.js. One year later and it's mostly forgotten.
The corollary that's missing, of course, is that they often should get fired—but popular (sorry, "boring") choices have a momentum of their own.
It’s just a container that you have to boot and it handles web requests, right?
They boot fast, so for a low traffic site you can worry less about cold start, is there any other difference with any other containerized web server?
- hireability: large community of developers to hire from today + years from now
- low risk of abandonment: long history of development, stable funding, and ideally many users+contributors from diff orgs using in commercial contexts
Not easy for startups and new frameworks to achieve 'boring' status!
I think this is a red herring. The thing that actually matters for most companies is marginal hireability. By the time you're big enough to worry about absolute hireability (because your hiring demands exceed the liquidity at the margins) you can create a hiring pool out of thin air (e.g. if google invents a new language and shills it a bit, tens of thousands of college students will learn it for free).
If you're a small company and you're picking between Java and Elixir (or whatever) your concern should be "how hard will it be to hire 3 developers at a given quality level?", not "are there 1 million developers available?"
The million means you arent scrambling . Hiring in niche stuff even for 1 person stinks. Replacing/maintaining dead frameworks is 10x+ worse than writing the original.
When you can find and just drop someone in the same/next week and it's not all cruft... And you're sure that'll be true next year too... That's boring code. Super destressor for everyone as folks can easily scale up / down, take paternal leave, onboard junior /senior folks same-day, etc, and not worry about ecosystem churn.
Ex: It's a world of diff when we hire folks to write our django pieces vs GLSL engine, and both of those ecosystems are big. Just django is the way bigger and thus more stress free. When you go down to niche langs with niche frameworks.. unless there is a good reason, I don't want to be in that company nor bet on it 2-4yr from now. For us, we do GPU everything, so careful parts of our stack are weird and constant careful effort, and we try to limit it to just those.
It's 2am and I am desperate to fix a customers problem. What's the chance of me finding the answer on SO? Good documentation is obviously helpful, but SO expresses knowledge in a Q&A format much better.
It's familiar in that it both "supports popular language runtimes" (runs on top of the JVM or transpiles to JavaScript) and it's a Lisp dialect (or close enough) and Lisps have been around since a very long time.
It's incredibly stable: so stable some libraries commonly used haven't been updated in years. There's also very little code churn inside Clojure's own codebase.
It is very reliable.
It's limits and trade offs are well known.
Somehow I though my language of choice was "edgy" but I realize it may actually be "boring": a dialect from a very old family of language running on top of a boring tech (the JVM).
When it comes to programming languages, I'd stick to the top 10 languages if your company isn't hip enough to attract a certain kind of developer on its own.
Valid point anyway
Google were notoriously strict for limiting languages at the start and I think it was very frustrating for some of the developers they hired. If I had a boring technology checklist then "Language we already use" would be top of the list.
- A nonzero number of excellent potential applicants aren't going to work for your company because they don't want to invest their own development into learning the Clojure ecosystem deeply. (This might be somewhat balanced out by folks who are stoked to learn Clojure.)
- Every non-Clojure person you hire will require significantly more ramp-up time. This can be a real problem for small companies where you lose quite a lot of expertise every time a senior developer leaves.
- These problems compound for every "innovative" technology you add.
Clojure devs are much more senior - they've typically been burnt by at least one tech stack, often more (Java, JS + React, Fortran, Cobol, punching tape, etc.). Clojure devs also tend to be really passionate about, you guessed it, Clojure, which commonly turns out to be a good thing. People passionate about that level of language-detail tend to be meticulous about many other useful things, like choosing the right tools and building simple and maintainable applications.
There's sometimes a slight tendency towards over-engineering which is understandable. People who dive deep into other programming languages and go through the pain of learning lisp sometimes tend to lose focus of the actual (business) problem to solve. But I wouldn't say this tendency is significantly higher than elsewhere. Still, sometimes, the pragmatism of a rails dev just churning out code is missed.
Also, because Clojure jobs are scarce and there's a high number of "secret Clojurists" (people who code Clojure at night and secretly dream of using it at their day job), you actually get a much higher number of applicants than you would have estimated based on the most recent Stackoverflow survey.
Also, you get a real shot at hiring rockstar devs. This is huge and cannot be overstated. If you're hiring for a standard JS / Python stack, you're suddenly competing with FAANG companies and their salaries. If you're hiring for Clojure, you're hardly competing with anyone. And you get a good pre-selection of senior devs. Like, those which were burned at a FAANG company, who finally came to their senses and now want to code Clojure. What's not to like?
I guess a drawback would be that you couldn't instantly hire a local team of 100+ devs, even if you take secret Clojurists into account. But who would want to work at a place which hires 100+ devs in a short amount of time?
(I interviewed around 200 people, many of them for Clojure roles, sometimes even comparing Python and Clojure applicants for the same role)
Relevant talk: https://youtu.be/kNiGu_VaoTg?t=1566
I have felt this to be true for many years. I was an early Clojure adopter, deployed Clojure apps into production shortly after attending the very first Clojure/conj, and did quite a bit of hackerrank and similar competitive programming exercises with Clojure for fun and learning.
I didn't have much luck getting job offers for Clojure positions but was mostly successful in getting job offers for other tech stacks during that same time. It was kind of funny to me - I really wanted to move to a Clojure-only shop but kept getting offers for SQL and Java/C# positions despite not really being an enterprise dev type.
https://medium.com/building-nubank/tech-perspectives-behind-...
https://www.cognitect.com/blog/2020/07/23/Cognitect-Joins-Nu...
The cost of innovation is not so much in the core of Clojure itself, but that once your company gets larger, you will want to integrate with more and more things that have not put effort into Clojure compatibility, just because the language is not very popular. Also hiring.
The answer to that is to just use java interop.
It's not the end of the world or anything, and for a smaller project Clojure might be the perfect solution. But if it's something that you're trying to scale into a startup with dozens of engineers then you're probably going to pay a higher incompatibility cost for using Clojure.
Nothing extra to install, everything works out of the box, no need for FFI or incomprehensible stack traces.
Poor students, at least Blue/J.
By the way, I already used Clojure in projects.
Usually I only critic stuff I actually know.
Even universities in India use IntelliJ or Eclipse these days.
Most people do not have problems that require so much freedom.
Most people do not know what to do with that freedom -- they don't have enough experience actually organising their applications.
Most people benefit from using a language/framework that requires them or at least rewards them to put things in a certain way. For example Java Spring rewards people for following a certain application design -- you can break rules but then you are on your own and Stack[Exchange|Overflow] examples can no longer be copied/pasted directly into your codebase.
As much as I love Clojure, every single corporate Clojure project I have seen in the past was an utterly unmaintainable mess.
I have never actually participated in a Clojure project (I use Clojure mostly for rapid prototyping/PoC-ing), but what I figured is that Clojure requires minimum maturity from the developer and especially drive to be constantly simplifying things -- which is unfortunately very high bar. Most developers I work with / interviewed do not really understand what it means to refactor and simplify. Most people are only focused on the part of the work when they get something to produce expected values and everything else just isn't high priority in a corporate environment.
Dunno where the staging server came from
https://blog.begin.com/posts/2022-01-27-the-boring-technolog...
Another good extension to the topic would also be defining when Boring Technology becomes Ancient Technology. You need to hit that middle of the tech curve where it's understood and stable but also still being maintained and keeping up with modern needs.
For me, "boring" means avoiding things like Kubernetes because it's an ecosystem with which I am woefully unfamiliar and I can more or less achieve with other (possibly less efficient) means.
Ted Dziuba made a point a while back that the three tools for systems engineering are money, time, and code, and they should be used in that order. It's a sort of shorthand for "boring" to just buy a bigger server, or spend the time to leverage existing and know Unix tools, and then if all that fails, use some gimcrack new tech to solve your problems.
(Though, I'd say that the biggest impediment to leveraging "boring" technologies is correctly determining what your problem is. Sometimes we focus on the wrong metrics, or the right metrics at the wrong time, and that skews our decision making.)
https://en.wikipedia.org/wiki/Technology_readiness_level
So, not ElasticSearch.
"X works fine why are we using Y?" "See Y doesn't cover every X use case perfectly, we should have stuck with X!"
The arguments are predictable at this point. We'd still be using Jquery for developing frontends if this mindset was pervasive.
It's like BLM, whether I think Black Lives Matter or Bureau of Land Management, the reference is bound to be about the other one, sure as the the USB is always backwards.
Seriously though, probably the difference being a boring project and being a bored project.
In my experience, most of these things negatively correlate with stuff I actually want (like software quality or stability). It indicates a software ecosystem that exists mostly as an ersatz social outlet for a certain kind of person. The best softwares I use tend to have none of this stuff - maybe just a mailing list and a bug tracker.
I wonder how you'd classify JavaScript since the language is very backward compatible, yet the popular libraries built upon it break compatibility often.
People in this scene are going to be the first to switch languages/frameworks or introduce drama into what should otherwise be pedestrian problem solving exercises.
And on a more concrete note, when it's 3AM and your pagerduty is lit up like a Christmas tree, are blogs, chats, podcasts what you're interested in? No way! You want cold hard documentation and crusty "tell-it-like-it-is" engineers or consultants. They're seldom bubbly, but they command respect and get it done.
Stability follows a predictable release and versioning scheme (note: NOT frequent is fine and in some ways more desirable. security patches are always welcome of course.) biases for non-breaking changes easing long term maintainability publishes a regular changelog open-source and/or open-source backed service ideally public governance: roadmap, issue tracking, and decision making all visible
Reliability can be trusted to work as expected; ideally does one thing well social proofs exist (careful!)
Well understood limits, and trade-offs accessible docs objective benchmarks and/or published service quotas friendly community (Code of Conduct, blogs, chats, podcasts, etc.)
Sure, the stack you're using isn't everything and other parts of a project can be just as exciting. But I often heard engineers complain about their company being stuck in the past and they wish to use all the cool tech they see in the news.
This is becoming my go-to filter for determining if I would want to hire someone in the first place. Hypothetically, if someone told me they left their prior job because they wanted to "use cool tech" on an interview, I would be providing a strong "No" input to the process.
The honest reality is that a lot of people are doing a job they probably should not be doing. If you want to be really good at writing software for other people, you should enjoy delivering experiences to your actual users. I find many developers can't even enumerate who their end users are these days.
In my experience companies, especially the small ones, struggle to hire engineers. So, they try to spice their positions up with some hot new tech.
Example: React is great for starting with smaller and/or progressively enhanced websites, but if you were to develop a large monolithic SPA you might benefit more from something like Ember. However it would be better to use one stack which can cover both use-cases, so you should probably go with React for both, otherwise you'll forever be rewriting the same code for both stacks and figuring out build and tooling issues twice.
Another example: You might need a lightweight message queue for smaller background processing needs, and you might also need a proper distributed log. The former could be solved by any number of queues, while the latter calls for something like Kafka. If Kafka can also reasonably cover the first use-case you should try to use it for both.
Say your company chooses risky, bleeding edge tech and uses it everywhere. You'll build institutional knowledge that can be transferred across projects, lowering the risk.
If every single app or microservice uses a different "boring technology" - one team is using Python and Postgres, another team is using Ruby and MySQL, etc - the knowledge gets siloed quickly which increases risk, no matter how "boring" those individual choices may seem.
If your technology gets developers excited then it's not boring.
As per the original article that introduced the term, that doesn't mean that it's a priori a bad thing, but it does mean that the bar for the other things it brings to the table needs to be higher and that most startups only get a limited number of technologies to be excited about.