Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>Saying they're out of consideration because they're not mainstream is a circular argument.

No, it's a pragmatic argument. There's no circularity it.

If they're not mainstream, then they're neither "very usable" or "well-supported" to any extend that a mainstream language would be.



Here's the circularity:

- There are no mainstream languages with powerful and convenient type systems

- But there are less mainstream ones

- But I won't use those

- There are no mainstream languages with powerful and convenient type systems


That's circularity alright, but not as in a "circular argument" though. It's a feedback loop.

That's however a totally legitimate engineering choice.

Engineers picking on a language shouldn't bet on less mainstream incomplete environments with less tooling and libs and options and devs, just so that they can raise them into the mainstream.

That might be a "tragedy of the commons" thing, but it's not an engineering obligation to be an early adopter.


They're not obligated to by early adopters, but then you hear comments like:

> There aren't any mainstream languages that have the ability to detect the ultra high-level errors you describe.

And it's like, well there are great languages that can do that, but if you restrict yourself to that tiny 'mainstream' subset, you'll never know it.

And moreover I think engineers (or rather, companies) are way too conservative about this stuff–picking 'mainstream' tech can be a touch-and-go proposition at any time. Just because something is mainstream, doesn't mean it's the right choice for your project.




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

Search: