|
i think theyre harder than monads tbh but i kinda like both
|
#
?
Dec 19, 2016 11:41
|
|
|
|
| # ? May 22, 2024 14:24 |
|
|
Also God I would love named arguments, as the builder pattern doesn't give you compile time checking that you've given all of the required names args without some serious wankery (some kind of phantom data state machine based on which of the builder methods that you've called so far) Unfortunately it's just getting bikeshedded to hell the last time I looked
|
|
#
?
Dec 19, 2016 11:41
|
|
|
here's a rust condundrum: you are writing a collection, and want to look up a key let's write the type signature: fn get(&self, key:String) -> Option<String> wait wait no, we don't want a String, that's an owned value. when you read a owned value, you destroy it. x = y leaves y null. if we passed in this, we would have to create a copy of the key each time to look up. wait, i guess we can write another method fn get(&self, key: &str) -> Option<String> nice. ok, we look up a key and uh, we return an owned value. ok. maybe we could copy the value each time we look up but we'd be doing an allocation. hrm. what about fn get(&self, key: &str, out: &mut String) -> bool ok, right, we pass in a mutable reference to a String, something owned, we can skip the allocation, overwrite out + return true can we look up a value in a collection, and not copy the key, or copy the value, let's try again we could use reference counting i guess fn get(&self, key: Rc<String>) -> Option<Rc<String>>) although Rc<String> turns to &str automatically, but i guess gently caress it and use generics fn get<K,V>(&self, key: &K) > Option<Value> it's the consumer's problem now ha ha. why can't we do fn get(&self, key: &str) -> Option<&str> i guess we could, that makes a nice signature i'm just not sure how to borrow a value and extend the lifetime such that the reference &value outlives the function wait what fn get(&self, key: &str) -> Option<&'a str> but now that's a valid reference for the entirety of the scope, so uh, if i replace a value later, what does that reference point to ok, what if we return a new Object, an Entry<String> with a method .get() that returns &str and then when we de-allocate entry, we unborrow, so those references from .get() will go out of scope so the lifetime is fine
|
|
#
?
Dec 19, 2016 12:00
|
|
|
gonadic io posted:Rust's lifetimes have a learning curve just as bad as haskell's monads. It'll be interesting to see if Rust gets a similar rep or if the more intuitive name is enough to avoid it. it's explained like monads: "here's 3 rules now form a type checker" but the borrow checker, well, y'know there's something disappointing when you find pointers all over the insides of rust's data structures tbh it kinda comes off like checked exceptions in terms of busy work, except way, way harder to fix
|
|
#
?
Dec 19, 2016 12:02
|
|
|
i feel like the problem with lifetimes is entirely syntactic. at least, that's what I'm struggling with. the struggle with monads was (fine, is) more conceptual. quote:but the borrow checker, well, y'know there's something disappointing when you find pointers all over the insides of rust's data structures i mean, it's just sort of an implementation detail DONT THREAD ON ME fucked around with this message at 12:07 on Dec 19, 2016 |
|
#
?
Dec 19, 2016 12:04
|
|
|
i am getting to be rather persuaded that unfortunately there will never be a broadly accepted language with more advanced typing than what we have managed to drag into e.g. java, and even that is pushing it a bit not due to incompetence, rather there seems to be a lot more impedance in how the systems apply to the way we think about programming than one would expect from looking at it on paper
|
|
#
?
Dec 19, 2016 12:06
|
|
|
actually something that seems to suck about rust atm is that you kinda need to use nightly if you want to use any of the cool libraries and nightly is frequently broken.
|
|
#
?
Dec 19, 2016 12:13
|
|
|
gonadic io posted:Also God I would love named arguments, as the builder pattern doesn't give you compile time checking that you've given all of the required names args without some serious wankery (some kind of phantom data state machine based on which of the builder methods that you've called so far) yeah like, cargo is interesting but i've already whacked a Makefile into my project to set environment flags also, again, the semi-colon, seriously, an invisible semantic operator
|
|
#
?
Dec 19, 2016 12:14
|
|
|
well you've convinced me to skip rust for a while
|
|
#
?
Dec 19, 2016 12:14
|
|
|
tef posted:also, again, the semi-colon, seriously, an invisible semantic operator
|
|
#
?
Dec 19, 2016 12:17
|
|
|
redleader posted:well you've convinced me to skip rust for a while i mean, rust doesn't look c++ hard, but it still looks pretty hard
|
|
#
?
Dec 19, 2016 12:20
|
|
|
Cybernetic Vermin posted:i am getting to be rather persuaded that unfortunately there will never be a broadly accepted language with more advanced typing than what we have managed to drag into e.g. java, and even that is pushing it a bit nah, i reckon local type inference + some generics will be broadly implemented the hard part is covariance or contravariance  which would be less of a problem if we used structual typing and not nominative typing so much i m h o but i said this to a real compiler writer and they had quite serious opinions so it's more like in my not-very-well-informed opinion.
|
|
#
?
Dec 19, 2016 12:20
|
|
|
redleader posted:well you've convinced me to skip rust for a while unsafe rust is actually pretty ok, and makes up for a lot of the problems with safe rust but then you're using rust because of the generics, typeclasses, library system, and stuff rather than y'know the safety bits, but you never really had them anyway
|
|
#
?
Dec 19, 2016 12:23
|
|
|
redleader posted:i mean, rust doesn't look c++ hard, but it still looks pretty hard a big difference is you can use rust as a total beginner and not really shoot yourself in the foot.
|
|
#
?
Dec 19, 2016 12:26
|
|
|
i'm still learning it and i am a grumpy poo poo
|
|
#
?
Dec 19, 2016 12:28
|
|
|
MALE SHOEGAZE posted:a big difference is you can use rust as a total beginner and not really shoot yourself in the foot. or put the round in the shotgun
|
|
#
?
Dec 19, 2016 12:29
|
|
|
tef posted:or put the round in the shotgun
|
|
#
?
Dec 19, 2016 12:30
|
|
|
also the rust programming community is probably the best programming community outside of these here forums and that's quite a thing
|
|
#
?
Dec 19, 2016 12:36
|
|
|
I have high hopes for swift, that's my programming language kokoro wish
|
|
#
?
Dec 19, 2016 12:41
|
|
|
tef posted:here's a rust condundrum: this is probably easier than i'm making it out but who knows
|
|
#
?
Dec 19, 2016 12:49
|
|
|
MALE SHOEGAZE posted:i still dont really understand the justification for this one i think the justification is rust is an expression based language instead of a statement based language, but it's pretending to be a statement based language so it doesn't scare c programmers away. all the semicolon really does it turn an expression into a statement
|
|
#
?
Dec 19, 2016 12:59
|
|
|
but i think in rust a statement is basically just an expression with a value of ()
|
|
#
?
Dec 19, 2016 13:00
|
|
|
but i might be wrong. im an idiot.
|
|
#
?
Dec 19, 2016 13:00
|
|
|
fart simpson posted:but i think in rust a statement is basically just an expression with a value of () this is my understanding, but remember also that the last expression of a block is implicitly returned. i think this can often be surprising, c/java at least make you put "return;" at the end but rust happily just finishes gonadic io posted:Also God I would love named arguments, as the builder pattern doesn't give you compile time checking that you've given all of the required names args without some serious wankery (some kind of phantom data state machine based on which of the builder methods that you've called so far) i think the only "good" solution to this is to make a special struct for your mandatory params, and have that be required to construct a builder to your arguments. then any builder methods that you call on it are for the optional args. so to summarise: to work around the lack of named args, just make 2 bespoke structs that are only ever used for calling this one method, one of which has individual pub fields for each mandatory arg and one has individual pub methods that update private fields for each optional arg.
|
|
#
?
Dec 19, 2016 13:27
|
|
|
error-chain is so good though. if only i could write something non-trivial enough to encounter runtime errors.
|
|
#
?
Dec 19, 2016 13:32
|
|
|
gonadic io posted:this is my understanding, but remember also that the last expression of a block is implicitly returned. i think this can often be surprising, c/java at least make you put "return;" at the end but rust happily just finishes it's not that the last expression of a block implicitly returns it's that every block is itself an expression with a value.
|
|
#
?
Dec 19, 2016 13:59
|
|
|
MALE SHOEGAZE posted:error-chain is so good though. after work today i'm going to put it into my underhanded rust submission https://github.com/djmcgill/under-the-table
|
|
#
?
Dec 19, 2016 14:13
|
|
|
tef posted:this is probably easier than i'm making it out but who knows code:Destroyenator fucked around with this message at 15:39 on Dec 19, 2016 |
|
#
?
Dec 19, 2016 15:34
|
|
|
Bloody posted:it'd be good if it wasn't browser based i exclusively use the console version
|
|
#
?
Dec 19, 2016 16:04
|
|
|
tef posted:why can't we do i think this works? the reference you return should get the same lifetime as &self, which is good if self owns it, and the caller can copy it if they want it to live longer, or if they want to mutate &self (part of rusts lifetime elision rules, you could also spell out the lifetimes explicitly to tie the return value to the self input) a related thing that annoys me is that you have generics that seems like the "obvious" way to do it, but then the actual signature for get() is code:i don't quite understand how it works, and it probably makes sense and solves a problem, but it feels like the kind of C++ thing where you write a simple implementation and it works but then a week later you'll go "oh haha, i didn't handle references/const, i'll need to rewrite this" and in Rust it feels like it will be "oh haha, i didn't handle mut / String/str duality or something, i'll need to rewrite this using Borrow and AsRef" just the thing that ends up in a "best practices" guide with "here's what everyone does at first, here's the nonobvious way you should do it instead"
|
|
#
?
Dec 19, 2016 16:24
|
|
|
did someone write a rust numerics and data frame lib yet
|
|
#
?
Dec 19, 2016 16:29
|
|
|
semicolons in rust just made sense to me as 'and then', where 'and then nothing' is unit, like how a totally empty block returns unit as well. idk i don't see what the issue is. it makes more sense to me than eg python where if you don't put a return at all it implicitly adds 'return None' to the end of your function
|
|
#
?
Dec 19, 2016 17:23
|
|
|
redleader posted:well you've convinced me to skip rust for a while idk why anyone would consider it in the first place.
|
|
#
?
Dec 19, 2016 18:12
|
|
|
Weekend Bridges posted:semicolons in rust just made sense to me as 'and then', where 'and then nothing' is unit, like how a totally empty block returns unit as well. idk i don't see what the issue is. it makes more sense to me than eg python where if you don't put a return at all it implicitly adds 'return None' to the end of your function pretend i posted something about monads, programmable semicolons, and bind being renamed andThen
|
|
#
?
Dec 19, 2016 18:30
|
|
|
Cybernetic Vermin posted:there seems to be a lot more impedance in how the systems apply to the way we think about programming than one would expect from looking at it on paper
|
|
#
?
Dec 19, 2016 19:11
|
|
|
you know, python hasn't been the current hipster language for several years. we need a new thread title
|
|
#
?
Dec 19, 2016 19:23
|
|
|
Xarn posted:Holy poo poo that exists, I thought it was a joke. the nice thing is that you'll rarely need it so most people dont need to use it unless they're writing data structures that have a structure that stores a const object. re: rust it bugs me that a "systems language" doesn't give me power over where i allocate objects from. sure i could write my own Vec<T> that takes some allocator trait thing but at that point why am i using rust? no default arguments is a killer and it bothers me because it affects APIs. i am also not a fan of the lifetime syntax. i know why its there but its super obtuse and isn't specified early on in their docs and can be confusing if you're coming from a c++ world. i'd be ok with named arguments because ive seen people in the rust community make the classic 'boolean as a function parameter' mistake in what would otherwise be fairly solid APIs. that or they port a python style API to rust and it just meshes poorly. the community is p. chill tho and i like that they've enforced their community rules and ousted shitheads before.
|
|
#
?
Dec 19, 2016 20:22
|
|
|
idk what i'd use rust for. everything systemsy i do eventually boils down into some nasty unsafe poo poo which presumably (?) would wind up infecting everything and everything else is probably more pleasant to do in c# or similar
|
|
#
?
Dec 19, 2016 20:26
|
|
|
Bloody posted:everything else is probably more pleasant to do in c# or similar rust's type system is a lot better than C#'s, and you can technically get around a lot of poo poo by just using Rc they're definitely not meant for the same things though
|
|
#
?
Dec 19, 2016 20:27
|
|
|
|
| # ? May 22, 2024 14:24 |
|
|
Half the brainpower in Rust probably goes into letting you write safe abstractions with unsafe internals
|
|
#
?
Dec 19, 2016 20:34
|
|
