4 ms·
As someone that writes a bunch of go but has never really gotten off the ground with rust: * Option? I don't mind if err != nil, but sure, it would simplify
by justinsaccount 4y ago
As someone that writes a bunch of go but has never really gotten off the ground with rust:
* Option? I don't mind if err != nil, but sure, it would simplify some things.
* Result and real tuples? awesome.
* real enums? sign me up.
If that was all added to go I wouldn't mind at all. But what does any of that have to do with
impl<'a, H, Fut, Tail> Execute<'a> for Dispatcher<H, Tail>
where
H: Fn(&'a Update) -> Fut + Send + Sync + 'a,
Fut: Future<Output = ()> + Send + 'a,
Tail: Execute<'a> + Send + Sync + 'a,
{
- int_19h 4y agoIt is a serialization of relative lifetimes, basically. Whenever you write code in any language that doesn't have a GC, you either have to maintain a mental map like this to avoid bugs, or you make the language do it for you like Rust does.
- 0des 4y agoShit like this makes my brain hurt
- timcavel 4y ago
- dgunay 4y agoIt doesn't, primarily the way I saw the discussion heading was (warning: strawmen ahead): > "Go is a good alternative to Rust because it is easy to write performant, concurrent code" > "Go is not very comparable to Rust. I won't describe why, here's a quote by Rob Pike and I'll strongly imply it's because its creators deliberately avoided complexity, even where useful." > "You did not explicitly criticize anything about Go, therefore it must not have flaws" Then I came in and described exactly where I feel Go ignores the state of the art in PLs. > But what does any of that have to do with (Rust-shaped vomit) Go doesn't need all those type system gymnastics because it does not have the problem of the borrow checker to deal with and doesn't promise to avoid segfaults for you.