5 ms·

I love the idea of Clojure. I find the ecosystem immature and full of ideas about "libraries, not frameworks" that leave developers incredibly vulnerable to th

by Kalium 7y ago

I love the idea of Clojure. I find the ecosystem immature and full of ideas about "libraries, not frameworks" that leave developers incredibly vulnerable to their own ignorance and second-order ignorance. The number of developers I know - or even know of - that can be trusted to develop a useful and secure web application from the ground up with this kind of tooling approaches zero. Clojure is a cool language. I can only hope the ecosystem soon matures enough to make it one that's suitable for serious use.

dominotw 7y ago
there is luminus that assembles all the parts for you.
- Kalium 7y ago
  Which would be wonderful! Except for the responses of visceral disgust I get from Clojure developers when I suggest using a framework. The culture seems hostile to actually using such things.
dmix 7y ago
Which libraries are people expected to plug together the security parts? I'm not pushing for clojure but a lot of other languages and frameworks are taking this approach too including Node and Go. Wouldn't the security stuff be a part of the individual packages? Ie authentication package handles sessions and tokens, an http server/middleware with built in csp and ssl, orm, the data stuff handling serialization and data parsing? Technically rails is composed of a bunch of smaller gems with a similar responsibility tree although without the centralized CVE distribution and pressure that creates. When I used Clojure it was always mini frameworks which created a base set of important packages with a pluggable middleware system on top and flexible data back ends. The individual packages need to have domain experts for their particular attack surfaces and exposures. If anything its about a lack of eyes or community size on the various wholes, rather than expecting the end user to do the individual hardening or plumbing.
- Kalium 7y ago
  You're right. Many things can be handled by packages, abstracting them away from the developer. Of course, that's assuming the developer thinks far enough ahead to remember that they need authentication, decide how they want to handle it, figure out what they want for a CSP, and so on. Other things cannot be so readily handled. Authorization, for example, isn't a concern that can be bundled into a pre-fab function. It's something application-specific that has to be re-evaluated with every single web request and is going to be subject to unique business requirements. Frameworks tend to handle these issues by setting out a set of conventions to adhere to, within which many of these concerns are handled for you to the extent possible. It's far from perfect, but it does a lot to reduce the chances of someone forgetting (for example) that forms need anti-CSRF tokens because their form-generation function doesn't do it for them or automatically work with the form-accepting and validating functions. Or, to use example I've seen, the logging package's ignorance of what might be sensitive in the strings its been handed turns into secrets being sent to the centralized logging system and exposed to far more people than they should be. The developer didn't think about what might be in what they were logging, the package assumed that the developer did, and the result could have been avoided by a more integrated whole. A culture of libraries instead of frameworks can mean that each project may have to make all the decisions a framework does all over again. Is everyone going to get it right every time?
  - bcrosby95 7y ago
    > The developer didn't think about what might be in what they were logging, the package assumed that the developer did, and the result could have been avoided by a more integrated whole Umm, is there any all in one web framework that protects against this to any level of guarantee?
    - Kalium 7y ago
      It's been my experience that Rails logging can and will do things like censor password fields when passed objects. So, yes, it is possible for logging (and serialization) systems to defend against this kind of thing.
didibus 7y ago
That's just a misconception imo. Clojure is full of frameworks. The real issue is overwhelming choice and the no handholding make your own decisions approach. Probably accentuated with a lack of beginner guides. Have a look at Pedestal, Yada, Duct, Hoplon, Catacumba, Coast, and Fulcro. Those are all actively maintained frameworks being used by different people in production. On top of those, you have the meta-libs frameworks such as Luminus and Chestnuts. And what most people don't know is a lot of Clojure devs use a Java framework, because those are also available to be used from Clojure. I have a Spring MVC Clojure app for example. Lots of folks use Vert.x for example. So whatever your definition of mature is, Clojure has everything you need and more. If you mean mature as in, one and only one way which everyone is rallied behind and all guides and tutorials teach and use, then no.
joeevans1000 7y ago
There was a interesting and relevant post about this recently from a pretty established clojurist: http://flyingmachinestudios.com/programming/why-programmers-need-frameworks/ http://flyingmachinestudios.com/programming/why-programmers-...

by Kalium 7y ago

dominotw 7y ago

there is luminus that assembles all the parts for you.

Kalium 7y ago
Which would be wonderful! Except for the responses of visceral disgust I get from Clojure developers when I suggest using a framework. The culture seems hostile to actually using such things.

dmix 7y ago

Which libraries are people expected to plug together the security parts? I'm not pushing for clojure but a lot of other languages and frameworks are taking this approach too including Node and Go. Wouldn't the security stuff be a part of the individual packages? Ie authentication package handles sessions and tokens, an http server/middleware with built in csp and ssl, orm, the data stuff handling serialization and data parsing? Technically rails is composed of a bunch of smaller gems with a similar responsibility tree although without the centralized CVE distribution and pressure that creates. When I used Clojure it was always mini frameworks which created a base set of important packages with a pluggable middleware system on top and flexible data back ends. The individual packages need to have domain experts for their particular attack surfaces and exposures. If anything its about a lack of eyes or community size on the various wholes, rather than expecting the end user to do the individual hardening or plumbing.

Kalium 7y ago
You're right. Many things can be handled by packages, abstracting them away from the developer. Of course, that's assuming the developer thinks far enough ahead to remember that they need authentication, decide how they want to handle it, figure out what they want for a CSP, and so on. Other things cannot be so readily handled. Authorization, for example, isn't a concern that can be bundled into a pre-fab function. It's something application-specific that has to be re-evaluated with every single web request and is going to be subject to unique business requirements. Frameworks tend to handle these issues by setting out a set of conventions to adhere to, within which many of these concerns are handled for you to the extent possible. It's far from perfect, but it does a lot to reduce the chances of someone forgetting (for example) that forms need anti-CSRF tokens because their form-generation function doesn't do it for them or automatically work with the form-accepting and validating functions. Or, to use example I've seen, the logging package's ignorance of what might be sensitive in the strings its been handed turns into secrets being sent to the centralized logging system and exposed to far more people than they should be. The developer didn't think about what might be in what they were logging, the package assumed that the developer did, and the result could have been avoided by a more integrated whole. A culture of libraries instead of frameworks can mean that each project may have to make all the decisions a framework does all over again. Is everyone going to get it right every time?
- bcrosby95 7y ago
  > The developer didn't think about what might be in what they were logging, the package assumed that the developer did, and the result could have been avoided by a more integrated whole Umm, is there any all in one web framework that protects against this to any level of guarantee?
  - Kalium 7y ago
    It's been my experience that Rails logging can and will do things like censor password fields when passed objects. So, yes, it is possible for logging (and serialization) systems to defend against this kind of thing.

didibus 7y ago

That's just a misconception imo. Clojure is full of frameworks. The real issue is overwhelming choice and the no handholding make your own decisions approach. Probably accentuated with a lack of beginner guides. Have a look at Pedestal, Yada, Duct, Hoplon, Catacumba, Coast, and Fulcro. Those are all actively maintained frameworks being used by different people in production. On top of those, you have the meta-libs frameworks such as Luminus and Chestnuts. And what most people don't know is a lot of Clojure devs use a Java framework, because those are also available to be used from Clojure. I have a Spring MVC Clojure app for example. Lots of folks use Vert.x for example. So whatever your definition of mature is, Clojure has everything you need and more. If you mean mature as in, one and only one way which everyone is rallied behind and all guides and tutorials teach and use, then no.

joeevans1000 7y ago

There was a interesting and relevant post about this recently from a pretty established clojurist: http://flyingmachinestudios.com/programming/why-programmers-need-frameworks/ http://flyingmachinestudios.com/programming/why-programmers-...