Choose the technology you know in and out, and are immediately productive with.
Choose the technology which is sure to be around in 5-7 years, preferably 10-15.
Choose the technology for which you are comfortable hiring the next 15 engineers.
This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choose exclusively among the top 5 most used in the field.
The key thing here is to avoid surprises, unknown unknowns. You won't have the time to learn from a novice level while building a new company.
A number of wildly successful MVPs were implemented with obscure (or then-obscure) technology which authors knew very well, and which boosted their productivity. ViaWeb was written in Lisp. YouTube was (and still largely is) written in Python, way before it was cool and well-known. The initial Rust compiler was written in OCaml.
This is pretty much spot on. People usually missing the point of 'boring' because they would think of unpleasant and ancient stuff.
The key value is indeed to avoid surprises.
When I read WhatsApp used Erlang back in the day, I was pretty impressed. Not only the obvious things like Erlang was the forgotten secret weapon for massive concurrent apps, but also details like they used FreeBSD back in the day when there was no preemptive scheduling but Erlang has preemptive scheduling so it was okay. Those details reflect they were very confident and they know perfectly what they were doing.
Yes, "boring" as unpleasant associations and this is why it works much better as a title. Consider these two titles:
* Choose boring technology
* Choose well-known technology
More people will click on the first one because it comes with a paradox suggestion. Why should I intentionally choose something unpleasant? That poses an interesting question. The second title sounds boring (how ironic). Why would I click that?
Whenever I hear "exciting tech" I tend to think "hyped to kingdom come". I think of node, docker, mongo, golang, etc. - tech that was pushed with marketing $$$ or big names. I have an inbuilt bias against that stuff - not that it's necessarily worse than alternatives but that the marketing budget or big name backer instantly makes me more suspicious.
For most developers it seems to work the other way around - big names and marketed heavily => it has buzz => it must be good.
Under boring there are two types - PHP and postgres. Boring tedious and annoying and boring reliable workhorse.
Simple C-ish syntax that's relatively familiar to most programmers, write once and compile to/from anywhere without arcane flags, easy to understand and use concurrency model with message passing, reference development tooling that can enforce standards out of the box.
I don't think there is much new here other than removal of cruft.
Well, the makers of Go took Modula-2 (which, funnily, already had coroutines), removed a number of "too complex" features like ranges, changed "begin-end" to curly braces, then added the object system from Oberon (a great move).
They bolted on two principal new features: channels and garbage collection. They also added a few hacks, like the two-value return.
And lo, we have a winner based on tech form 1970s and 1980s, with only a small bit of pixie dust from 21st century proper, the advanced GC. Anybody can become productive in a weekend. (Then the productivty ceiling is hit soon, and copy-paste programming ensues, but the initial high is strong.)
In the beginning it's selling point was small binaries and neat concurrency.
The tech was "exciting" because Google released it. Pretty much anything Google releases is coated in magic pixie fairy dust (perhaps slightly less so these days).
I mentioned in a comment below that a startup I worked for previously used Erlang. It was a giant headache. They initially used Mnesia as a database but it had issues (which I don't recall because it was before I joined). Then they switched to Riak which is written in Erlang, but was unstable at the time. They then used decided to use MySQL and Cassandra, but ran into issues because database drivers were contributed by the community and not updated.
Also, It's basically impossible to hire someone who is an erlang expert, meaning everyone has new to erlang.
Because of these and similar issues the company constantly had outages, despite using Erlang which is supposedly highly reliable.
I agree with you that Erlang usually is not in the category of 'boring' technology.
It's pretty risky for most teams. Despite Erlang was old, those ideas are both alien and novel to most people. The idioms, the patterns, and the architectures are not well explored as mainstream languages. In my personal experiences, there are also many rough edges.
With that being said, the example I raised just to illustrate that the WhatsApp founders had deep understandings of Erlang despite it was a niche technology. The same applies to FreeBSD. Those are the so-called 'boring' technologies for them.
There should also be an explicit call out to both tooling and community. Even if a programming language ticks all the other boxes, Without a sizable and stable community to constantly push tooling languages will fade, not necessarily die.
In my past job I was ColdFusion programmer for 15 years. ColdFusion ticks all the other boxes.
* Created in 1995 and is a very mature platform
* Easy to learn and productive
* I was very comfortable hiring multiple ColdFusion engineers over the years
But, the community moved on and the tooling is now nonexistent compared to other programming languages. ColdFusion will live on, but as a shadow of what it once was. Which is unfortunate because I actually enjoyed the language and platform.
I currently see it happening with Ruby. I used it as a scripting language for DevOps tooling, CLIs, and for small web apps, but without rails.
What I see is Go pushing it out from the DevOps space and Python is more popular as a general-purpose language.
Tools that were written in Ruby(eg.: Puppet) are outdated and new tools are written in Go.
I still think Ruby is a superior language compared to Python, but because mathematicians used Python and the recent ML/big data hype it got more popular and got better libraries which caused an upward spiral.
While Ruby is the language I most comfortable whit and I don't see it going away in the next 10 years. I have to accept that first-party integrations will come later and later and there will be less third party libraries. That is why I'm currently learning Go and if anyone asks me what language should they learn first I point them to Python.
This is avoidable by continuing to use Ruby. Just continue to use it and contribute to the community, it's that easy. Ruby still has big businesses using it - Github, Airbnb, Shopify. There is no reason to believe it'll go the way of cold fusion. The language ecosystem is much different than 20 years ago. There are so many languages all thriving. Even Perl is relatively healthy and is a fine choice for doing many things in the software space.
I came out a little bit negative in the end, but as I said I don't think it's going away.
All these companies you listed using it with Rails and that part of the ecosystem is alive and well, but I'm not interested in it.
A few years ago Ruby ruled the DevOps/Cloud space(which I working in), a lot of tools was written in it, but with the dawn of containerization, its former glory starting to fade. Docker, k8s, or even the new GitHub CLI is written in Go. While I am happy to write Ruby code, I can't expect the same from my colleagues.
While professionally I don't think I will continue to use it much longer, I still planning to keep up with it. Before the lockdown, I started teaching Ruby at a local meetup group, and I can't wait for Ruby 3.
IMO Ruby is already being left behind. HTTP/2 is a good example. Rails doesn't support it, and I can't find anything recent saying support will be added soon. Java is notorious for slow innovation yet language level support for HTTP/2 as added years ago and enabled for basically every popular framework. Same with Python, C#, Go, JS.
HTTP/2 is essential if you want good SEO which makes Rails a non-starter for many projects already
That doesn't make sense. AFAIK with frameworks like Rails or Django you never expose their server directly to the Internet, you put a NGINX in front of it. And NGINX talks to the backend code via UNIX sockets, so support for it in NGINX is what matters.
And sooner rather than later you are going to need a load balancer anyway.
That's not really good enough, you will have http1.1 between nginx and the actual server. Many features require actual code framework level support, like server-side push, realtime streams and grpc.
No. Avoid ColdFusion - it's a language from a bygone era when Adobe was trying to be what Microsoft is now. They failed and the ColdFusion community will die. The community, while made up of great people that I am still friends with, by and large was not interested in improving, learning new techniques, or growing beyond ColdFusion. They wanted to learn a skill and cash in on it for a long time. The language is dead and their skills are becoming useless as a result.
Maybe in 15-20 years ColdFusion will become like COBOL or ADA, where there's a bunch of code running some necessary systems and nobody knows how to maintain them. But it's a long bet for a payoff that would be much higher if you spent your time somewhere else.
If you're thinking of learning CF, only do so with the understanding that it's now a niche product mostly used in government and large companies. Learn it either as a hobby or look at the Lucee source for educational purposes. Even my last company is moving away from CF.
About Lucee ...
I actually helped the company migrate away from Adobe ColdFusion to Lucee due to a chance in Adobe's licensing. We migrated a large, 10yr old, application and all clients over to Lucee in about 1 year.
Lucee is a nice platform but I'll warn that it's not as polished as Adobe CF and there's some difference in features. You'll run into rough edges in their documentation and language implementation (especially the scripting languages). One nice thing I really enjoyed was being able to download the source and figure out how my CF code was actually being compiled into Java. It took me a few days to understand the parts I needed but I actually figured out some issues I was having. I also was able to build Lucee from source, just for learning, which was really nice.
> YouTube was (and still largely is) written in Python, way before it was cool and well-known
That's a good point. I wonder how many successful apps used tech that only appeared boring after the fact. Rails is a fairly boring stack today but back when GitHub started, it probably wasn't.
If you know you need to cut a hundred trees to foot-long logs in a certain time-frame, you don't pick the new fancy gadget you just got from Kickstarter. You know, the one with a WiFi notification system and a cloud SaaS service etc.
You go with a regular hand-saw, axe and a proper chainsaw. You'll get your stuff done - on time and on budget. You might not get the thrill of using the latest and greatest tools, but you'll get paid.
After that you can grab the Solar/Hydrogen-powered Indiegogo-funded whizbang and go test in on a tree or two on your own time.
People use "boring" in opposition to "hyped" or "trendy", which like you said totally misses the point. I jumped on react right away when it came out, but not because of it being trendy, but because like you said I could be productive with it right way, I knew it'd be around for 5+ years and that I could hire engineers.
Agreed. I find "boring" to be an unreliable metric for decision-making in software. A boring tool could result in damage to the long term development of software if it is inflexible, for example. Migrations between tools are easily some of the most expensive technical debt costs any software organization may face.
I also agree that the better measurement of good software is that which is unsurprising. Code should be easy to follow, and the decisions for the software tools that are used should be given the same treatment. You should be able to explain your code or infra to most developers without any raised eyebrows. That doesn't make it boring. In fact, it's very interesting when a problem that looks complex on the surface can be solved by relatable means.
It's funny to call Django the "early web" when it first came out in 2005. That is really not early at all. Especially when you consider Rails, etc. predates that.
I was an early Python adopter (1995/1996) and could not for the life of me find anybody who would consider letting me use it in 'mainstream' commercial software projects. Then all the sudden about 10 years ago it exploded in popularity big time.
But I'd moved on to working on other things by then, I no longer enjoy writing in Python.
Wow, this sounds like the classic "I was into that band before they popular" indie snob, hah!
I was using python with SCons back when it came out, sí around 2000. I was also surprised at the statement that python wasn’t well known, but I agree that the Java web scene was much more mature. It was, however, very focused on configuration. There was nothing like LAMP getting people up and running in under a minute.
Rails was popular before anyone ever heard of Django. Rails jobs were already common when it reached 1.0 at the end of 2005 (In early 2006 a law firm offered me $30 to do rails work as a summer job off campus). Django took another couple years before reaching 1.0, though I did do work for some early adopters (0.95) circa summer 2006.
The staples of the early web, in my mind, are html and perl CGI scripts. php might make the cut as early web, but web frameworks, like those in ruby and python, feel to me me much less like the early web, and much more like the web 2.0 days.
Matts Script Archive was mid 90s. Mod perl maybe just squeezes into 'early web', I think /. used it in the late 90s.
Perl wasn't the only CGI in the early days - a large internal web application I encountered as late as 2004 had it's CGIs written in C, running on IRIX
PHP is certainly the newcomer as far as I'm concerned
Like a number of languages, PHP was around for quite a while before it really took off. PHP is probably most associated with "Web 2.0" as it became the model for web interactions in the mid-2000s.
I would classify early web (1.0) as 1993-2003 (pre-AJAX), and modern web (2.0) as 2004-on (post-AJAX). The biggest change since then has been on the backend -- moving from web frameworks in Python/Ruby to Single Page Applications with Javascript backends.
PHP silently transforming all string keys of a map to integers when they are all integer strings ("123", "456" etc.) is exactly one of the reasons I'll never choose a language that pulls the rug from below my feet and replaces it with parquet.
When you are actually coding Java -- yes. But as a sibling commenter pointed out, there's a lot of "XML as code" in the Java world. That's really hard to work with.
I haven't dealt with "a lot of XML" in Java for ages. I've been using it in my day job for a decade, and about the only XML I touch is pom.xml (that's the build file for Maven). This is like complaining about stuff in Java 1.4 -- sure, but we haven't been using it for ages.
Please don't take it the wrong way, but the days of XML for everything are long gone, and for years in Java it's been XML for nothing as a counter reaction.
Your experience doesn't nullify mine, and vice versa. There's a huge pile of legacy Java applications out there still needing maintenance and occasional new features.
You cannot judge a language and platform merely by legacy software. By that token, almost everything today is horribly broken, even trendier technologies like NodeJS or Go. You'd have to judge C by K&R standards, and C++ as the horrible preprocessor it initially was. It makes no sense!
You must judge Java by the developments of the last decade at the very least. Otherwise you're ignoring the practitioners.
Java hasn't used XML in ages and you cannot fault it for legacy apps. You could similarly complain about the horror of EJBs -- sure, but the industry has moved on and acknowledged they were a mistake.
The problem with judging a language by how it was a decade ago is that you're going to be left claiming absurd, outdated things. Imagine if I claimed I didn't like Java because it lacks generics, or because it lacks lambdas, or because I really, really dislike working with EJBs, or because working with Java means "working with a lot of XML" (this would flunk you in an interview, by the way).
Imagine if I complained about Linux and all I used as an argument was the Unix Haters Handbook.
Imagine if I complained about Windows and the most recent version I had used was Windows 95.
That depends on what you want from the judgement doesn't it?
If you want to be able to know the theoretical things you could do with the language, I think your definition is right.
If you want to know the most likely experience you would have using the language, I think mine is right.
I think it also depends on what circumstances you're using the language. Spinning up a new project probably lends itself more towards your definition. If you're looking to join an existing project, mine is probably more useful.
I am judging a technology by its amount of foot guns. That's why I am more fan of languages with only one way of doing things (and even that gets increasingly rare).
Java is a pretty solid tech and the JVM is one of the best runtimes in the world. But it does offer you infinite possibilities to write awful code and that made me less interested in it with time.
I don't disagree with you there are better languages which have learned from Java's mistakes, and I don't think I've argued it's the best one. Just that it's extremely successful, a good platform, and that programming in Java doesn't have anything to do with flinging XMLs like someone claimed.
I am saying that when I was contracting with Java some years ago it was a complete crapshoot: you could get an almost brand new project with a lot of thought put in that made it a pleasure to work on, or you could get an ancient EJB mastodon that made you want to slit your wrists.
And that gamble still exists if you want to contract with Java. A lot of preliminary negotiations have to be done in order not to find yourself in a situation where you should have charged $30k a month due to the insane amount of digging you have to do just to make the thing accept one new feature.
That gamble exists in one way or the other with any tech platform. I double dare you to take on a codebase written with NodeJS, Golang or Python without checking its sanity first. This isn't exclusive to Java.
XML as code can (and often does) work as intended.
It's much less annoying than "exciting" episodes and habits:
- let's see if our SSL certificate has been actually updated on all servers in the cluster
- let's find out what I need to restart after deploying my web app update
- who knows what the classpath loading order will be this time; if it's broken you can try a restart
- finish the test quickly before the sysadmin committee begins an application server upgrade and everything goes offline for as long as it takes, hopefully only a few hours
Not sure how what you said fixes the points you enumerated? XML as code simply wraps other people's libraries in a different DSL and if they have bugs and/or operational complexity, no DSL on top of it will change that.
Java is boring in one sense, but it's the wrong kind of exciting in another. I've had to touch it a couple times in the last few years, and there's still a ton of "enterprise" nonsense in the space. Everything feels bloated, confused, unpolished. It's like I'm walking along, step on a trapdoor, and suddenly am sucked down into a tangle of stack traces, class loaders, annotations, and XML configs.
For me, part of "boring" is being like a 2x4 or a claw hammer: simple, solid, reliable, well understood. A lot of the Java world is nothing like that.
> For me, part of "boring" is being like a 2x4 or a claw hammer: simple, solid, reliable, well understood. A lot of the Java world is nothing like that.
TBH, this is exactly what the Java world is like. There are not many surprises in Java land. The language isn't getting fantasy land changes on a daily basis. There are libraries that haven't been updated in years because there hasn't been a need to update them - they just work. People want to leave Java because it's boring.
Is Java perfect? Of course not, no language is perfect. But, Java is the closest thing to a boring 2x4 the programming world has ever invented.
Java the language is decently boring, (although I appreciate how Kotlin has tried to advance while staying pretty boring). But not Java the ecosystem. When I returned to using Spring a couple years back, I thought, "Well, it was rough then, but I'm sure they've worked out a lot of the kinks." Nope. It had become more complicated and less reliable. I know a lot of Java-land stuff seems fine to people who live in enterprise-land, where people have a very high pain tolerance and no particular urgency around getting things done. But for me that's not the right kind of boring.
Java also seems to bring with it a lot of cultural baggage for bloated design thinking, like needing overkill factory patterns, accessor patterns, and more.
If you start creating something called AbstractMonthlyBillingReportAggregatorFactory that inherits from AbstractBillingReportFactory that inherits from AbstractReportFactory all of which implement a Report interface, things have gone unsalvageably far off the rails to be useful any more.
It’s fair to say you could do this same thing in C++ or Python etc., and sometimes that does happen. But just anecdotally observing this in many companies, it happens _on purpose_ with Java all the time, but much less so in other ecosystems. In other systems it’s just much easier to get things done without resorting to tons of inheritance misdirection, and many great common libraries already solve problems in those ecosystems with minimal inheritance bloat, giving lots of easy to follow examples.
This is true about enterprisey patterns, which for some reason plague Java more than other languages. I think it's a flaw of the moment in time when Java became ubiquitous -- I mean, it still runs most software than many fashionable technologies these days, but it's not as dominant as it used to be -- rather than the language itself. Modern Java doesn't look like that, but indeed older software built with it did.
These are fashions in the software engineering world. Had Ruby dominated the development world at the time Java did, you would have seen the same enterprisey patterns.
I think that’s largely true, but not completely. It just turns out that certain language features sincerely matter more for business software, such as rapidly mutating object & data models without needs to update them as a ripple effect through other designs in the system, and the ability to trade-off safety or correctness as resources just like memory or runtime complexity, which Java as a language is just not set up to do easily.
Maybe my brain is slow today, so please excuse me if this is not what you're saying. Are you arguing that Java is not set up to "do easily" business software or rapidly mutating data structures? Because Java as a battle tested platform has evolved many cool features for exactly those cases. There are even commercial pauseless garbage collectors (and the noncommercial ones are pretty advanced, too). Java and the JVM run circles around many of the technologies that became fashionable later, such as Ruby or the many javascript frameworks.
For an article about "stick to boring and reliable" there seems to be too much push back against Java. I understand the psychological processes involved: stick to boring unless it's the one technology one personally finds unpalatable -- for me that would be COBOL or ColdFusion (and yes, I'm aware Java has been compared to COBOL by proponents of trendier technologies! :P )
A reliance on object orientation as a non-negotiable language requirement is intrinsically antithetical to efficiency for business software.
If a language supports what I would call “lightweight OO” - extremely low boiler plate, zero required OO constructs (purely optional), and language features that render the concept of dependency injection intrinsically obsolete (because mocking can be done purely through introspection at no cost), then that flavor of OO is well suited for business problems.
It has less to do with things like JVM or GC oddities, because those can be straightforwardly engineered around. It’s more about what non-negotiable commitments to specific patterns or strategies come along with the language choice.
Pure functional languages are the worst offenders in this area, which is why their benefits aren’t actually benefits and they are poorly suited for business software. Of the core “industry standard languages” Java would be the next worst offender.
Conversely, I think C# is an ecosystem that suffered the same limitations as Java but found ways to extend and reinvent that make it more attractive now, though still far behind Python, C and C++.
> A reliance on object orientation as a non-negotiable language requirement is intrinsically antithetical to efficiency for business software.
and
> Pure functional languages are the worst offenders in this area, which is why their benefits aren’t actually benefits and they are poorly suited for business software. Of the core “industry standard languages” Java would be the next worst offender.
You seem to be talking out of principle instead of actually having hands-on experience developing large systems in Java. To be honest, it doesn't seem you're familiar with the language or the platform.
I'm not interested in debating your theoretical preconceptions.
Well, it really, really doesn't show. I'll have to take your word for it. I suppose your company is doing badly, since Java is really not suitable for its needs?
You seem likewise uninformed about functional programming and how it has been used to write extremely high-performance fintech systems.
No, mlthoughts2018 doesn't "seem" that way. You have decided they are, and are camouflaging your personal chosen interpretation with false objectivity.
Sorry, I'm even less interested in arguing with what you think of another user who doesn't need your help defending their point.
In any case, that Java's OOP cannot be successfully deployed for business software is counterfactual. Anyone insisting on that point is unfamiliar with Java.
> Which for some reason plague Java more than other languages.
Is the reason a mystery? Java is the language that got a multibillion dollar marketing pitch at its inception. It was designed to be in "the enterprise" from day 1.
I'm not saying it's exactly a mystery. Java had the misfortune of being ubiquitous when XP and design patterns became all the rage. Every intern using Java had to learn "patterns", and schools where teaching them too. Heavyweight frameworks like Spring (and before that, EJBs( were all the rage too. It took a lot to extricate modern Java from that situation.
Yeah, boring vs exciting is a false dichotomy. Early-2000s Enterprise Java is neither - it's intimidating, because the code is so bureaucratic that it's impossible to properly understand the implications of any given action, and bureaucratic software is inherently buggy in my experience because there are so many interactions that inevitably something will trip over an unexpected edge-case of some other thing.
> For me, part of "boring" is being like a 2x4 or a claw hammer: simple, solid, reliable, well understood. A lot of the Java world is nothing like that.
Strong disagree. This is exactly what most of the Java world is like: well understood and reliable. I wonder if people who say things like you did actually use it for their day jobs, or rely on things people using other technologies claim in their blogs.
Wonder no more! Two years ago I did a 9-month contract in Java. I have used Java for consulting gigs going back to 2000. I honestly expected it to be a pleasure to work with this most recent time in hopes that things were usefully boring. That was not my experience.
Java is very similar to C++. Its boring in the sense that most things have been around forever and really old code is terrible but you still have to deal with it because backwards compatibility is so good. If you don't consider Java boring I wouldn't consider C/C++ boring either.
Choose the technology you know in and out, and are immediately productive with.
Choose the technology which is sure to be around in 5-7 years, preferably 10-15.
Choose the technology for which you are comfortable hiring the next 15 engineers.
This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choose exclusively among the top 5 most used in the field.
The key thing here is to avoid surprises, unknown unknowns. You won't have the time to learn from a novice level while building a new company.
A number of wildly successful MVPs were implemented with obscure (or then-obscure) technology which authors knew very well, and which boosted their productivity. ViaWeb was written in Lisp. YouTube was (and still largely is) written in Python, way before it was cool and well-known. The initial Rust compiler was written in OCaml.