What is automatic about docker? Do you mean other people have already put in the work? Or do you mean that it's more trivial to pip/npm/cargo install stuff?
I would say OOP revolves around the concept of modeling real-world entities or concepts as objects in code. Records encapsulate data fields within an object, providing a way to model real-world entities.
>Object-oriented programming (OOP) is a programming paradigm based on the concept of objects,[1] which can contain data and code: data in the form of fields (often known as attributes or properties), and code in the form of procedures (often known as methods). In OOP, computer programs are designed by making them out of objects that interact with one another.
But also, from same wikipedia page:
>Attempts to find a consensus definition or theory behind objects have not proven very successful (however, see Abadi & Cardelli, A Theory of Objects[68] for formal definitions of many OOP concepts and constructs), and often diverge widely. For example, some definitions focus on mental activities, and some on program structuring.
TS has a powerful type system that behaves in strange and counter intuitive ways, particular for people coming from JS. It doesn’t even have a spec, really. I would prefer something less powerful but more predictable, personally.
I code in C# and use a ton of LINQ when writing business logic. It's FP-ish enough to avoid logic mistakes. The mediator design pattern, which is kind of bringing another FP paradigm to the OO world, also features heavily.
I think this is the point really, not that mainstream, "general purpose" languages support FP well, but that FP ideas and aspects have been adapted into many of them.
C# LINQ, being a round-about implementation of do-notation, is a pretty advanced FP feature, and beyond most mainstream languages. C# is certainly a step up over Java etc.
However, most developers wouldn’t understand, say, a result monad implemented via LINQ, so you’re still fighting the ecosystem somewhat.
Yes, the field of FP is much more, but the core of FP is that. A language doesn't become non-FP simply because it has some imperative abilities, or logic programming builtin, etc.
Immutability by default is not a requirement for functional programming (I mean... if it were, Haskell would be obviously not FP since the 'default' entrypoint is very mutable).
Neither are monads. There are entire FP languages without monads for effects (obviously, you can write a monadic interface in them, but it's not part of the idiomatic core). For example, clean uses linear types to control effects and purescript / Idris use a custom effect-system. So no, monads are not a requirement, and even if they are, modern c++ fully supports them, as does rust, javascript, etc. It's very common in javascript to use Array.map() and Array.flat().
> Immutability by default is not a requirement for functional programming (I mean... if it were, Haskell would be obviously not FP since the 'default' entrypoint is very mutable).
I mean the bindings and collections. For example, when you make an array in JS, the default syntax is a mutable list with a mutable binding:
let xs = [ 1, 2, 3 ]
> Neither are monads. There are entire FP languages without monads for effects (obviously, you can write a monadic interface in them, but it's not part of the idiomatic core).
I should be more precise - there needs to be some way to mange effects. Monads with syntax extensions is simply the most common (Haskell, Scala, F#, Closure macros)
> and even if they are, modern c++ fully supports them, as does rust, javascript, etc. It's very common in javascript to use Array.map() and Array.flat().
JavaScript does not have good monad support. This is why async/await was added as a new language feature. Yeah, I know you can hack together something with generator functions, but it’s hardly idiomatic.
But we’re getting into the weeds here. My point is: I don’t consider a language to support FP when writing functional code in that language leads to lots of friction compared to what is idiomatic.
Have you ever tried FP in Java? It works for some toy thing but then you hit the lack of TCO, or the ridiculously long type names (not inferred) or the pyramid of doom…
It's the friendlier syntax. With the same conditional in javascript and python,the python version reads a little more like english. The same can can be said for loops. However, JS is right there in your browser so I would argue its much more accessible. Also the usecases for javascript are more aligned with junior coders (browser games, toy projects with a visual element etc), though to dig in to these you have to learn about the web dom which is quite overwhelming.
It seems like this system can only work if the build and deployment is all done by one tool in a monorepo. What does migration from existing setups look like?
And what about services that communicate via shared infrastructure:
- A writes to Kafka topic T
- B reads from Kafka topic T
Ok so we could make the hash of A part of the topic name T, but then on every release we make a new topic and lose history?
- flakes are labelled experimental for years now (I think it might be almost 5 years now) which creates confusion with new users, but they are universally used nearly everywhere now
- there seems to be some bad blood[1] between https://determinate.systems/ company and the long time Nix users and developers who are accusing them that they are using Nix for their benefit with not contributing back. From my understanding Determinate Systems introduced flakes and probably this why there's some resistance to it by some.
But to answer your question, pretty much everyone adopted flakes and guides that don't use them are most likely old.
DetSys founder here :). Firstly, congratulations to Flox on the launch.
DetSys is founded by Nix's inventor Eelco, and me -- a fairly long time community member (since ~2016.) We're also loaded with long term Nix users and contributors. We (the company) didn't invent flakes, and I didn't have anything to do with it either. While working at Tweag, Eelco worked with Target to develop the idea.
I'm not sure where this idea of bad blood or not contributing back comes from, either. The vast, vast majority of our code and products are completely FOSS, and our most popular product (the Determinate Nix Installer) is deliberately licensed in a way that upstream Nix can take it and integrate it however they want, any time they want. And I hope they do! We also invest heavily in contributions directly upstream. We're long time open source contributors and advocates, and that doesn't change now that we started a company.
I think there is a lot of compression of time and history here that has lead to lot of pretty baseless accusations and confusion. I think some people who don't like the change don't like it because they've built their own mechanisms to get what flakes provides. That's fine, nobody has to use flakes. The old ways aren't going away. Some folks don't like them because they're not technically perfect or bug-free. That's fine, too, but they're not becoming more stable by pretending flakes don't exist.
I look at threads like the one you linked as evidence we're doing something interesting. Nobody would care if what we were doing was useless.
One point that is absolutely true, though: DetSys is 100% contributed to the version of the future where Nix + Flakes is the thing. Flakes solve such vast problems that I feel there is no going back. This is the basis for the Determinate Nix Installer: we guarantee flake stability, and use the installer as the wedge to keep that promise with our users. This promise has been the basis of our work on FlakeHub and our just-launched-today FlakeHub Cache.
Unfortunately, nix.dev -- an official Nix documentation source -- specifically does not teach much about Flakes. To the degree of introducing documentation for unmaintained tools that see very low community adoption: https://nix.dev/guides/recipes/dependency-management.
We've taken a strong position on flakes by introducing our installer and zero-to-nix.com, a flake-first documentation source because of this confusion. I have asked numerous times for the various Nix leadership teams to make a choice on if flakes are the future or not, but as we can all plainly see: they have not chosen to do so. This confusion about flakes comes from the very top, unfortunately. I find this very motivating for building the best Nix company I can, to support the adoption of Nix and flakes in interesting places around the world.
Ah, apologies for getting things wrong. Thanks for explaining it and making it clearer. I just saw the hostility in that thread and that's how I interpreted it.
BTW: I have nothing to do with Flox, I'm just ordinary Nix user who actually likes flakes and also wishes it would get removed from the experimental flag. At this point I agree there's no going back. If flake was removed tomorrow there would be a huge uproar and countless of setups broken. The ship already has sailed and continuing on keeping it behind experimental only undermines what "experimental" supposed to mean.
I don’t know anyone who is recommending against flakes these days. The “experimental” label is more about the API stability than completeness, bugginess, or anything else.
There are certain scenarios where the performance can be problematic, but there are workarounds and permanent solutions are being worked on. Nevertheless, using flakes extensively at home and work.
>I don’t know anyone who is recommending against flakes these days. The “experimental” label is more about the API stability than completeness, bugginess, or anything else.
"Experimental" traditionally means "if you use it and it breaks, then that's your fault". This is because if <experimental thing> did break, the entire internet would dogpile on any complainers with "IT WAS LABELLED EXPERIMENTAL WHAT WERE YOU EXPECTING."
It's the same as ignoring Kickstarter warnings; if a project gives you a warning then tell you to ignore that same warning, don't; if things go to shit then everyone will say "YOU WERE WARNED WHAT WERE YOU EXPECTING." They cannot un-warn you, that's not how this social situation works. I'm not claiming this is fair, I'm just claiming this is how it plays out in practice.
The only safe response to this is to assume that anything labelled "experimental" is exactly what it says. And to be clear, that means the only safe response is to ignore any claims that the thing labelled "experimental" is safe.
Or to put it another way: if you don't mean it's experimental and do recommend it to the average user, then don't use the term "experimental".
Here's the closest thing to an 'unwarning' that can exist, which is a tl;dr of the history:
The experimental label is a historical compromise because flakes, which was conceived by the original author of Nix (who is still a maintainer), was a major change merged to master without going through the whole Nix community RFC process (which was then in its infancy).
So it was added, but tucked away behind an 'experimental' designation and enablement flag. This proved controversial at the time and perhaps still is among old timers, but in the interim flakes have become enormously popular with new users (probably most people who picked up Nix in the past 3 years or so).
Third-party adoption of flakes has by now reached the point that the vast majority of big tools in the Nix ecosystem support it well. Some interfaces are still officially unstable but serious breakage is pretty rare. The flakes implementation in the codebase is very usable but still incomplete and still a bit buggy, and straightening out the kinks in the implementation as well as stabilizing the interfaces (both for Nix code and the CLI) is careful, patient work under way right now.
Hence the common recommendation to just use 'em unless you have deep Nix knowledge and a specific reason not to.
I've originally started developing Mikoto as a Discord extension, but pivoted when I realized that it was against their TOS + there's only much you can do if you only have a partial control over the stack.
We're open source, at https://github.com/mikotoIO/mikoto. We also will have a very comprehensive extension API, powered through iframes + wasm "containers". We also focus our features on superusers, and will eventually seek monetization through selling integration and enterprise hosting.
Spent some time reading through matrix specification; my opinion is that it's overkill in some ways and under-delivers in some parts of its specs for my usecase, enough to justify writing a whole new protocol from scratch
With that being said, we're working on implementing a matrix compatibility layer!
If what you need is available, however, then it can be so much better.