Hacker News new | ask | show | jobs
by AnimalMuppet 4258 days ago
I think you missed the author's point here. You have to have the webserver somewhere. That's inescapable complexity. It's in the language, or in the library, or in an external container like Tomcat. But if you're going to run a web app, you have to have a server somewhere.

Where Go made things simpler is in the dependencies. The app now has all the dependencies compiled in, and so it's completely isolated from what libraries some other app in the container needed. That is a removal of accidental complexity. (Right up until you need to update all the apps to fix a bug in some library, and now you have to update each app, not just update one library in the container...)
2 comments
bad_user 4258 days ago
I don't get the comparison with the JVM.

I've built web services with an embedded Jetty in which the deployment happened by copying and executing a single JAR file with everything included. It's actually really easy to do - http://www.eclipse.org/jetty/documentation/current/embedding...

Now I'm building web services on top of Play Framework (and Scala), which comes with its own web server that has nothing to do with Servlets or Java EE and so it has nothing to do with application servers and WARs and containers. And it's been good for the Play framework to come with its own server, because Servlets is moving slowly (that's what happens to standards) and Play has been capable of WebSocket or asynchronous processing of requests long before Servlets was.

This is actually an area for which I love the JVM - Java's Servlets is an objectively good standard with multiple implementations, other platforms can only dream about such a popular and good standard (Java EE on the whole arguably less so, but the Servlets part is OK) and you can totally decide to not use it. I personally love having choice and when I'm faced with a problem, it's much easier for me to search and learn a new library than a new language - I'm saying this after I've been working with about 6 languages on the job and played with about a dozen others.

Also, here's another opinion - I personally started to hate languages coming with "batteries included". I like languages in which the standard library contains the core necessities. Like, immutable data-structures or abstractions for dealing with concurrency - completely fine to be in a standard library. JSON parsing, http handling - no freaking way.

link
NateDad 4258 days ago
Can you explain why you don't like languages with batteries included? Isn't it nice to have one JSON parser that you know is quality and that everyone can use? People new to the language don't have to go figure out which of the 8 libraries that are out there is the "good one". Standards like that also mean that you can jump into any random codebase and know exactly what's going on. So.... can you explain? I don't understand why they're a bad thing.
link
bad_user 4258 days ago
> Isn't it nice to have one JSON parser that you know is quality and that everyone can use?

Sure it is - but that's an utopia and never, ever happens.

The JSON parser in Scala's standard library sucks. The JSON parser in Python's standard library sucks. The JSON parser in Ruby's standard library sucks. I actually challenge you to give me an example of JSON functionality included in a standard library that doesn't suck.

In practice what happens is that one or two third-party libraries pop-up at some point that are so much better that people start using it as a de-facto standard and then the functionality in the standard library becomes legacy that has to be carried around because backwards compatibility.

And much worse than a small standard library is a standard library full of deprecated stuff.

link
NateDad 4258 days ago
>I actually challenge you to give me an example of JSON functionality included in a standard library that doesn't suck

Uh... the one in the Go standard library? :)

link
jasode 4258 days ago
>Where Go made things simpler is in the dependencies. The app now has all the dependencies compiled in, and so it's completely isolated from what libraries some other app in the container needed. That is a removal of accidental complexity.

I agree with all that Golang simplification except for one thing: I don't call the previous state of affairs "accidental complexity". It's certainly "more complex" with more moving parts but it doesn't feel "accidental" to me.

I maintain that the nature of complexity and location of it has changed. You yourself gave an example:

>(Right up until you need to update all the apps to fix a bug in some library, and now you have to update each app, not just update one library in the container...)

Complexity has now increased in deployment if there's a bug. If Tomcat has a security bug, you update it instead of all the servlets. If golang exe has a bug, you have to recompile all exes and redeploy.

It doesn't mean the Java situation is overall better than Golang, it's just different.

link