Post 3296637 by kornel@mastodon.social
 (DIR) More posts by kornel@mastodon.social
 (DIR) Post #3277826 by amiloradovsky@functional.cafe
       2019-01-23T05:17:37Z
       
       1 likes, 1 repeats
       
       It's kind of tempting to rewrite some/all of my old #C/C++ utilities in #Rust, just to develop some more intuition of the linearity and familiarize myself with the infrastructure a little bit better. It shouldn't even take much time, it seems. Are there a caveats?
       
 (DIR) Post #3278148 by pounce@cmpwn.com
       2019-01-23T06:29:19Z
       
       0 likes, 0 repeats
       
       @amiloradovsky There can be a barrier to rewriting in rust, particularly if you're only partially switching things over, FFI be not very fun to deal with.Also there's the ordinary things to deal with in rust like the borrow checker and strict typingbut honestly it's not that bad. once you start to feel what a rust program is like, writing it becomes a lot easier.
       
 (DIR) Post #3278851 by kwarrtz@mathstodon.xyz
       2019-01-23T05:19:58Z
       
       0 likes, 1 repeats
       
       @amiloradovsky Makntainability, perhaps. Rust is still a somewhat immature language, so a few years from now the entire ecosystem may have changed and made your tools difficult to support. Certainly not trying to dissuade you though. I love Rust, and the ecosystem is becoming more stable and mature every day.
       
 (DIR) Post #3278895 by veer66@toot.veer66.rocks
       2019-01-23T07:05:20.497778Z
       
       0 likes, 0 repeats
       
       @kwarrtz @amiloradovsky I fixed quite a lot of things in my Rust codebase from last year to build by 1.32 and latest #reqwest (lib).
       
 (DIR) Post #3296636 by amiloradovsky@functional.cafe
       2019-01-23T09:23:22Z
       
       0 likes, 0 repeats
       
       Turns out #Rust doesn't have any ready-to-use random number generation facilities: all there is is controversial information about something called `rand`…
       
 (DIR) Post #3296637 by kornel@mastodon.social
       2019-01-23T18:08:12Z
       
       0 likes, 1 repeats
       
       @amiloradovsky rand used to be a part of the built-in standard library, but has been removed from it. The recommended way is to depend on crates.io crates. This way each program can use the version it wants, and the core language doesn't have to be stuck with the first version of the API forever.
       
 (DIR) Post #3311868 by clacke@libranet.de
       2019-01-24T04:19:11Z
       
       0 likes, 0 repeats
       
       @kwarrtz @amiloradovsky I thought the Rust lib was supposed to be stable since 1.0?
       
 (DIR) Post #3463500 by amiloradovsky@functional.cafe
       2019-01-24T08:33:36Z
       
       0 likes, 0 repeats
       
       "[…] it is assumed that #Rust projects will use #Cargo from the beginning." — Yeah, makes sense, and also that the #Git repository and the initial commit will be made before any code is even written. Eventually it should become #Pijul though.
       
 (DIR) Post #3463501 by amiloradovsky@functional.cafe
       2019-01-24T09:01:24Z
       
       0 likes, 0 repeats
       
       I'm only not sure what would be the #OCaml's analogue, just #ocamlfind (findlib) or full-blown #OPAM. It actually isn't obvious for me how these two are related. It becomes even more complicated when we introduce #Coq's libraries…I actually once used #Nixpkgs for building & testing. The advantage is that it isn't language-specific. Disadvantage though was that I needed to generate patches and place them where they belong, every time I want to (re)build it, then wait pretty long time.