drogus

14 ms·

91.
by drogus 4y ago
I worked mainly in web dev for almost 2 decades now and having programmed both with Rust and Go, my vote would be to default for Rust, so I guess you everyone's mileage may vary. Also the argument about the stdlib is kind of weird. It&
92.
by drogus 4y ago
It will get even simpler when 1.63 hits with the `static` `Mutex::new`: use std::{sync::Mutex, thread, thread::sleep, time::Duration}; fn main() { static MUTEX: Mutex<String> = Mutex::new(String::new()); le
93.
by drogus 4y ago
I think the business logic point would have some people disagreeing. I talked to a VP of Engineering of a company using Rust and Elixir and he said their heuristic of when to choose Rust is "will the requirements change a lot over time
94.
by drogus 4y ago
Depends on what you're doing. There are apps that can be written in Rust much more quickly than in other services, cause you don't have to worry about a lot of stuff (like for example it's hard to keep an open connection for
95.
by drogus 4y ago
These comments are still in context of using the language in a startup. Good luck with finding Ocaml, F# or Scala devs.
96.
by drogus 4y ago
> I recently picked up Python again to write a simple REST API, and the process is just so much faster For me it's much more important how will it work in the next few years, not how quickly you can write it. If I could, I would use
97.
by drogus 4y ago
There are plenty of Rust devs looking for work outside of embedded. Also, for me Rust's speed is one of the benefits. I would default to Rust for a lot of different things where speed doesn't matter at all.
98.
by drogus 4y ago
That's a good point and I think I will add a paragraph or too about that. The simplest answer is: as long as you're not doing any unsafe Rust you should just use whatever is derived from types within a type. If you have a struct w
99.
by drogus 4y ago
You should also check out Gleam! https://gleam.run/ It's almost like Rust and Elixir had a baby :D As for the rest of the comment: totally. Almost none of the code I write in Rust needs C-like performance and I still c
100.
by drogus 4y ago
> in a typical language you can easily pass by reference between components and threads. and that's when you usually get data races ;) > In rust the unspoken rule seems to be to allocate, allocate, allocate - unless you are writi
101.
by drogus 4y ago
I disagree. I write Rust, I write mainly async Rust and while my code is maybe not the most sophisticated I use a lot of async traits and generics. I still find it one of the best languages I know, definitely my favourite for all around cod
102.
by drogus 4y ago
I think it depends on what you call hard. Things you listed usually make things unergonomic, not necessarily hard. You can still do a lot of stuff with async Rust, but it often requires a lot more boilerplate and compromises. Granted, it ca
103.
by drogus 4y ago
> From the perspective of language design, this manifests a failure to design an orthogonal language. I wanted to convey this observation in my post. I wouldn't say it's a "failure". It's an incremental design. T
104.
Async Rust doesn't have to be hard(itsallaboutthebit.com)
277 points by drogus 4y ago|188 comments
105.
by drogus 4y ago
I have recently written a blog post about `Arc` and `Mutex` if you want to get an in-depth view on using them: https://itsallaboutthebit.com/arc-mutex/
106.
by drogus 4y ago
> At this point wouldn't it be better to just use a regular GC language? No, because you wouldn't slap `Arc` on every single variable. The example from the blog post is a dispatcher and `Arc` is then needed for dispatched funct
107.
by drogus 4y ago
As @therockhead replied already: you won't put every single variable behind `Arc`. It will only be for shared state: queues, handlers that you need to move between threads/tasks etc.
108.
by drogus 4y ago
The last paragraph is the key. Just use `Arc` or `Arc<Mutex>`, it will be fast enough. That's why my first article on a new blog is precisely about that: https://itsallaboutthebit.com/arc-mutex/
109.
by drogus 4y ago
No it's not. There are tradeoffs, definitely, and one of them is visible in the article: at the moment doing lifetimes and async is hard. But you don't have to do it, most of the time you use `Arc` or `Arc<Mutex>` and call i
110.
by drogus 4y ago
Just use `Arc`, it's fine, it will be plenty fast.
111.
Arc and Mutex in Rust(itsallaboutthebit.com)
4 points by drogus 4y ago|0 comments
112.
by drogus 4y ago
Looks interesting! Do you plan to create an SDK? Or is interfacing with the HTTP API will be the best way to use the app for now?
113.
by drogus 5y ago
> I feel like you’re getting defensive, although I wasn’t attacking you. If that’s how I came off, I apologize. I mean, you implied that people with performance anxity are just fragile people who will break down when an outage occurs and
114.
by drogus 5y ago
I'm not sure why everyone here is so focused on the word "triggered". Some kind of an obsession? Yes, it's in the quoted tweet, but I haven't used it anywhere and you're responding to my comments. And then, in
115.
by drogus 5y ago
Thanks for clarifying too! Regarding progressing I think it's for the better. It was about two years ago I didn't have much issues with finding something else (I brought it up only cause Shopify was mentioned in a tweet that start
116.
by drogus 5y ago
Author of the tweet here. > Hard disagree on that. “Triggering”, huh? I’m sure for some people, the idea of life not delivering to you exactly what you want, and when you want it, is triggering too. I think that you're purposefully
117.
by drogus 5y ago
Author of the tweet here. I don't think that companies do this consciously, but I think the problem with your take is that your comment seem to assume that performance anxiety is somehow related to being "triggered" when peop
118.
by drogus 5y ago
I'm curious, what are the types of other things that you do and which people want to rewrite to Rust? In general I'm very much against any rewrites without a clear list of things that are lacking in the current implementation, det
119.
by drogus 5y ago
This is an early version of the project, so this is most likely not directed at end users. Why would you even address end users at this point? Nobody will use it for a long time anyway, so in my opinion is a great move to address potential
120.
by drogus 5y ago
This site is for developers, isn't it? For me this is interesting, cause I could see myself contributing to a Rust project, I'm guessing there's more people who think that way.

More ›