Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choose Boring Technology (2015)

mcfunley.com

Post reply on HN
Print view View original

241–250 of 297 posts

Re: Choose Boring Technology (2015)

#241

Post by rooam-dev »

darkwater wrote: post #59
rooam-dev wrote: post #43

Boring tech is subjective, it depends on the team. A tool for the job needs to be in right hands to be right. Some may be fine with 1 hour after hours deployment, some may want a fully automated CD pipeline.

Nope, boring technology implies mature and tried enough ecosystem where the users community found out and know almost every failure scenario. Your team skills are not relevant in this definition, if a tech is "new" and "exciting".

Indeed, team's experience is not relevant in the definition, however it's the main criteria to choose a [boring] tech, after the cost of course.

To use/apply any tech or workflow depends on execution.

Re: Choose Boring Technology (2015)

#242

Post by the_af »

mlthoughts2018 wrote: post #223
the_af wrote: post #191

Earlier quoted context omitted.

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 r…

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 introsp…

> 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.

Re: Choose Boring Technology (2015)

#243

Post by m463 »

MattGaiser wrote: post #26
m463 wrote: post #21

Earlier quoted context omitted.

It makes perfect sense if you want to work for Elon Musk under the streets of Hawthorne.

If you are doing firmware development, sure. If you check out their full stack development jobs, they want Go and TypeScript. https://boards.greenhouse.io/spacex/jobs/4747757002?gh_jid=4...

ha, I was referring to "the boring company"

Re: Choose Boring Technology (2015)

#244

Post by rubber_duck »

leonardteo wrote: post #184

Getting vulnerable here for a sec and hoping that others can add their thoughts. I struggle with this. As a small-ish, bootstrapped business, the issue I commonly run into is developer retention. If we stand our ground and choose boring technology because we have limited innovation tokens and can't afford to waste them, there's the flight risk of those devs who really want to work with those new technologies. And thi…

I'm against letting juniors or random devs introducing stuff you don't want to maintain in to your codebase for the sake of using the latest fad tech, chances are they will leave anyway and you will be left holding their mess. If they know what they are doing (ie. you hired someone with experience in stack Y and they want to help you migrate) then I'd say go for it if you can afford it. But picking a "safe but boring" stack puts you in the same hiring pool as everyone else picking that stack - can you compete on other terms to attract employees ?

Let's say you decided to write a webapp a few years back when RoR and AngularJS/CoffeScript was the popular stack. You wanted to write it in Clojure but you though "I can't hire Clojure devs reliably and RoR is popular so let's go with that". You are a small business/not high growth - you grow your app steadily - you now have a sizeable codebase on a legacy code stack that nobody really wants to touch or learn, there are plenty of job openings on that stack you have to compete with. Meanwhile people enthusiastic about Clojure were probably above average developers who would be happy to take below market rates just to work on a stack they enjoy and you could easily find people even today.

In a market where demand outpaces supply I'd say the "safe stack" is not a correct choice for small companies - if you have the know-how to pull off something more cutting edge. If you don't then ofc. use what you can to get the job done.

Re: Choose Boring Technology (2015)

#245

Post by mlthoughts2018 »

the_af wrote: post #242
mlthoughts2018 wrote: post #223

Earlier quoted context omitted.

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 introsp…

> 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…

I work in a company whose core systems are all written in Java, I deal with modern Java every day.

Re: Choose Boring Technology (2015)

#246

Post by polytely »

randombytes6869 wrote: post #117
AmericanChopper wrote: post #68

Earlier quoted context omitted.

Whether you end up with a hellish dependency tree is more up to the developer than the language. I’d say the only reason this is more common in node projects than it is in other languages is because dependency management in other languages is more tedious, so the barrier for introducing new dependencies is higher. All of my node projects have had rather tidy dependency trees. It’s also been quite easy for me to use p…

Trust me, its the lack of standard library. Python and Java are both "batteries included" . You can write apps decently with just 5-10 dependencies if you want. Every JS app I've worked on has like 10-20X the dependencies of projects written in languages with a good standard lib

Totally agree, I'm currently learning Elixir and it has been such a delight to work with compared to Javascript. I'm writing a simple static site generator and I've not used any external libraries yet, because everything I've wanted to do thus far has been easy to build with the functions included in the standard library.

Re: Choose Boring Technology (2015)

#247

Post by the_af »

ByteJockey wrote: post #227
the_af wrote: post #192

Earlier quoted context omitted.

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…

> You must judge Java by the developments of the last decade at the very least. Otherwise you're ignoring the practitioners. I think plurality of situations it's actually used for currently would be a better standard than what you're advocating for. This has the advantage that the merits people judge things on, and the experience they will most likely have using it will line up. The downside is that, the merits used…

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.

Re: Choose Boring Technology (2015)

#248

Post by the_af »

mlthoughts2018 wrote: post #245
the_af wrote: post #242

Earlier quoted context omitted.

> 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…

I work in a company whose core systems are all written in Java, I deal with modern Java every day.

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.

Re: Choose Boring Technology (2015)

#249

Post by ma2rten »

namelosw wrote: post #77
nine_k wrote: post #62

I still think that "boring" is a wrong word. 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 choo…

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 wa…

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.

Post reply on HN