Functional programming tends to get conflated with static typing and immutability, but it’s a much broader paradigm than that. I find it really depends on the specific language. It’s very easy to do local mutation in Clojure for example. There are constructs like transient specifically designed for doing that. There are also languages like Janet that are functional, but use mutable constructs by default and can embed in C with very low footprint.

I generally get annoyed with software being slow to startup and hogging resources as well, but that’s a separate discussion. The JVM is designed primarily for servers where you have long running processes, and startup time isn’t really a big concern. So, it’s not the best illustration. A CL app written using something like clog will be very snappy.

Joe Armstrong made a good point a while back as well. He pointed out that it’s better to focus on making the compiler smarter so that it can do the optimize performance, and optimize languages for human readability. I very much agree with that sentiment. We can see an example of that being done with GraalVM which can compile JVM bytecode into optimized native apps that have very fast startup time and use far less resources than the JVM. At the moment it’s not comprehensive, but you can make GUI apps with it, and they’ll even run on RPi.

https://factoryfactoryfactory.net/

Sure yeah, I’ve done lots of UI programming with Clojure. It works great. I’ve also made small games. Why do you think it would be more difficult than with imperative style?

Typically this is true, but it’s certainly possible to get comparable performance with functional style. Carp, which I linked above, basically uses the same approach to memory management as Rust. It doesn’t rely on GC.

I also find that for most cases it really doesn’t matter all that much unless you’re in a specific domain like writing drivers, making a game engine, etc. Computers are plenty fast nowadays, and ergonomics tend to be more important than raw performance.

Sure, if a big instance started to dominate the fediverse it would be a form of centralization. However, the protocol being designed with federation in mind makes it much easier for people to migrate from that instance if it becomes a bad actor.

Going back to the original point though, I do think that fediverse could be marketed better in a way that would appeal to more people. Since we agree that federation is a desirable feature, the focus should be on figuring out how to explain it to people in a sensible way.

Sure, but all of this basically comes down to poor marketing. It’s not an inherent problem with the technology or with the concept of federation.

It shouldn’t be surprising either given that Mastodon is a niche platform developed largely as a volunteer effort. The reason people advocating Mastodon tend to focus on stuff like on the flaws of the centralized social media is because that’s what matters to them. We see pretty much the same thing happening with Linux, and many other open source projects.

This is the point I was making above, BlueSky has a professional marketing team that understands how to sell their product to the general public. That’s the main reason BlueSky is gaining users at a faster rate.

Regarding the Gmail problem, it’s true that we could end up with one major instance most people are on. I don’t see that as a huge issue in practice since you can still choose use different instances. That’s a fundamentally better situation to be in.

For example, I don’t use Gmail and I run my own personal Mastodon instance using masto.host, this doesn’t stop me communicating with people on Gmail or major Mastodon instances like mastodon.social.

😆

What I’m saying is that the amount of friction this adds is completely blown out of proportion. It’s just not that hard, and people acting like it’s a huge barrier are not being serious. If this was the case email would’ve never taken off. The fact that we’re at the point where it’s hard to imagine a regular user going outside a walled corporate garden is really the problem here.

Unfortunately people aren’t as informed and most really just don’t care.

The flip side is that we shouldn’t care too much either. Fediverse already has millions of users, and it can just keep growing organically at its own pace.

That’s not actually true, modern architecture works much closer to the way functional languages work https://queue.acm.org/detail.cfm?id=3212479

I don’t think there’s a lot of evidence that federation is a significant obstacle in practice. Email is a great example of a federated platform that even the least tech literate people are able to use just fine. It could be argued that Mastodon onboarding process could be smoother, but that’s not an inherent problem with it being federated.

In my view, the simplest answer is that BlueSky has much better marketing because it has a ton of money behind it and it’s been promoted by Dorsey whom people knew from Twitter. So, when people started abandoning Twitter, they naturally went to the next platform he was promoting.

I’d also argue that there is a big advantage to having smaller communities of users that focus on specific topics of interest and can federate with each other. In my experience, this creates more engaging and friendlier environment than having all the users on the same server. Growth for the sake of growth is largely meaningless.

Absolutely, and there’s actually been a substantial amount of research on the subject as well. The way we perceive time is a product of our emotional state, and the environment.

It does, hence why it breaks the paradigm.

Rust solves a specific problem, and it’s good at letting you write correct programs with low resource usage. It’s definitely a huge improvement on C and C++.

That said, I find a language like Clojure is far more productive because it’s more expressive, and development is done interactively. With Clojure, you start up your program, connect the editor to it, and evaluate code as you go seeing changes live. Once you’ve worked this way, it’s really hard to go back to having to compile your whole program each time you want to see what it’s doing. It’s like having a conversation with the compiler. It makes it very easy to experiment with different ways to solve a problem, and it gives a lot of confidence because you always see exactly what the code is doing. Clojure also interops with JVM and Js runtimes, so those entire ecosystems are available for use.

Incidentally, there’s a Lisp style language that embraces a lot of Rust principles. https://github.com/carp-lang/Carp

The. real question is whether this problem needs to be modelled using classes in the first place. The alternative is to just have a set of composable functions that take a piece of data and return a modified version that can be passed to a different function.

Yet, the fact remains that people did get comfortable with email, and even the least tech illiterate people are able to use it.

That’s a recent phenomenon though, and it’s effectively been forced on people by the largest email provider making it difficult to use others. My original point was that people didn’t find it confusing to register for different mail providers when that was easy to do.

You don’t have to make an informed decision. Signing up for an instance isn’t a blood pact. If you find the instance you singed up for isn’t to your liking, You can easily migrate your account to another. Meanwhile, if you’re worried about something you don’t align with, then you don’t even get that choice with a centralized platform like Bluesky. For example, I don’t align with any of this shit https://toad.social/@davetroy/113476788536250587

As a rule, exceptions should indeed be used for behaviors that are outside normal execution flow. For example, you might throw an exception if a file you’re trying to access doesn’t exist, or a network call fails, etc.

There’s plenty of real world code written in functional languages. Also, this idea that FP is somehow more complex is complete nonsense. Lisp family are some of the easiest languages to learn.

Been working in Clojure for over a decade now, and would never never go back to using imperative/OOP at this point.