Not to denigrate this (very) nice functionality, but, can we perhaps
avoid using non-portable languages and implementations?
I work with Ruby, Node.JS, Groovy and several other major "popular"
platforms/frameworks/languages on a regular basis, and constantly curse
them for all the problems in security, portability, and clarity that
more mature languages/frameworks/etc. simply don't have anymore.
As a systems person, I'm much more attuned to the requirements of
maintenance, security, and support that is typical for developers.
Which is why I cast a dim eye on anything implemented in something
outside the "baseline standards" that systems folks use these days:
Perl, Python, C, bash, and Java.
This isn't a comment (really, I do mean that) on the general state of
application development and choices there for language/platform/et al.
This is a statement that SYSTEMS-specific stuff (i.e. things that we
expect to become part of the OS, or at least heavily used AND maintained
by Systems folks) should avoid anything outside the relatively
constrained list of things that all systems people can reasonably be
expected to understand very well. And I've seldom seen any coherent
argument as to why such software needed to be written in something else
(and, no, "because I really like XYZ's cool functionality to do ABC"
isn't a valid argument). For example, it's why I find Chef and Puppet
so very annoying, because they chose Ruby as the basis for their DSL,
rather than Bash, Perl or Python, given that Ruby is really not in the
toolchest of any systems folks, and only known in the DevOps world
BECAUSE people were forced to learn it for Chef/Puppet.
Honestly, I don't really even like the Fishworks-style stuff - the
functionality is fabulous, but I think it was a serious mistake to write
a critical piece of software in a framework that few systems people
understand at all, let alone have enough knowledge of to figure out what
is wrong when something goes sideways. Even if it was for an "appliance."
-Erik
On 9/7/2013 1:51 AM, Robert Fisher wrote:
It won't run on SPARC because Node.js doesn't run on SPARC. IMO that's
not likely to change, as it requires someone porting V8 to SPARC, or
getting Node to work reliably with a difference Javascript engine.
I did consider writing it in Ruby for better portability, but it's
aimed at people with cloud deployments, and I don't know of anyone
doing that kind of thing with SPARC hardware.
Rob
-------------------------------------------
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182180/21319143-b7837b05
Modify Your Subscription: https://www.listbox.com/member/?&;
Powered by Listbox: http://www.listbox.com
-------------------------------------------
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be
Modify Your Subscription:
https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4
Powered by Listbox: http://www.listbox.com
