React and the ecosystem. I wanted to be clear that I don't "hate" the React team. They are smart people and are trying to do a great job. The passion is definitely there. But they should IMHO focus on different things.
LLMs do NOT have intelligence. Achieving AGI would mean solving self-driving cars, replacing programmers, scientist, etc. All things LLMs are currently unable to do in a way that replaces humans.
There's a huge gap between what Gemini 3 can do and what AGI promises to do. It's not just a minor "technical definition".
You are so brainwashed by app stores' talking points that you don't realize you are describing computers.
Just let users install whatever they want. Maybe add a verification process (a-la app verification for Mac) if users want to be restricted to verified apps. Show a "this is from an unverified developer" messages if the app comes from an unverified developer (is not signed).
There's no need to draw lines. Leave that to painters and architects.
> At a guess, people will use something with:
- Strong tooling and libraries
- An accessible type system
- Deterministic memory behaviour
- By-default strict evaluation
- Commercial backing
Every mainstream functional language is lacking in at least one of these areas.
Rust’s type system is very close to Haskell’s and takes a lot of inspiration from functional programming.
I’m not sure I’d call Rust mutable-first either. As for side-effects, I suspect the next leap in PL development will be an efficient algebraic-effects system with a good dev experience (or at least a trade-off so appealing it overcomes the necessary friction).
> Rust’s type system is very close to Haskell’s and takes a lot of inspiration from functional programming.
Well… No.
It misses some landmark features like HKTs, and it likely never won't get them.
Inspiration? Sure. But what lang today doesn't take that?
> I’m not sure I’d call Rust mutable-first either.
So what do the affine types track? ;-)
> As for side-effects, I suspect the next leap in PL development will be an efficient algebraic-effects system with a good dev experience (or at least a trade-off so appealing it overcomes the necessary friction).
Let's make "some effect system" out of it and I'm with you.
But it likely won't be Rust getting such features in the near or midterm future (no clue about such a possibility in the far future, though).
Other languages are almost there on the other hand side. Scala for example will get "ability tracking" real soon™ now.
Rust may seem a little bit like a FP lang at frist if you're coming form one. But after writing some code you going to realize that Rust's philosophy is quite different form a FP lang: Rust embraces mutability and side-effects at its core! It "just" tries to make that more safe.
Thing is, the constraints that make mutability and side effects "safe" are pretty much indistinguishable from functional programming. You can opt out of those in Rust via "internal mutability", but that comes with a corresponding increase in complexity.
I don't think Rust can enforce referential transparency, nor does it have any focus on doing this manually. But I would say referential transparency is one the most important properties in functional programming, if not even the most distinguishing property.
Referential transparency is the one feature that makes reasoning about a program easy. You can think about referential transparent programs purely in the substitution model. You can move referential transparent expressions freely around as you please.
You can't think of a Rust program this way. It's inherently procedural.
Rust gets a lot of things quite right! But it's not a FP language. It's a better C. It's about shoveling bits and bytes around, as safely and efficient as possible.
For most practical purposes, Golang and Java cover this. Rust / C++ is great is systems stuff, I am not going to use it for some application layer stuff, with all complexities that come with it.
I find it pretty hilarious that “too much micro libraries” is a criticism, but then you recommend TypeScript - which runs on Node.is, the progenitor of “micro libraries” in the next sentence.
We’ll ignore every other bullet point containing fundamentally incorrect information also.
I've used both substantially, Telegram for the past 2-3 years, Signal since it was Textsecure.
The primary concern is that messages in Telegram aren't encrypted by default. But that's been the case for a lot of messengers and tbh for large groups privacy really can't be assumed on any E2E solution. (yes, technically but practically it wouldn't be the case)
The Telegram creators are also extremely cocky and the encryption they do use is non-standard and done mostly in-house. It backfired on them a little with MTProto which they've fixed in v2, but it doesn't make cryptographers confident.
Signal and Telegram have wildly different philosophies on what it means to be secure. Telegram refuses to implement E2E on desktop clients citing it being too large of an attack surface (I am inclined to agree with them). They emphasize ephemerality of conversations in a way Signal doesn't do (E2E chats in Telegram and frequently brought up and torn down, Signal instead just has self-destructing messages).
Finally, look at the creators' motivations. Moxie is having to sell double-ratchet stuff to the likes of Facebook and relies on Amazon and Google to run the service. Pavel is several orders of magnitude more rich, has been outspoken against Putin, and can afford to fund anything he needs done on Telegram. I'm not claiming either is more trustworthy, but motivations are radically different.
Security aside, Telegram is just so much more pleasant to use, and I think that’s what wins users over more effectively than probably anything except network effects.
Usability on Telegram is fantastic in how it syncs messages between devices and allows editing/deleting them. I see its security as good enough for my risk model, which is primarily keeping my chats out of the hands of Facebook, Google, and other predatory tech giants with a history of playing fast and loose with user data.
