tomekwWhy do languages, like #rust, for example, need so many new features?
Marsh Ray@tomekw There are simple languages, but they stay “simple” by pushing lots of complexity into library code.
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
@tomekw idunno. WoW did expansions fairly well. Guild Wars 2 had regular content drops as well. And now it’s just what people expect. You can’t just release a game and expect people to keep playing it forever. Even the most engaging game loop becomes stale after all variety is exhausted.
This doesn’t map that well on PLs as you come up with your own content drops all the time.
Michał Fita@tomekw Not all of them require, many factors at play.
But #Rust to guarantee safety brings abstractions to a very high level, in result, to allow flexibility in getting things implemented fast it needs a lot of (proven) features. Some may argue these may be ceded to libraries (crates), but then we have a scrutiny issue of our supply chain.
@michalfita does it NEED them, actually?
Call me an ignorant, and by no means I want to fight #Rust. I’m happy it exists and it’s great. I just think we, as people, love to reinvent the wheel. I can’t stop thinking we had Rust 40 years ago, but simpler and called #AdaLang.
@tomekw Nope, we didn't. #Ada has safety mechanism utilised in run-time, like #Pascal does. #Rust is first language with practical implementation of a compile-time borrow checker for native compiler, while the actual science behind it wasn't new.
In #Ada productivity is low as you have to chisel your code, compile and run to check for correctness, while in #Rust the compiler stops you for knee-shooting attempts.
@michalfita I think it works both ways: if you don’t know #AdaLang well enough, you have to fight the compiler, if you don’t know #Rust well enough, you have to fight the compiler / borrow checker as well :)
I do not agree with the sentiment of one tool being more or less productive than the other: I am amazed how productive I am with Ada.
Skills > tools.
@tomekw I'm more productive in #Rust than in #Python. The consistent nature of the standard library makes conversion of thoughts into code easier and less prone to stupid flops, that Python then throws at you during run time.
I didn't program in #Ada, I read about it, run some example and talked to some people using it. The opinion circulating about it is that it can be tedious to write large Ada applications or even systems.
Ray Kelm@michalfita @tomekw Rust solves a class of errors that require more knowledge to solve in C, but a really good C programmer would avoid those errors as well. Rust is more about ensuring that ALL programmers can avoid those kinds of errors. The cost though is more complexity when writing your code. That complexity does reduce coding speed on average.
@rayk @tomekw I'm good C programmer and I can avoid those errors, I worked with good C programmers who can avoid those errors.
Yet, we as a team were sending releases out that were crashing in extensive tests or even in the field. Results of our collaborative work and complex merges, despite out great efforts in review (who remembers #Fagan inspections?) ended up buggy and unsafe.
We had static analysers with licenses costing $20k/seat/y and we still had crashing code.
1/2
@rayk @tomekw It's my experience that convinced me the #Rust is the right way, despite things I don't like or lack of things I like.
The reason of why new projects in #Rust pop up like mushrooms are in fact Rust's complex features and safety mechanisms. It makes people confidently build more advanced stuff quickly.
2/2
@michalfita I’m sceptic about “more advanced stuff quickly”. My prime evidence: web frameworks. Everything I saw in Rust is barely at the level of the most primitive frameworks in Ruby/Python. Rails is being shat on for being a resource hog and stale and stagnant but it's literally decades ahead in terms of features and DX. Sure, your axum microservice can handle a billion requests a second but you spend 2 days building a mildly complex form while in Rails you can build a whole damn blog/cms in 15 minutes.
@pointlessone @rayk @tomekw I'm afraid you have biased view. There are two angles to the "web frameworks".
1. #Axum and #Rails don't even play the same sport, the former's performace comes at cost of orders of magnitude more complex implementation; it was never intended to be #Django in #Rust
2. The fact we have web frameworks in Rust is "an accident", the language was never intended to specifically write ones. Rust is a proper system programming language, the same class as C (not #Go w/GC).
@michalfita I'm not sure what point you're trying to make.
I didn't mean Axum specifically. I can accept that it put its complexity budget into performance but why noone else put “more advanced stuff” on the features and DX budget?
Ruby wan't built for web apps either. It was (and is) a general purpose scripting language. In a way, Rails is an accident, too. There was nothing inherently web-oriented that made it uniquely suited for web frameworks. When Rails started there wasn't even a proper web-server in Ruby. It was plain CGI. So what stops Rust from having an advanced web framework? Let's say, it wont be as fast as Axum but surely it will be faster than Rails. Isn't that enough? Especially if it’s feature set and DX even remotely resembling Rails with types and memory safety on top. Why doesn't anyone build an advanced Rails in Rust?
@pointlessone @rayk @tomekw There are frameworks in the making aiming for that, more over there are frameworks aiming at that with use of WebAssembly instead of JavbaScript on the browser side. It's just complex problem to crack. Rails is 21 years old.
The point was you're focused on web frameworks ignoring tons of other stuff built from zero within last 5-6 years, including adding #Rust to #Linux Kernel, #RedoxOS, #Cosmic Desktop and embedded ecosystems.
Georg Semmler@pointlessone @michalfita @rayk @tomekw I think I can at least give you all a clue on why such thing does not exist (yet?). From my perspective as someone in a position to potentially write such a thing the main thing missing is funding and potentially capacity to work on such large expansions. For context: I have some prototype stuff laying around that would make writing that crud stuff much easier for years now, I just do neither have the funding, the capacity nor the manpower to got it into an state to make it public in any reasonable way. If you know how to fix that I‘m happy to hear your suggestions