tomekwWhy do languages, like #rust, for example, need so many new features?
mohs@tomekw the point there is certainly, that they need to have a reason for their existence and their usage. Therefore they need some way to be distinct from others. But also not lacking behind, what others have to offer. It is a competition after all, but not (directly) about money, the competition is about usefulness.
@mohs when you compare that to games: if you constantly need new seasons, battle passes and tons of new content, it means the core gameplay loop is broken.
At least that’s how I see it.
@tomekw that is a bad comparison I think. Because games are used for your entertainment and you use them only for the sake of themself. But a programming language is a tool you use to tinker with other objects.
There is no gameplay loop for a programming language. There is only the question: Is it useful in order to solve the problems you have?
The languages came up, as people saw some problems, that others did not cover, or even created the issues.
Needless to say, that these days most games are similarly evolving over time as long as there is a development happening.
@mohs fair :)
Let me rephrase: I think some languages try to over-engineer things for the sake of doing it, not to make them actually more useful.
PointlessOne 
@pointlessone
I'm not sure what
@tomekw had in mind, when he wrote that. But I can say that I'm quite happy about the async features. They make things easier. Problems mostly rise at the borders of sync and async, but that applies to all languages where that feature exists.
I'm not sure what
@tomekw had in mind, when he wrote that. But I can say that I'm quite happy about the async features. They make things easier. Problems mostly rise at the borders of sync and async, but that applies to all languages where that feature exists.
@mohs To me—a noob—async happy path seems way too narrow. I run into sync/async borders fairly quickly and it doesn't seem like there's an easy fix, I'll have to learn how it works and at the moment it seems kinda complex. Not the basic idea but the actual implementation. This feeling is also backed up by seemingly regular appearance of posts about edge cases and how to deal with them and those posts are like a good chapter of a book. Or the other day I saw a 30 minutes video that explained like a dozen concepts that go into a 2-line async function definition that has almost all sigils in it and half a dozen traits/generic type and all are required to make it work.
@pointlessone it becomes easy if you setup your application to start with an async context. because calling a sync function from async is easy. The other way around is harder. Although there are okayish abstractions to make these not too hard to do. The problem is, asynchronous code is always adding a layer of complexity, that you have to get done right. The alternative to that is to deal with threading explicitly. In a limited context that might be easier.
I once implemented an esp32 with the task of collecting data and forwarding that into a logging system somewhere in the internet.
For that I didn't use async, but threads, as it was predefined how many I will need.
A webserver is a totally different scenario.
So it depends what is easier to do.
@tomekw
I once implemented an esp32 with the task of collecting data and forwarding that into a logging system somewhere in the internet.
For that I didn't use async, but threads, as it was predefined how many I will need.
A webserver is a totally different scenario.
So it depends what is easier to do.
@tomekw
@mohs I kinda want to try and do a dumb thread-pre-request web server just to see how slower it would be but also to see how everything sync within a request feels. I mean, it will be slower but do we care if it's 50 ms instead of 2 ms? But also all sync is much easier mentally, at least when coming from other languages that have no async.
@pointlessone
You can do this task from the rust-book: https://doc.rust-lang.org/stable/book/ch21-00-final-project-a-web-server.html
that is pretty much what you described.
Note: There is also a separate async book.
@tomekw
You can do this task from the rust-book: https://doc.rust-lang.org/stable/book/ch21-00-final-project-a-web-server.html
that is pretty much what you described.
Note: There is also a separate async book.
@tomekw