
Happiness is a Boring Stack - jasonkester
http://www.expatsoftware.com/Articles/happiness-is-a-boring-stack.html
======
sklivvz1971
Absolutely agree with the article. We do boring stacks at Stack Overflow (we
are proudly a ASP.Net MVC/SQL Server shop) and our performance stats are
pretty damn good.

Our average page is rendered in less than 20ms on cache misses [0] and we do
over a billion page views per month with 9 web servers at 5% capacity. [1]

Sorry but it does get annoying when people suggest we "improve" our stack with
$fancy_new_stack.

[0]:
[https://twitter.com/Nick_Craver/status/790527231600787456](https://twitter.com/Nick_Craver/status/790527231600787456)

[1]:
[http://stackexchange.com/performance](http://stackexchange.com/performance)

~~~
nikon
My product is built with C# .NET too. However I'm not bought into the
Microsoft platform at all. Example: Nancy[0] for REST APIs, Postgres for
persistence (with Dapper[1] of course), ElasticSearch and so on.

Recently turned off my last Windows Server, I've converted all of the services
into docker (mono) containers and making use of Rancher[2] for orchestration.

I am also using Node.js as an API gateway which fits in quite well.

[0] [http://nancyfx.org](http://nancyfx.org)

[1] [https://github.com/StackExchange/dapper-dot-
net](https://github.com/StackExchange/dapper-dot-net)

[2] [http://rancher.com](http://rancher.com)

~~~
caseymarquis
I was under the impression IIS was leaps and bounds better than Linux based
.net web servers. Thoughts on this having experienced the alternatives?

~~~
flukus
Nancy plays a lot nicer with "not IIS". With .net core it seems like IIS is
destined to be a thing of the past anyway.

------
milesf
This what I like to call "both/and". I like both the old reliable and the new
shiny. So often people want things to be "either/or". Either I'm going to use
this solution or that one.

The key is to know the context of each, and I think this article does a very
good job of describing when each ought to be used. He uses the boring reliable
stuff on his own things, because he is beholden to no one and does not need to
justify his decisions. And he also works with the exciting new stuff with
clients, because it is simply easier to sell it to clients who are caught in
the Silicon Valley echo chamber.

Both/And is like trying to hold a small bird in your hand: too tight and
you'll crush the bird and it will die, too loose and it will fly away.

~~~
nxc18
Its interesting to note that there is an inversion here.

You'd think that for one's own enjoyment, the new and shiny would be the
natural choice, while dependable and stable long-term would be reserved for
people who need dependability and reliability long term (a.k.a. Clients).

~~~
ynniv
There is no inversion: new and shiny is what clients want, boring and
dependable is what owners want. In this example he owns the boring products,
and builds the shiny ones.

~~~
gjvc
"new and shiny is what clients want, boring and dependable is what owners
want"

excellent summary.

------
brhsiao
I often hear this sentiment that new languages and frameworks du jour pop up
every week, and that past an age a fellow just wants to learn a single
reliable stack and collect a weekly paycheck.

Am I the only one who just hasn't experienced this feeling? There used to be
Rails/Django and jQuery. Now there's Node and React. Both revolve around
extremely simple ideas. Spend an afternoon reading the React docs, and you'll
know everything you need. Take another afternoon after that and learn Redux.
If you have another few afternoons, learn Clojure, and see what the Lisp folks
have gotten going with reagent/re-frame. There isn't that much to keep up
with.

It's the same with complaints about JS having too many transpiled dialects.
These dialects make life easier. There are good ideas in them. For example,
Livescript is wonderfully concise and elegant, at no cost of readability once
you grok Livescript. It makes your code more readable and faster to write. How
is this a bad deal?

I sometimes wonder if people are just annoyed that they need to learn new
paradigms at all. It's not like ours shift at an especially fast rate.

~~~
taneq
I don't know what age we're talking about, but I'm not as young as I once was,
and I still love learning new stuff.

BUT

If I'm going to invest time in something, it's going to have to pay rent. It's
got to serve some real purpose, to give me something I didn't have before I
learned it. And that rent is going to have to cover the initial investment,
and then some.

Most new web frameworks don't pay rent.

When I was younger I always wanted to make games. I'd spend weeks building a
fancy game engine that would let me make the game... and then I'd burn out,
before ever actually building the game itself. Those game engines never paid
rent, other than what I learned from implementing them. If you're just
learning someone else's API which then becomes irrelevant a few months later,
then you don't even get that payback. You just waste your time.

~~~
mehh
Are you me?

------
clifanatic
Well, I don't know if "boring" is the word I'd use, but I like _transparent_
stacks: if I make a mistake, it tells me where I made a mistake in a way that
I can interpret. All of the "boring" stacks have this property.

~~~
jimbokun
I think this is the biggest selling point for Functional Programming. You know
given these inputs, you will always get the same output.

Even if not using a Functional Programming language, it is good practice to
write your code to follow this principle whenever possible. I think this is
what mocks and unit tests try to achieve, creating a scenario where given
certain inputs, you know what the output will be.

~~~
nikanj
From what I've seen, functional programming doesn't really excel at error
messages

~~~
edgyswingset
Sure it can - here's an example of an error message added to F# which suggests
valid names for Record labels when you've typed an incorrect one:
[https://github.com/Microsoft/visualfsharp/pull/1102](https://github.com/Microsoft/visualfsharp/pull/1102)

Don't confuse correlation (some functional programming languages out there
don't have good error messages) with causation (functional programming
languages don't excel at good error messages).

~~~
reitanqild
Elm is also said to be a good example.

Haven't gotten around to really test it after hello world though but what I
read was somewhat convincing.

~~~
616c
I think Evan is really winning people over with his interest and focus on
that, as I alluded to in my other comment.

[http://elm-lang.org/blog/compilers-as-assistants](http://elm-
lang.org/blog/compilers-as-assistants)

~~~
arvinsim
Elm has the best error messages I have seen by far in any language.

------
moduspwnens14
It's a great point--it just seems arbitrary to draw the line in the sand of
having a "boring stack" that consists of SQL Server and C#.

I mean, that, as a minimum, means you're running and maintaining a Windows
server, along with antivirus, backups for the OS, and backups for the
database. Any time Windows updates come along, your service will be
unavailable. Every couple of years, you'll need to buy a new license, upgrade
Windows, and make sure everything comes up smoothly. This likely will involve
fixing and troubleshooting some issues. You'll need to have some monitoring
set up to make sure you don't end up running out of disk space on Saturday
morning.

Or maybe you have more than one Windows server (to avoid downtime from a
single server), but that makes your stack decidedly less "boring." Now you're
dealing with at least a load balancer and making SQL Server redundant.

I mean, I guess it's more boring than chasing the latest front-end reinvention
or maintaining MongoDB, but there's some room for improvement here, clearly.
Containerized deployments (via Docker or a "serverless" architecture) might be
able to help.

~~~
Pigo
Don't get me started on chasing down NuGet dependency errors. The only
difference is there's usually only one option for any given task. We're
constantly held back by packages with conflicting references. I'm not jumping
everything to Angular 2 just because it's available, but I can build my 1 apps
in a fraction of the time it takes to use my old MVC boilerplate.

~~~
artifaxx
Seriously, good package management makes a huge difference. Long term
maintainability really benefits from a package manager that you don't spend
hours diagnosing obscure dependency errors. I do not miss this aspect of
developing in C# at all, even if it was great otherwise.

------
apolymath
omg this guy is on spot. My day job is Magento (hell), but I am absolutely in
love with boring ol' C#, along with the new ASP.NET Core framework & Kestrel
web server. All of my side projects are built using C#, and I don't use jQuery
or Angular or React or Reactive. I use plain old vanilla javascript, because I
care about zero HTTP requests & zero bloat & zero BS.

~~~
UK-AL
Applications that don't rely on large js frameworks, tend to feel snappier as
well.

~~~
cle
They also tend to turn into huge messy hairballs after years of developers and
new business use cases. Not that these are use cases for personal projects,
but standardized frameworks are valuable for large teams with lots of changing
use cases and long-term maintenance requirements.

~~~
ksk
I don't see any long term stability and support in any JS framework. They seem
to pop in and out of existence at a fairly rapid pace. What examples do you
have of long-term projects that use those frameworks?

~~~
91bananas
[http://backbonejs.org/](http://backbonejs.org/) is my favorite framework. It
doesn't do much, I continue to be impressed with it daily. I'm on my second
major project with it. It's getting old now in JS years (read, actual years).
Doesn't have any steam behind it compared to ember, react, angular. But it
continues to work daily

~~~
mohaine
I hate backbone. Lots of boilerplate and everyone I see a set("field",value) I
die a little inside.

Also, everything of any size I've seen written in backbone turned into an
unmaintainable mess.

~~~
91bananas
What boilerplate? React is all the rage now and it looks a hell of a lot like
a backbone view. It has an initialize function, render, events, some
constants, and the handlers for events. I don't know how much more minimal you
can get than that.

As for the unmaintainable part, I couldn't disagree more. Maybe you've worked
with poor programmers?

~~~
mohaine
Really it is the requirement to to redefine your model in backbone that is a
deal breaker. Alot of code that just don't have to write in other frameworks,
although i understand why it is there.

Most of the unmaintainable comes from it being a lighter weight frame work so
devs often fall back to jquery. This is OK if you can figure out exactly where
they added that trigger. Way to often that is overly hard. It could be pages
away.

And yes, most of my coworkes are poor programmers. Saddly that is the world we
live in and I like frameworks that make them a little easier to live with.

~~~
Tenhundfeld
The issue I've seen with backbone apps, even written by "good programmers", is
that no two are alike. So, when you come into a new app, a nontrivial amount
of time is spent figuring out how the original programmers are using it, which
libraries they pulled in for stuff like model validations, etc.

To be fair, that's somewhat due to the fact that I mostly encounter them in
consulting arrangements, and I don't know that any of the other frameworks are
much better in this respect. I think I've just gotten spoiled by doing most of
my work in Rails, a mature opinionated framework.

------
mixmastamyk
I agree in general but why would you use Windows/SQLSrv for internet-based
products? I'm fine with it on the desktop, but the extra costs and time
devoted to things like activation are a non-starter as far as I'm concerned. I
believe they finally have ssh and package mgrs available, but don't you still
have to install them manually?

There's plenty of boring stacks on Unix that are free, in both senses of the
word.

~~~
rpeden
Because it performs well, and the cost of Windows licenses ends up being a
rounding error if you have paying users. I've administered Linux boxes for
years, and while I enjoy it I find Windows Server more enjoyable to work with
in many cases.

SQL Server licensing is another story. It is expensive, but I've also seen it
handle heavy workloads on modest hardware without complaining. Though I don't
doubt the same is true for Postgres and MySQL/MariaDB/Percona. From what I've
seen, the constellation of reporting and BI tools around SQL Server are what
make it appealing to enterprises regardless of cost.

~~~
bad_user
Windows being a rounding error is kind of a myth perpetuated by people that
haven't been in the position to buy Windows licenses for a company.

First of all most software developers are not working in the consumer space.
And for B2B you often get asked to have an on-premises option, either because
the company doesn't trust you with their data, or because non-stop Internet
connectivity can be a problem. And when deploying on-premises, the cost of the
Windows licenses do matter a lot.

If the clients are just web browsers then you can save the company a lot of
money, since the clients can be just terminals powered by whatever you can get
your hands on. But if you assume Windows clients, well, the costs can be huge.
And on the server side, remote maintenance is way cheaper with Linux boxes,
because well, you can control anything on a remote Linux machine, securely,
reliably and for free. Add to that the licensing cost of Windows, which isn't
cheap because you can't run a server on Home edition.

Basically if your solution assumes Windows in any way on the customer's side,
you're just adding unwanted cost that could have been your profit. And SQL
Server is simply unjustifiable.

~~~
UK-AL
Considering most boring corporates run windows as their main server OS, I
think it be an easier sell to run windows for on premise applications.

~~~
bad_user
In my experience dealing with boring corporations, that's another myth. Yes,
they run Exchange. But all new developments I've seen happen on Linux boxes,
precisely because it's easier to outsource IT.

~~~
rpeden
Perhaps it depends on how boring/conservative the corporation is. At a past
job where we worked with big banks, they'd sometimes look at you suspiciously
if your application _didn 't_ run on Windows Server.

That's just anecdotal, though. Maybe we were just unlucky and worked with odd
customers.

~~~
UK-AL
No. It's not odd.

The vast majority of corporations have an IT department who's main skill is
windows management. And for good reason.

There still lacks a decent Active Directory/Group Policy/ Exchange open source
combo.

------
rpeden
Jeff Atwood made similar points in _The Magpie Developer_ :
[https://blog.codinghorror.com/the-magpie-
developer/](https://blog.codinghorror.com/the-magpie-developer/) and _Why
Ruby?_ : [https://blog.codinghorror.com/why-
ruby/](https://blog.codinghorror.com/why-ruby/)

Not that chasing after the latest and greatest is always a bad thing, but
sometimes existing (and relatively boring) tools are the best ones for the job
at hand.

~~~
zengid
From "why ruby":

>Ruby isn't cool any more. Yeah, you heard me. It's not cool to write Ruby
code any more. All the cool people moved on to slinging Scala and Node.js
years ago. Our project isn't cool, it's just a bunch of boring old Ruby code.
Personally, I'm thrilled that Ruby is now mature enough that the community no
longer needs to bother with the pretense of being the coolest kid on the
block.

This is my feeling right now. Nobody is yelling about Ruby so I can take my
time and enjoy learning it at my own pace.

------
libeclipse
This is how I feel. I have friends that are always going on about all the
latest "best practices" and cool hipster stuff like docker swarms and
microservices. Meanwhile I've kept my own projects using boring old (or rather
tried and tested) technologies and languages like python.

I don't like it when people are recommending new buzz words every week.

~~~
matt_wulfeck
Unfortunately the new buzz words of today are the boring stacks of tomorrow.

I would say that containers represent a greater leap forward in thinking than
a new programming language. Like it or not your future applications will run
in a linux container.

~~~
VodkaHaze
> Unfortunately the new buzz words of today are the boring stacks of tomorrow.

Bullshit.

SOME of today's buzzwords will be boring stacks of tomorrow. But unless you're
a some sort of oracle, chances are you won't be able to pick which are today,
for the same reasons you shouldn't try to beat the stock market.

~~~
dasil003
I don't think it's that hard to pick promising tech to explore once you have
some experience under your belt. For instance, containers are super
interesting to me because they directly address a lot of the pain points with
dev VMs or native development. It may end up being the case that Docker does
not win this battle, but it's also clear there is some meat to this hype and I
will profit from learning about it even if the landscape shifts dramatically
before it stabilizes.

~~~
takeda
To me you're proving his point. Containers are new hip thing right now, but
it's huge amount of work to productionalize them. There are so many solutions
and all of them have drawbacks. Seeing how things are going, most likely it
won't be docker in the end, so the amount of effort you spent on it won't give
you any edge.

From my observation it seems like docker ultimately is ending being used as
another package mechanism.

~~~
dasil003
I don't see how you take it that way. Experience with containers will be very
valuable over the next decade, and anyone with experience will have an
advantage over someone with no experience. There's not one binary moment where
all of a sudden technology X is mature and stable. Docker has been around over
3 years, and the underlying technology many years before that. Although Docker
is having trouble on the orchestration side, the container format is quite
ubiquitous already, so I'd say it's highly unlikely that Docker will
completely disappear in the medium term. Finally, it's not all or nothing,
Docker solves a lot of problems today in certain configuration, you don't even
necessary have to productionize anything as it's quite useful in purely dev
scenarios. Even in a worst case scenario where Docker becomes completely
irrelevant, you've learned something about what works and doesn't work with
containers.

There's obviously a choice where you want to pick things up on the adoption
curve, so maybe you're more conservative than me, but my underlying point is
that it is possible to find a balance and you can still advance your skillset
even if you pick something that doesn't necessarily stick around for the long
haul.

------
tikhonj
It all depends on how you define "boring":

• If you mean "familiar" then you're right: something you know is better than
something you don't. (But it's not the way to learn or expand your horizons.)

• If you mean "stable" then the whole thesis is a bit of a
tautology—crucially, there's no fundamental contradiction between "new and
shiny" and "stable", and "boring" stuff is often _also_ unstable/insecure/bug-
prone (think PHP or C).

• If you mean "popular" or "mainstream" then you're putting _way_ too much
stock in the judgement of crowds. Crowds and fashion are fickle and the
popularity of a product is a poor indicator of _any_ intrinsic qualities.

I've seen people using all three of these definitions—and linear combinations
thereof—when talking about these things. More too, probably.

I think it's important to separate them out exactly what you mean by words
like "boring" or "practical" when talking about software tools and
abstractions to understand exactly what's going on and to communicate clearly.

~~~
owdadithurts
Maybe "stable" was the wrong word. Perhaps "proven stable" would be better.
It's not that "new and shiny" can't be stable, it's just that it hasn't proven
itself stable yet. It hasn't been around long enough to prove it. So it's more
using technology that has over a decade of proven dependability, over
something that may or may not be.

~~~
cutler
Elixir, Clojure and Scala cut across this distinction. They're very new and
shiny but built on proven technology. In that sense maybe they're a better bet
as they definitely bring something new to the table and help solve hard
problems. I think Clojure suffers most from this familiarity bias as I'd argue
it's at the top of the excellence tree despite being largely ignored by an
industry forever wedded to C# and Java.

~~~
kod
It's been over 12 years since Scala 1.0. I've been doing Scala full time for 7
years. It's not new and shiny.

------
intrasight
I've flipped-flopped back and forth several times over the last 15 years on
the question of server-side vs. client-side view logic. I literally start each
new project with a new technical review and evaluation of this question.

I'd have flipped permanently to client-side if the quality and consistency of
the JS stacks were of the same quality as the server-side stacks (I use
ASP.NET MVC). I know that it has been a rapidly evolving thing and hence the
churn. But here's the thing - with software I've come to prefer intelligent
design over Darwinian evolution. On the server-side we have intelligent
design; on the client we have evolution. On the server, we have stability and
a roadmap. On the client we don't.

With that said, painting pages on the server to send down to the client just
doesn't smell right anymore.

~~~
majewsky
> With that said, painting pages on the server to send down to the client just
> doesn't smell right anymore.

Can you elaborate on that?

~~~
intrasight
By that I mean that we should have moved cleanly beyond that by now with no
regrets.

Certainly it comes from my time in the '80s and '90s developing "desktop"
software (of course we didn't call it that)on Unix and Windows. There were
user interface objects that had behaviour. Once we "got" that HTML and
JavaScript could do similar, we make the browser into the new windowing
system. But unlike the Windows and Unix desktops of old, which had "official"
SDKs and libraries, it was the wild west. Fifteen years later it still is.

If fifteen years ago you had said that one starts a new project by running a
command-line script that would clutter your project with hundreds or thousands
of tiny source files from sources unknown, we would have laughed at the
absurdity.

------
ohstopitu
I personally enjoy the new & fancy. Infact, I try the new stuff because I
enjoy trying it out, and the "gotcha" moment with that happens when you
understand the stuff.

That said, If I had to choose a tech stack for work, I'd choose something that
I am comfortable with and something that I know a lot about (compared to the
rest of the stuff available) - because in the end, it's not about having new
and shiny so I can blog about, but to solve the problem that my company is
facing/trying to solve.

~~~
nine_k
There's an important difference: the new and shiny _may_ be something that
increases your productivity. The increase may be so big that it outweighs the
risks of it not being mature or well-known enough.

See Paul Graham's essay on Lisp as a secret weapon. There were a number of
now-popular "secret weapons", most way less elegant than Lisp (e.g. Rails),
used exactly because they made your product's time to market much shorter.

Getting to the market quickly, while an opportunity still exists, is one of
the most important problems any company is going to solve. Operational
excellence may take a back seat compared to it.

~~~
bbcbasic
My counterargument is when rails came out PHP was just as capable of letting
you knock stuff up quickly and meeting the business goals for a startup.

Where rails excels I think is at shops that need to pump out different
websites for different clients so that continually starting over cost is
minimised.

And Lisp is old tech.

~~~
nine_k
Rails, like all opinionated frameworks, gives you a great head start for a new
project, as long as you follow the prescribed project structure. (It starts to
feel worse as you grow and hit the restrictions of the baked-in assumptions.)

Lisp is not "old tech"; Lisp is timeless tech. Like, well, math. BTW, Unix is
also rather old, but still does remarkably well, and gave a distinct edge to
its users since ~1990s when Linux and FreeBSD became viable server platforms.

~~~
bbcbasic
I meant old in a nice way :-). As in been around a long time.

And timeless sure, although I have never written any lisp, maybe I should.

------
rch
In other words: 'When you have the option, use the stack you're most
comfortable with'.

~~~
bunderbunder
It's not just comfort, it's that stuff that's been around the block a few
times tends to fall into one of two categories: Stuff that's solid and stable
and not very fussy, and stuff that nobody uses anymore because it's a PITA.
That makes it pretty easy to make good technology decisions.

Newer technology tends, almost by definition, to be very experimental. And
experimental means, almost by definition, that some ideas are going to work
out and others aren't. Oftentimes it takes a while to figure out which is
which. And popularity, even extreme popularity, tends not to be a good proxy
for robustness - if anything, it's a source of noise that only makes it harder
to figure out what's robust because hype tends to be a pretty darned
autoregressive process.

~~~
amorphid
I find Elixir easier than Ruby and Javascript, one you figure the actor model,
dialyzer, and reading other people's macros.

------
arthurread
I agree. Kind of. You get to choose the kind of problems you work on, and the
way you break up your time. If you want to innovate on the infrastructure, if
you find that interesting or if worth the gains for the kind of scenarios you
work on then go for it. At the same time focusing on solving problems in the
programming infrastructure, spinning cycles learning new techniques means you
get less time actually solving problems in your actual problem domain. You
don't need a $3000 carbon fiber road bike to get to your friends house down
the street, no matter how many articles you read about how good that road bike
is. I suppose the idea is use the most boring stack that can get the job done.

------
sarreph
I've been thinking a lot about this recently.

I'm in between jobs and thinking of starting a SAAS on the side in order to
support my goal to go backpacking for a few months next year.

However, the amount of microservices I'm thinking of putting it all together
with means it'll require a decent amount of non-automatable (as far as I can
tell) maintenance and attention. This isn't exactly what I want at the back of
my mind all the time while travelling... but then again, you can't have all
your cake and eat it.

Anyone who has a successful hands-off SAAS built on a modern stack care to
chip in on ways of mitigating this?

~~~
brightball
Elixir is a solid solution for this. You essentially write micro services as a
monolith that runs on the BEAM VM and naturally spreads across a cluster
([https://elixirschool.com/lessons/advanced/umbrella-
projects/](https://elixirschool.com/lessons/advanced/umbrella-projects/)).
It's all message passing without shared memory so whether you're sending
something to a different function, process, processor or machine in a
different datacenter your code doesn't really care. As a bonus you don't have
to define REST/SOAP/Protocol Buffer interfaces for every single microservice
you're writing...since it's just function calls.

Everything works smoothly and efficiently just like boring Erlang has for
decades, with some readability and productivity perks that Elixir gives you.

Elixir sounds trendy and new, but it's just modernized Erlang. It's older than
Linux.

~~~
amorphid
I <3 actors & immutability. I didn't understand what "easy to reason about"
meant until learning Elixir.

~~~
cutler
Yes, I loved Elixir as soon as I set eyes on it. However, as far as "easy to
reason about" goes, Clojure in an Emacs CIDER repl is about as good as it
gets.

------
leothekim
Some interesting thoughts on a similar sentiment: [http://mcfunley.com/choose-
boring-technology](http://mcfunley.com/choose-boring-technology)

Nice takeaway: "The nice thing about boringness (so constrained) is that the
capabilities of these things are well understood. But more importantly, their
failure modes are well understood."

------
dahdum
"It seems like on a lot of stacks, keeping the server alive, patched and
serving webpages is a part-time job in itself. In my world, that's Windows
Update's job."

I imagine the Linux alternative of this would be Debian with unattended-
upgrades and a PHP app.

~~~
icebraining
Sounds about right. I run Tiny Tiny RSS with Postgres and Nginx on Debian
Stable and I can't remember the last time I've had to spend time administering
it. (I do update TTRSS itself manually, but since it's behind Nginx's basic
auth, I don't feel rushed to plug security holes).

The truth is, as shown by data, that downtimes is usually caused by
developers, not stuff crashing by itself.

------
bootload
_" Good old C#, SQL Server and a proper boring stack and tool set that I know
won't just up and fall over on a Saturday morning and leave me debugging NPM
dependencies all weekend instead of bouldering in the forest with the kids."_

Microsoft tax.

Yes you can get alternative C# implementations [0] but SQL Server? Having to
deal with _" MS Tools"_ in an era of high quality alternatives? Boring for me
would be Perl/Postgres, both in their 20's, solid, reliable, with plenty of
quality developers and language support.

[0]
[https://en.wikipedia.org/wiki/C_Sharp_%28programming_languag...](https://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29#Implementations)

~~~
staticelf
At my last job the backend system was mainly written in Perl, finding
developers was nearly impossible. Of course, it may have to do with the fact
they paid less than other companies and did not allow remote work.

------
elliotec
This is my feeling about Rails. I've created several Rails apps that delighted
the customer, and most have required literally zero maintenance after years of
use.

Sprinkle in a bit of jQuery and you have an app that is stronger and just as
fancy-feeling as a mess of a massive client-side app.

~~~
cutler
I think the improvements to turbolinks in Rails 5 make pjax more of an option
now. Also, for scaling remember it's not the end of the road for Rails when
you're running out of processes to keep up with requests. JRuby 9000 has been
gathering a lot of momentum recently and promises huge performance gains when
Truffle and Graal kick in. Migrating a Rails app to JRuby is not that
difficult.

------
jsingleton
I really like C# and .NET as a stack, just like the OP. It may not be cool but
it works well and they are good skills to have for stable employment
prospects.

The new .NET Core stuff is looking very promising too. I really hope it takes
off, and not just because I have a book out on it :).

~~~
aswanson
On top of that, it has a powerful, well-documented IDE and support community.
It is what it is. I love to experiment with new stacks and paradigms but if I
want to Get Shit Done, nine times out of 10 Im going with older tools.

------
bbcbasic
If you are doing a side project you can choose between solving a real problem
or learning new tech. It is hard to do both simultaneously in the time that
most people give to side projects. Hell its hard even if you are full time.

Learning new tech in a side project is a worthy thing to do and I have built
some nice little toy Haskell, Elm, JS and Java projects.

However I am more productive in my usual C#, so if I wanted to get something
done quick e.g. an MVP website, I'd probably that would be the best choice
despite the advantages of other languages. E.g. PHP -> cheap shared hosting,
easy to deploy, Haskell -> Excellent type system, find most bugs at compile
time, etc.

One exception is I recently want to scrape the HN Api sequentially with
multiple requests at a time, and I found this easier on Node.js than C#,
because I could be sure I wouldn't get exceptions saying my threadpool has run
out of threads etc. :-)

------
drather19
I like the point about building systems that take care of themselves and are
largely hands-free. I'd say that applies regardless of platform (or
"shininess"), though. The author has clearly internalized one of the more
important lessons in engineering in terms of designing for maintainability
(with an ultimate goal of zero/low-effort maintenance and/or extension).

I'm not sure the platform itself is as important to achieving this goal so
much as the decision-making ability of the engineers themselves, though. Maybe
a tendency to pick shiny because of shiny is just a way that poor decision-
making surfaces? However, I don't see a problem picking an appropriate
solution that happens to be shiny.

Anyways, kudos for sharing the wisdom.

------
qaq
You can have both happiness and an interesting stack a good example of this is
Elixir or I would guess F# in the .Net world.

------
EugeneOZ
MS SQL Server is so awful crap, you can just try any another DB to see that -
I can't trust this author after "good old SQL Server". And I don't see nothing
except boring oldman grunting in that article. Programmers should always learn
and they know it from the beginning of their way.

~~~
mrweasel
I never push SQL Server to hard, but it have always been stable and extremely
well documented. It's certainly better than MySQL in many respects.

Would you mind sharing a bit about how SQL Server has failed you? I would
genuinely like to know, maybe there's some use cases where I need to at least
be careful about picking SQL Server.

~~~
EugeneOZ
For example, try to work with UTF-8 strings - concatenate them, compare their
parts. And it's just one aspect - there is a lot of them.

------
ungzd
Maybe yes, when you work at bank, change 1 line of code per month, documenting
this change in 10 Word documents, most of time drinking coffee and sleeping
during Powerpoint presentations with 1000 attendees.

~~~
crpatino
You are not being paid to change 1 line of code per month. You are being paid
to be a living repository of institutional knowledge: so you (can) know (in a
finite, bounded time) what line to change in order to achieve the business
requirement, and what dozen-or-so Word documents you need to read in order to
confirm which unintended consequences may result of that change.

That said, sleeping during massive presentations will hinder your abilities as
a living repository... so, hang in there and keep pouring-in the coffee.

------
jon49
F# is an amazing language on the .NET stack that is strongly/statically typed
but will infer many of the types. It has TypeProviders which let you strongly
type your external code sources (FSharp.Data.SqlClient is just amazing -
statically typed SQL directly in your code!). Unions/Discriminated Unions,
units, etc.

Much cleaner than C# with all the .NET goodness!

------
Animats
I agree. A site I run:

    
    
        Server status at 2016-10-25 12:07:41
        System status: Database up for 419.94 days.
    

It's Python and MariaDB.

~~~
majewsky
So you're not doing any important kernel updates?

------
dsolin
Totally agree, but I remember the (childish) excitement of using the new,
shiny, "cool" stuff. And then the satisfaction of snorting at the soon-to-be-
released .NET Framework. And not to talk about that Java-rip-off of a language
that would come with it!!! Oh those were the days... I am a C#-developer
today, but don't tell anyone! ;)

------
qwertyuiop924
It depends on if you like the boring stack, and also what your normal stack
is. If you mostly write ruby, Sinatra or Rails should be your first port of
call: they're widely used frameworks in your language.

But no, don't go for the zeitgeist for no reason: zeitgiest is tautologically
new, and new stuff tends to break a lot.

------
pjmlp
It also resonates with me.

I play with all sorts of programming languages, specially on those long winter
nights.

When it comes to production code it is all about the Java and .NET stacks,
with some C++ only when there is a need to integrate some sort of native
library, or call the respective VM APIs.

Even then I can usually sort it out with JNA, P/Invoke and RCW.

------
sdegutis
Fully agree. We're moving our work codebase from Clojure to Java. It's true
that Java is boring and old and simple. That's what makes it great! Now we can
focus 100% of our efforts on the business logic rules. (Granted, sometimes I
wish we were using C# instead. But only sometimes.)

~~~
ungzd
Clojure is real boring stack. No abstract singleton proxy factories, just
plain scripting. I have web application in production using plain Ring API,
without frameworks. Like good old days of CGI and PHP but more sane.

~~~
edwinnathaniel
> No abstract singleton proxy factories

I barely see this in the code that I wrote given that I've been writing Java
code for ... 8 years? (unless you're writing Spring framework itself)

Can we please drop this?

~~~
kelnos
> Can we please drop this?

I would love to agree with that, but I don't think we can. I've been writing
Java (well, more recently Scala) for 14+ years, and I still see otherwise
great programmers succumb to Java class-itis.

~~~
lacampbell
I see a lot of bad C# code, but I don't feel the need to make snide comments
about C# whenever I see or hear it mentioned. It's pretty clear to me it's not
the languages fault.

There's nothing in Java forcing you to make deep class hierarchies or leaky
abstractions.

~~~
kelnos
Nothing that _forces_ you, sure. But when you have a culture following that
language for so long that encourages that, and have existing 3rd-party
libraries and an ecosystem that makes it easier to do that... well, that's
what happens.

Not sure about the GP of my original comment, but I'm not trying to be snide;
I just _see_ it everywhere, and it really frustrates me. I _don 't_ see it
with Scala/C++/python/ruby programmers, so what's the common denominator? The
language.

------
sunstone
I totally agree with the philosophy but for me it's Django, python and
postgres on ubuntu server.

------
draw_down
"Boring" meaning "a lack of surprise", sure. "Boring" as an antonym for "what
the cool kids like", no. Plenty of unfashionable technologies are that way for
reasons.

------
jupp0r
There were times when .NET was the new and shiny (it arguably still is with
the recent open-sourcing and stuff going on in F#). I wonder if it was back
then when the author started to use it :)

~~~
frogfuzion
Nice. I remember when I was begging my manager to switch from our classic
ASP/JScript/MS SQL/Java Applet stack to .NET and he refused saying that it was
not mature enough. Good Times.

------
josep2
This is a refreshing take, although maybe extended a bit too far. It seems
like this kind of thinking is mostly in the real of software on the web and
not necessarily on the systems side of things.

------
sly010
Agree. Things like Docker and microservices architecture are solutions for
problem you have only if you are playing with more "interesting" stacks.

~~~
UK-AL
Tbh we use an NServiceBus(.net) microservice stack, and it's been pretty
boring and uneventful for us.

------
bbcbasic
.NET also suffers from the image problem of the anti micro$oft, anti-IDE,
anti-not-open-source sentiment.

~~~
flukus
It's been open source for several years now. It's more open than java, android
and many high profile OS projects. They've also decoupled intellisense from
the IDE, meaning any text editor like vim can get the same features.

------
lmm
Low maintenance is important, but so is functionality. It's frustrating to
have to fix code that was working and gets broken by some update, but it's
even more frustrating to have to copy/paste code because your language doesn't
have the abstraction facilities that let you factor out the commonality.

~~~
edwinnathaniel
> but it's even more frustrating to have to copy/paste code because your
> language doesn't have the abstraction facilities that let you factor out
> commonality.

I find this statement to be less of a problem in many modern programming
languages (or greatly exaggerated by a specific language fan when comparing
his/her preferred tools vs "the other languages).

~~~
lmm
I think in higher-kinded types these days, and can't stand to use a language
without them (where I necessarily end up copy-pasting). There are plenty of
modern languages without that.

I've only had to copy-paste code because of Scala's lack of support for
polykinded code a few times, but it was very frustrating every time. Hardly
any languages, even modern ones, support that.

------
nstj
What a wonderful article. Bravo.

------
SadWebDeveloper
tl;dr Full JS Stack Engineering sucks.

------
matchagaucho
C# and SQL I might agree with. But ASP.NET and MVC = stable?

All the hidden view state and POST backs to re-render the UI... _terribly_
difficult to troubleshoot and support in my experience.

~~~
UK-AL
That's ASP.Net WebForms which is basically very old and legacy.

~~~
pjmlp
I wish.

Even this year I was getting some SiteCore requests, which I didn't accept,
but version 6 was largely built on top of forms.

I haven't bothered with it since version 6, so I don't know how well it has
moved into MVC world.

~~~
yareally
Seconded. Sadly, our tech stack at work still includes some webforms cruft and
I have a few friends at other companies that also still have to deal with
them. Could be worse I guess...I know someone that still has to put up with
classic ASP.

Thankfully I work with backend stuff at my job currently or I'd probably go
crazy dealing with a mishmash of mvc and web forms. Webforms are not super
easy to get rid of if you weren't careful on how you coupled to them, so I
think some code is still being added to ours.

------
bluejekyll
> Good old C#, SQL Server and a proper boring stack

And? What is the proper boring stack for targeting a browser? The reason React
is so popular is because it answers a fundamental problem of application
delivery to the browser client.

If you're living in C# land that's not always boring either, as soon enough
you have a GC nightmare.

I agree with everything in this article in principle, but it fails to leave
room for innovation, where innovation is necessary.

And an MS stack when 80% of the world deploys to Linux on the serverside. You
might be stuck in the wrong decade...

~~~
vlunkr
I like React, but it's delusional to think you can't target a browser without
it. I mean, we lived without front end frameworks for a loong time before
that.

~~~
bluejekyll
I'm not saying you can't target a browser without it, I'm saying it answers a
development problem of having rich applications built on the clientside.

~~~
blakeyrat
1) We had those before React.js and all the modern JS frameworks

2) A lot of people don't like having "rich applications built on the
clientside", because in their experience that means buggy, broken applications
that never work quite right and often break the scrollbar and back button.

