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

Honestly I’d rather have good defaults than lots of options. If one tool meets requirements out of the box, then it’s preferable to a tool that requires a lot of tooling.



But if you do not have options then what is a "good default" , you have a default option if you have more then an option, so you prefer software with no options?

Can you give examples of languages(compilers or VMs with bad defaults in your opinion?


Java by default has a hard memory limit which when hit causes services to hang in a semi-responsive state rather than exiting cleanly, requiring every user to hand-tune limits and carefully setup health checks and monitoring. Two decades in, they added a non-standard option to instead exit.

If they had instead made the default to act like almost everything else it would have worked with standard process monitors and limits with no effort required and a substantial fraction of the downtime I’ve seen for Java applications would never have happened.


Isn't this default better for average Joe that runs a Java desktop app, and developers that deploy apps should know how to change this defaults?


How is it better for something to stop working but not exit? It’s exceedingly uncommon for anyone to have correct handling for OOM exceptions so the most likely effect is that stuff partially works - servers accept requests but never respond, apps have menus/buttons which don’t work, etc.

Similarly, if developers who deployed apps knew enough to avoid this, we’d know by now because it wouldn’t happen so frequently. It does highlight who failed to do real health-checks (e.g. years ago most Hadoop services needed huge amounts of RAM to start without crashing but they’d be listed as okay) but it’s the kind of thing sysadmins have been cleaning up for decades.


You are probably right for this case, my initial comment was related to performance tuning configuration, the comment I replied sounded like JVM should have had X set to my preferred value or "I prefer software that has no options to confuse me with aka GNOME mentality"


You can have options and have good default values for those options. Good default values are those that are reasonable for most people most of the time such that they don't need to be (or hire) domain experts to properly configure their tool.

My opinion of a bad default would include a language toolchain which defaults to dynamic linking and requires one to opt into static linking (Java, Python, JS, etc, etc, etc). Worse than that is an anorexic toolchain that has no defaults whatsoever and requires you to pass every little detail directly to the compiler--bonus points if your language has a massive ecosystem of competing tools which are meant to manage these sorts of details for you but utterly and uniformly fail to do so (looking at you, C/C++).


So the JVM run-time is installed and used by average people, so the defaults should be set for this people that install Java to run a desktop app IMO, the developers that want extra performance should read the manual and configure things.


I’ve never heard of a runtime that forces a dichotomy between end-user- and developer-friendliness (putting aside for the moment that end users are famously annoyed by the Java runtime). Rust, Go, etc don’t have runtimes which force a choice between end-users and developers...


JVM can be used for Desktop, server and in the past applets , it would be impossible to find a configuration that is optimal for all applications, so competent developers would tweak the defaults or use different deployment methods like AOT compilation or bundle your own JVM , is your problem that JVM is used in so many different places that different algorithms, runtimes and optimization were created for it ? Your examples of Go and Rust are of languages that are so far not been used in such diverse places, there are no good alternative compilers but something like Python has such a diversity of runtimes.




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

Search: