> Devs don't want to manage VMs. Patching, gold loads, SSH configs, k8s, so on
Which devs?
I'm a developer and I enjoy most of these things. Working with k8s is a pleasure, managing VMs can be quite simple (and more often than not, is). I don't do much patching, but I "SSH" into our k8s pods quite frequently. I've never thought, gee I wish I had a lambda to simplify this. I know I _also_ don't represent all devs, but I'm never seen this comment made outside of it being an argument supporting FAAS.
K8s can be great but at a largish retailer (billions in yearly revenue) it took a team of engineers on the better end of the company's talent pool to manage the clusters. Those salaries can buy a lot of serverless service usage and according to uptime metrics better reliability. On top of it the teams adopting serverless generally had higher velocity. At scale there were a few use cases that needed to economize but... Largely not.
I think the more important part is the laundry list of frameworks, cloud services, etc. to manage, not the pleasure you draw from working with the services themselves.
If you get minimal returns for managing 5 extra services, it doesn't make sense most of the time.
I do agree though that the cost should not be the thing the poster brags about with this architecture. It's the tradeoff between simplicity, cost, and functionality.
I work in the finance industry. Most devs don't seem to know or care about IAM, proper network security, or keeping VMs and container images up to date.
IAM in AWS is by no means "easy" but when you get it right, it's pretty damned good.
I would add that the hard parts of working with Kubernetes is setting up ingress controllers and persistent volumes, but that's precisely the type of problems that any Kubernetes service provider takes care for you.
anyone mind explaining the /# to me? like `Application.get_env/3`. been wanting to learn Elixir for awhile now, but didn't even know what do Google for that one.
It’s the literal identifier for a function pointer. Module.function/arity. (“Arity” = “number of arguments.”)
If you’re wondering “why add the arity”: Functions in BEAM are polymorphic on their arity, but not their argument types; i.e. multiple functions can share the same name but have different arity, but all definitions in a module of a function with the same name and arity are actually the same function.
When you see Erlang/Elixir code with multiple definitions of a function of the same name and arity, those are called “clause heads”, and are defining the function “by parts”; code like the following gets compiled into one function that branches internally depending on the arguments passed:
That out of the way: `Foo.bar/N` in Elixir code is a function-pointer literal, which you can pass around just like you're passing around a closure. These three lines are all equivalent in semantics:
# remote function pointer
f = Foo.bar/1
# closure
f = fn x -> Foo.bar(x) end
# closure with anonymous parameters
f = &Foo.bar(&1)
...in terms of what happens when you use `f` in your code; but the function-pointer version has lower overhead to call, and costs less memory to keep around, because it's not capturing anything from the environment. It's literally just a pointer.
Oh, and this also exists:
f = &bar/1
...which is a function-pointer referencing a local function in the current module. This distinction is important, because you can get local function pointers that point to private functions; whereas you can't get remote function pointers (the fully-qualified kind that include a module name) to private functions. It's kinda like C++ with private fields—you have to not use `this.` when accessing them.
Oh, and one more variant:
f = some_mod.foo/2
This isn't a function-pointer literal, but rather a function-pointer expression. `some_mod` here is a variable; this expression will give you a function-pointer to the function `foo/2` on whatever module is named by the atom in the `some_mod` variable. (This can only be resolved at runtime; your code will throw an error here when it executes this expression, if it finds out that `some_mod` doesn’t contain an atom, or that atom has no corresponding module, or that module doesn’t have a foo/2 function on it. You can catch this error, though; and the runtime itself catches this error to implement just-in-time module loading.)
not sure how i made it through my entire CS degree without learning this term. either that or i just don't remember it. anyways, thank you! this is really useful even outside of Elixir.
It's much more common than just Elixir programmers. It's a common concept in computer science, particularly in functional programming or languages which permit function overloading on arguments.
Edit to add: I've heard and used arity for at least 10 years, in particular in the Clojure community. I've heard of Elixir and understand it shares some common ideas with Clojure and Ruby, but never been a part of its community.
In functional programming classes at the uni you probably wouldn't hear this because if they teach Haskell which I assume most do, every function always takes just one argument. That's because functions are curried by default.
I personally haven't really heard this mentioned anywhere outside of the Erlang/Elixir sphere.
This thread really surprised me - I learned about arity when learning about ternary operators, which are pretty universal - you can find ?: in all sorts of languages. I think I was learning about C when I first got a detailed explanation on the subject.
Even if every function is curried by default (and "currying" is yet another concept that may be alien to users of some languages), it is probably still useful to know with what number of arguments a function can evaluate to a value that is not just another function
I think it's a useful name for a useful concept, not sure why they'd take it out, "Function.prototype.length" is a much poorer replacement semantically (but hey, Javascript isn't known for its correctness or well-thought-out design...)
I had never heard of "arity" either until I started reading about functional programming concepts. It seems to be used a lot within the functional programming world, but not so much outside of that.
This. I went into my 400 level cryptography class with 0 Number Theory knowledge as it wasn't a prerequisite. Big mistake, it should've been. My lowest grade in college and I still busted my ass.
That being said, it was incredibly interesting and I do not regret it.
You would be surprised - I use Godot to make games, program in Vi, and currently do art in Piskel (https://www.piskelapp.com/). Will definitely give RX a try!
Can you speak more to the scope of this? I'll be watching the video later - but, I'm curious how this "isn't possible to build"?
Also curious about the reasoning behind a new language (Dark), instead of supporting other languages out of the box. Could've started simple with supporting node / python and worked towards go, rust, etc.
Specifically in the context of fundraising, we said "backends are way too hard to build, we can remove all the accidental complexity of infrastructure, deployment, and APIs". Many people felt that that was not possible.
The "Dark's philosophy" video addresses the language a little - everything that's cool in Dark is enabled by the super tight integration between the language, editor, and infra.
Which devs?
I'm a developer and I enjoy most of these things. Working with k8s is a pleasure, managing VMs can be quite simple (and more often than not, is). I don't do much patching, but I "SSH" into our k8s pods quite frequently. I've never thought, gee I wish I had a lambda to simplify this. I know I _also_ don't represent all devs, but I'm never seen this comment made outside of it being an argument supporting FAAS.