[scegit]

> “We probably over-engineered it, I guess,” Damens said.

Exactly. Also, creating a programming language for something as simple as a newspaper is pretty much a nightmare. Worrying about scalability when most of their content is static.

[dang]

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

[ndespres]

This is nearly 20 years ago. Were CGI and PHP really up for the tasks of serving up the type of dynamic pages at scale 2 decades ago? The "content" (articles) might be largely static but the pages are not, with dynamic ads, weather reports, showtimes etc. Not to mention getting non-technical people to adopt the language easily, transitioning from print publishing workflows. Do you not believe them when they say existing language and solutions weren't working?

[scegit]

I'm not really familiar with how things were ~20 years ago, but I still believe that creating a language to use internally just for this is overkill. Dynamic ads, weather reports ... etc. are not that difficult they could have probably done it in C (maybe a custom somewhat advanced template engine?) with much less effort.

[scott_s]

I think you are underestimating how novel those things were 20 years ago. The NYT has been ahead-of-the-curve when it comes to the sophistication of their webpage for about that long. Perhaps their language helped.

[scegit]

It is pretty cool that they created their own language, but I was not sure if they really needed to do that. I guess it was worth it back then. Looking at their website in 2002[0] it is pretty impressive indeed. [0] https://web.archive.org/web/20020209001700/https://www.nytim...

[mooreds]

Twenty years ago I would have prototyped the solution in perl as an Apache module and then rewritten the slow hot spots in c.

But I don't know what their hardware constraints weredit person => perl

[a-dub]

My guess is that it actually looked a lot like that, except the mod_perl app was actually a homegrown template engine using their homegrown template language which they then called "Context".

That was a common pattern back then.

[batter]

Now they're forcing everything to golang. As result loosing some good guys who don't like that pressure.

[ses1984]

This is wrong, or omits important details. Different teams there use golang, python, java, scala, clojure, javascript, and probably other languages.

[hu3]

That caught me by surprise but it makes sense when checking their GitHub activity.

18 repos for Go

18 repos for JavaScript

9 repos for Python

7 repos for Ruby

I'll read more about their decision on using Go. Thanks for the pointer.