Hacker News new | past | comments | ask | show | jobs | submit login

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




"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


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?


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.


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.


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


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


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.


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


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


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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: