This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (33)
- # cider (40)
- # clara (28)
- # cljs-dev (38)
- # cljsrn (5)
- # clojure (197)
- # clojure-greece (1)
- # clojure-italy (7)
- # clojure-losangeles (1)
- # clojure-nl (10)
- # clojure-spec (32)
- # clojure-uk (154)
- # clojurescript (48)
- # core-async (33)
- # cursive (32)
- # datomic (19)
- # duct (1)
- # fulcro (10)
- # graphql (6)
- # jobs (1)
- # lumo (1)
- # mount (6)
- # off-topic (48)
- # onyx (12)
- # other-languages (2)
- # re-frame (77)
- # reagent (19)
- # reitit (4)
- # ring (5)
- # ring-swagger (18)
- # rum (4)
- # shadow-cljs (52)
- # specter (12)
- # tools-deps (47)
Whats a thing from another programming language that you miss when working in Clojure? I see the reverse situation quite often. Note. I just realized this is quite a large question. I’m in between tests on my Python project and i’m missing destructuring a ton at the minute.
type safety, fast startup times (for scripts or cli tools), good tooling for refactoring and static analysis
Hm. Roger. Thats a well trodden ground. I have a fairly limited experience to Python, Ruby, Java, Clojure. I’m always curious if their are idioms in Scala, Haskell, etc… that i’m not familiar with, that other people find interesting.
Well, the type system of Scala, Haskell and related are a huge improvement over Java
Half the times I wish I had a type system, and half the times I'm amazed at how much simpler clojure code tends to be
The self-documenting-ness of class-based objects. The set of methods defined on a class gives you an immediate sense of the sort of things the class author envisioned you would want to do to an object of that class. There's real value in it. Whereas a complex nested map -- you can do a million things to it, but it's not immediately obvious which of those million things is the appropriate one for what that map is intended to represent -- which itself may not be obvious the first time you look at new code. And that set of methods is easily discoverable through introspection, which gives you some extra velocity. I'm more than willing to trade that away for the other advantages clj/s offers. And it has inherent disadvantages -- as RH has said, it means having to learn a new mini-DSL for each new type of object. But I think it's worth recognizing the value it has, and thinking about ways to bring that same value into clj/s. If anyone has thoughts/ideas about the best ways to do that, I'd love to hear about them.
(records + protocols is the obvious answer, but in practice, using them doesn't always appeal, or feel like it necessarily gets me the whole way there)
@eggsyntax I think you could argue the same for Haskell which is not class/object based, but it does define functions/lenses etc. on specific data structures instead of just maps which makes the API stand out more
but when I have to write it, I’m like, pfff, this is too much work, I could do it in Clojure faster, etc. So it’s more work in advance, but you’ll get the benefits later when you have to refactor something or learn a new API.
I haven’t used Haskell in anger either, just worked half way through Haskell Book and did some toy projects
Is anyone here doing: - application platforms - compliance And happy to share any knowledge on the topic? Bonus points for datomic 😊
Ah OK, I don't know anything about PCI compliance, sorry. If Datomic's immutability is troubling you, maybe this will be useful: http://vvvvalvalval.github.io/posts/2018-05-01-making-a-datomic-system-gdpr-compliant.html.
No, our lawyers are quite happy with retraction for gdpr. I'm more looking into whether we can make a lot of annoying work on PCI (audit logs, logging, breakglass, alarms, firewalling) go away to some degree by relying on an application platform abstraction. Unfortunately, datomic feels potentially awkward on some of these systems.
@U0P1MGUSX I was thinking more along the lines of Heroku, Kubernetes, Mesos, etc. But anything which satisfies the constraints of being a higher level description of infrastructure would be sufficient.
@U09LZR36F I had a PCI system for a $100M business for several years. The architectural problem with PCI is that the PANs bleed. So the underlying platform- if it is shared by apps that you do not want under PCI- needs to provide the controls and segregation, both for in-transit and at-rest PANs. Can k8s do this? At first blush, I think one should be able to segregate workloads sufficiently, such that a single k8s cluster can run both PCI and shielded-from-PCI apps. Does k8s provide any special magic for PCI? Not really, other than what it does to run software on a bunch of a machines from a uniform control plane, where a lot of that software needs unique configuration.
I was wondering things like whether k8s had a concept of firewall isolation of containers. But also if the logging story would satisfy PCI easily, along with all the other controls like FIM which have to be implemented or countered somehow.
We have done a lot of work around integrating logs with aws CloudWatch, and fiddling with micro segmentation, and I'm wondering how much k8s or similar might give you for "cheaper"
Yeah, gotcha. Hmm, I don't think it's going to be cheaper, for most definitions of cheaper, certainly not upfront. It could be more ergonomic in the long run.
Solving for both PCI and non-PCI within a single AWS tenant strikes me as awkward, challenging. With k8s, there is a lot more control, though that means a lot more configuration work. Raw k8s does relatively little out of the box. It doesn't do anything about logging other than connect stdout/stderr from the container runtime to syslog on the host. It doesn't do anything about networking other than assign each pod its own netblock. It literally does nothing about durable storage. It has a tenancy model, but no platform I'm aware of has a specific-to-PCI model of tenancy.
So one has to pick and choose and integrate and then configure components, though here one is working with pieces of software rather than interfaces offered by cloud services.
A PCI tenant is an interesting idea, though. k8s involves a lot of declarative configuration. This configuration can be generated, templated and shared across environments. The ease and scalability of doing so has been a major factor in k8s adoption. So- I would guess that at some point, there will emerge a set of configuration templates for PCI compliance, to be applied to one's k8s cluster.
That's disappointing. I had hoped that Google's eye would have put a really strong security perspective on things. Sounds like a similar cost to the one we've paid on AWS already. In terms of networking, k8s does nothing to firewall pods from each other?!
Sorry, that was a little too much shorthand- k8s decided that the cross host pod->pod communication, pod->outside, and outside->pod were all problems to which there are many, many potential solutions, both in terms of mechanism and in terms of policy, with lots of competing things to optimize for. So when one is building a cluster, among other things, one has to pick a cluster network plugin from a very extensive list: https://kubernetes.io/docs/concepts/cluster-administration/networking/ that meets one's particular requirements and capabilities. From the outside, networking is just something k8s does, it's really not, there are many distinct machinery, configuration and observability choices involved, and implicitly or explicitly, you have to make all of them. With that machinery in place, you can then manage it with declarative policy resources, which is extremely powerful, much better at scale than e.g. committing a change and then hoping puppet picks it up when it runs across your plant and that the churn as things are changing doesn't break anything. But one has to get to that point.
I found the policy resources which pertain to networking, which does permit you to perform segmentation. That's relieving. This is all quite interesting. Are there any other declarative aspects I might appreciate? Policies are neat, but AWS has them, even though they're a little painful to write.
On the surface it's not dissimilar to other templated, declarative-esque approaches to infrastructure, e.g. cloudformation, terraform, but instead of describing your infrastructure, you describe your workloads. The underlying model is that you post your desired workload end state- a set of services, or some jobs, etc- as "resources" to the cluster, and "controllers" gradually converge the state in the cluster with the state described in the resources. This machinery is also extensible, so you are not limited to the resources k8s comes with, but can create your own, and still take advantage of the convergence machinery. This most recently has led to the creation- by a third party, outside of google- of the concept of an "operator"- a set of resources that, for instance, declaratively describe the full lifecycle of managing a database, including backups, restores, failovers, etc. (Relevant for PCI :) The level of abstraction is very high. Google has a terrific paper describing their Borg cluster manager- the system that motivated the creation of kubernetes. Recommended for getting a flavor of the concerns that k8s is solving for, and the approach it takes: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43438.pdf
> The underlying model is that you post your desired workload end state- a set of services, or some jobs, etc- as "resources" to the cluster, and "controllers" gradually converge the state in the cluster with the state described in the resources. Is this not pretty much the same as terraform/cf? I'm missing the distinction I'm afraid. Being able to describe the database system like that (and anything contextual) sounds very powerful. I'll take a look at the paper, thanks.
Huh, Apple must really not want me to file a bug report via their developer site. Every time I try, on my company's VPN or not, with any of Chrome, Safari, or Firefox, I get an error when trying to go to the bug reporting page.