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

I think the tension is more between people writing executables and people writing libraries.

If you want your language to be suitable for any purpose by using an intricate web of libraries depending on each other, you need those language features and deep theory. Think haskell, lisp, rust, etc.

If you kind of know what people will use your language for, and you build in the most important functionality, you aren't nearly so dependent on libraries. You just make the language accessible and as productive as possible. Think Go, erlang, PHP, SQL, javascript, VB.

I honestly think that any language that enables too much cleverness will inevitably produce a mess given enough developers involved.

I tend to think libraries work fine with Go. It's "frameworks" that are difficult.

I think you're on point, writing system stuff in Golang can be a bit of a pain due to the lack of expressiveness, but writing anything else is a freaking joy.

Reading Golang on the other hand is always pure joy.

Yet the Go standard library is one of the best around ...

It seems that you are agreeing with me.

A standard library for a language with a purpose (like Go) should include a lot of stuff related to that purpose. That avoids the need for an intricate web of dependencies and specialized third-oarty code, but ties the language to its purpose a bit more.

A standard library for a use-for-anything-and-everything language (like rust) might be smaller because it relies more on third-party libraries for the specific purposes you have in mind.

Any general-purpose programming language that wants to be more than a toy needs an "intricate web of libraries".

The alternative are domain-specific languages - like SQL for example - which people simply do not and will not try to use in arbitrary new settings.

well said!

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