# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 34
# self = https://watcher.sour.is/conv/j6mz62q
🦀 “How do you do $foo in Rust?” – “Use this create: …” That’s another symptom of the language being very young. Well, or maybe I’m just spoiled by Python and its very extensive standard library. 🤔 Still, I’m not too happy with pulling in tons of dependencies that all have versions like “0.4.0”.
🦀 “How do you do $foo in Rust?” – “Use this create: …” That’s another symptom of the language being very young. Well, or maybe I’m just spoiled by Python and its very extensive standard library. 🤔 Still, I’m not too happy with pulling in tons of dependencies that all have versions like “0.4.0”.
🦀 “How do you do $foo in Rust?” – “Use this create: …” That’s another symptom of the language being very young. Well, or maybe I’m just spoiled by Python and its very extensive standard library. 🤔 Still, I’m not too happy with pulling in tons of dependencies that all have versions like “0.4.0”.
@movq Yeah, that's what I'm experiencing all the time as well (and I'm just following, not actively contributing Rust code). Just reminds me of the JS ecosystem. Welcome to dependency hell.
@movq @lyse Seems like it’s heading down the NodeJS pattern 🤦♂️
@movq @lyse Seems like it’s heading down the NodeJS pattern 🤦♂️
@prologic Yeah, at least from the outside it looks like a dangerous similarity.
@lyse @prologic To be fair, I’ve often heard the rumor that they want to let code mature in “Crates” (external dependencies) before they eventually merge it into the standard library. I’m not involved enough to cite any examples, though, so take this with a grain of salt. 🤔
@lyse @prologic To be fair, I’ve often heard the rumor that they want to let code mature in “Crates” (external dependencies) before they eventually merge it into the standard library. I’m not involved enough to cite any examples, though, so take this with a grain of salt. 🤔
@lyse @prologic To be fair, I’ve often heard the rumor that they want to let code mature in “Crates” (external dependencies) before they eventually merge it into the standard library. I’m not involved enough to cite any examples, though, so take this with a grain of salt. 🤔
@lyse @prologic On the other hand, I’m not sure if that approach even works. If you let a project “mature” outside of the standard library, that project might very well do things that are not compatible with said standard library. Like, it might pull in another external dependency (which it very likely does). So what happens then, when you want to merge that into core? You merge both projects? Rewrite one of them? Hardly. 🤔 Maybe this idea of “letting it mature in a crate” is only meant for stuff developed by the core Rust team itself? 🤔 That’d be a very different story then …
@lyse @prologic On the other hand, I’m not sure if that approach even works. If you let a project “mature” outside of the standard library, that project might very well do things that are not compatible with said standard library. Like, it might pull in another external dependency (which it very likely does). So what happens then, when you want to merge that into core? You merge both projects? Rewrite one of them? Hardly. 🤔 Maybe this idea of “letting it mature in a crate” is only meant for stuff developed by the core Rust team itself? 🤔 That’d be a very different story then …
@lyse @prologic On the other hand, I’m not sure if that approach even works. If you let a project “mature” outside of the standard library, that project might very well do things that are not compatible with said standard library. Like, it might pull in another external dependency (which it very likely does). So what happens then, when you want to merge that into core? You merge both projects? Rewrite one of them? Hardly. 🤔 Maybe this idea of “letting it mature in a crate” is only meant for stuff developed by the core Rust team itself? 🤔 That’d be a very different story then …
@movq I dunno, maybe 🤔 But I just can't bring myself to bother with #rust-lang myself 🤣
@movq I dunno, maybe 🤔 But I just can't bring myself to bother with #rust-lang myself 🤣
@movq @prologic Yeah, I doubt, that this approach really works in reality. The theory, however, sounds pretty neat. If projects were started with this exact goal, they might succeed, but I still have my reservations. Admittedly, I don't know of any example, neither succeeding nor failing (or not succeeded yet?).
@lyse @movq @prologic IIRC, the story around rust async was a good example of letting things mature in libraries. They added macros for the keywords but then delegated the implementations to the ecosystem and then formalized stuff with proper language keywords and interfaces when stuff settled. I believe C++ has a similar model in that stuff tends to bake in boost before entering into the standard library.
@brasshopper The problem with programming languages however is that if enough people get involved you end up with a form of confirmation bias where the language devolves into a state of high complexity with features from every other language drawn from the experiences of those that contribute to it so you lose all of the simplicity and elegance of the original language. It happened to C++, Java, Python and many other languages over multiple decades.
@brasshopper The problem with programming languages however is that if enough people get involved you end up with a form of confirmation bias where the language devolves into a state of high complexity with features from every other language drawn from the experiences of those that contribute to it so you lose all of the simplicity and elegance of the original language. It happened to C++, Java, Python and many other languages over multiple decades.
@prologic I totally agree. If I ever make a programming language, I really want to find a way to make removing features a regular part of the process. Rust definitely feels like it’s heading in the direction of complexity. However, I did see a ray of hope in a recent talk from rust conf. One of the co-leads for the language suggested removing features.
@prologic As an aside, this is one thing I admire about Haskell. Its “core” language (sort of like an IR) can fit on a note card. I believe that someone fit it in a tweet. Haskell syntax and type system is more complex though. See this talk by FP God-king Simon Peyton Jones for more about that: https://youtu.be/uR_VzYxvbxg
@brasshopper I just watched that talk, it is brilliant! Very cool.
@lyse While I think some parts of the FP (and Haskell especially) community can get into abstraction for the sake of abstraction. They do have some cool ideas. I think this is one of them.
@lyse haha what do you think?
@brasshopper I'm really not sure. ;-) But since Haskell has its roots in academics, I reckon it is fine to go a bit overboard.