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

271–280 of 297 posts

Re: Choose Boring Technology (2015)

#271

Post by jp_sc »

randombytes6869 wrote: post #256
derrekl wrote: post #157

Earlier quoted context omitted.

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

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

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.

Re: Choose Boring Technology (2015)

#272

Post by scottlocklin »

dahauns wrote: post #202
scottlocklin wrote: post #153

Earlier quoted context omitted.

> Trust me, its the lack of standard library. It's almost certainly not, as R has plenty of batteries, and young nitwits in the Hadleyverse are writing preposterous node-like dependency graphs. It's fashion, and it should be curb-stomped.

I don't see how R of all languages is a useful counterexample. It's as far a way from a general-purpose language as it can get while technically still being one, in both scope and intended use/audience.

It's a useful counterexample because the problem didn't exist for the 20 years before legions of nodejs bros descended upon it and bestowed upon us the mess of hot garbage it is today. At this point, there is an entire half of the ecosystem which is unusable unless you drink the 400 dependency kool aide.

Re: Choose Boring Technology (2015)

#273

Post by ClumsyPilot »

jp_sc wrote: post #271
randombytes6869 wrote: post #256

Earlier quoted context omitted.

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

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.

Re: Choose Boring Technology (2015)

#275

Post by dumdaar »

pydry wrote: post #224
w7 wrote: post #206

Earlier quoted context omitted.

I'd honestly consider Golang "excitingly boring". 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.

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). Tech like postgres doesn't get that kind of hype.

>Pretty much anything Google releases is coated in magic pixie fairy dust

Dart didn't make any impact till flutter was launched.

Re: Choose Boring Technology (2015)

#276

Post by nine_k »

w7 wrote: post #206
pydry wrote: post #135

Earlier quoted context omitted.

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

I'd honestly consider Golang "excitingly boring". 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.)

Re: Choose Boring Technology (2015)

#277

Post by mbrodersen »

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…

Be happy to see them go. They are the wrong developers for you to employ. Their focus is all about self-indulgence and not on creating a viable long-term business. Don't ever hire anybody who calls them self a "ninja developer" or equivalent. Instead, ask them to send in their CV again when they are grown up.

Re: Choose Boring Technology (2015)

#278

Post by mbrodersen »

tomc1985 wrote: post #221
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…

Can I be honest? I fucking hate developers. We're like magpies of the worst variety. How many times have I had to argue against bringing in ${NEW_TECH} or ${NEW_TECHNIQUE} because it would be more trouble than its worth. No, it doesn't look as cool engineering-wise, and yes, our work may be a little harder because of it. But then they win the argument and we implement it and hey! Those problems I told you about? They…

I am thinking it but not saying it out loud :-)

Re: Choose Boring Technology (2015)

#279

Post by mbrodersen »

speedgoose wrote: post #67
choeger wrote: post #51

Earlier quoted context omitted.

You basically have arrived where lisp was some decades ago. Logical next steps are to write the OS and the editor and the VCS in JavaScript. However, at some point you will have a look into your myriad of nodejs dependencies and see with horror that they rely on C++ extensions. Then you learn that your precious stack is just a GCC upgrade away from not building anymore. And noone in your company even remembers what t…

If a NPM package requires a C++ compiler, I ignore it and move on.

V8 (and other Javascript JIT compilers) are written in C++. Whenever you think you run Javascript code, what you are actually running is C++ code that will emulate and compile your Javascript into machine code, update the DOM with C++ code, access sockets using C/C++ code etc. all running on an OS written in C/C++. Your code is a very small percentage of the code that runs "your" application. C/C++ runs the world. Including Javascript, Python, Java etc.

Re: Choose Boring Technology (2015)

#280

Post by speedgoose »

mbrodersen wrote: post #279
speedgoose wrote: post #67

Earlier quoted context omitted.

If a NPM package requires a C++ compiler, I ignore it and move on.

V8 (and other Javascript JIT compilers) are written in C++. Whenever you think you run Javascript code, what you are actually running is C++ code that will emulate and compile your Javascript into machine code, update the DOM with C++ code, access sockets using C/C++ code etc. all running on an OS written in C/C++. Your code is a very small percentage of the code that runs "your" application. C/C++ runs the world. In…

I do trust the C++ of V8 and NodeJS because it's used by many and well tested in the field.

I do not trust a random npm package with C++. C++ is way too level and insecure and it's not worth it.

Post reply on HN