These are chat archives for rust-lang/rust

20th
May 2016
Daniel Collin
@emoon
May 20 2016 03:52
Thanks!
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 15:49
Every once in a while, I try to convince my coworkers that rust is the future of statically typed, compiled languages. They read a few examples, and leave stunned and upset that it doesn't have what they consider to be traditional OO programming. The question is, how do you engage such an audience, and begin to sway them?
Dylan Waits
@waits
May 20 2016 16:12
Go similarly lacks traditional OO, but I find it to be a refreshing simplification; it rarely feels like a barrier.
LeonineKing1199
@LeonineKing1199
May 20 2016 16:36

Every once in a while, I try to convince my coworkers that rust is the future of statically typed, compiled languages.

Well, that's just zeal talking is what that is. Rust isn't the be-all-end-all. It's another tool for people to choose from :)

Sean Perry
@shaleh
May 20 2016 16:37
If they insist they have to have OO to be successful they are already closed to alternatives
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 16:37
Well, that's just zeal talking is what that is. Rust isn't the be-all-end-all. It's another tool for people to choose from :smile:That's fair, I'm just enamored with it's inherent safety.
oops, lemme retry that...

Well, that's just zeal talking is what that is. Rust isn't the be-all-end-all. It's another tool for people to choose from :smile:

That's fair, I'm just enamored with it's inherent safety.

Sean Perry
@shaleh
May 20 2016 16:38
@palodequeso just remember, the safety is not 100% due to type safety or compilation. Sell the safety specifically.
LeonineKing1199
@LeonineKing1199
May 20 2016 16:39
That's one of its very attractive features. "Jr. developers won't ** your codebase into oblivion" XD
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 16:39
hahaha
Sean Perry
@shaleh
May 20 2016 16:39
it helps to show some of your team's code re-thought in Rust (or any other language) to actually demonstrate value
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 16:39
@shaleh That's a good point, perhaps I'll give that a try.
LeonineKing1199
@LeonineKing1199
May 20 2016 16:39
I'm a JavaScript dev. It's very, very, very easy for someone to come in and just wreck the codebase without even really trying....
Sean Perry
@shaleh
May 20 2016 16:40
@LeonineKing1199 especially jQuery style magic everywhere code
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 16:40
My dayjob is a mix of Node.js/javascript, and c#
and yes, I work very hard to keep people in line with javascript
LeonineKing1199
@LeonineKing1199
May 20 2016 16:41
It's tough. We try to use code review and TDD to keep things in line but sometimes, bugs are so impossibly hard to track down.
Sean Perry
@shaleh
May 20 2016 16:41
forced code review. Nothing is checked in until it a) peer reviews b) makes it through automated testing & linting
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 16:41
We do code reviews where at least 2 people have to sign off.
But everyone is too nice haha
sometimes I look like a pedantic monster
LeonineKing1199
@LeonineKing1199
May 20 2016 16:42
Omg, I used a raw for-loop once. Boy, was that a thrashing...
Sean Perry
@shaleh
May 20 2016 16:42
code review makes us all better. Be evil. If a hacker can't take it they do not take their job seriously
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 16:42
to be fair, out of the 5 on the team, only 2 have a computer sciencey background, and I'm one of them :/
Sean Perry
@shaleh
May 20 2016 16:42
a hacker who is against good code review is saying their ego has more value than the customer
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 16:42
I might quote that in times of need!
Sean Perry
@shaleh
May 20 2016 16:42
please do
Sean Perry
@shaleh
May 20 2016 16:48
review.openstack.org <-- nothing gets in OpenStack without peer review, linting, automated testing. You cannot commit to OpenStack. The review system commits your patches. Read the reviews. I tend to work on Keystone so I know those better.
this is what solid peer review looks like
The norm is to ignore any review not passing linting/unit tests.
LeonineKing1199
@LeonineKing1199
May 20 2016 16:52
How strict is your guys' linting? I've heard of some linters that rejected code because there was an unnecessary space after a comment...
Sean Perry
@shaleh
May 20 2016 16:52
yup
this is in Python. If it does not pass pep8 it does not pass.
LeonineKing1199
@LeonineKing1199
May 20 2016 16:53
Oh wow. But that's purely syntactical
Sean Perry
@shaleh
May 20 2016 16:53
annoying at times. But the devel can run it all locally before sending it for review
ugly code. Broken windows and all that.
start letting little things slide and bigger things follow
LeonineKing1199
@LeonineKing1199
May 20 2016 16:55
Well, that's sound like the slippery slope fallacy XD
Sean Perry
@shaleh
May 20 2016 16:55
yeah, try it some time and let me know :-)
LeonineKing1199
@LeonineKing1199
May 20 2016 16:56

Ha ha, touche!

But syntactical differences are exactly that, syntactical and not functional. Why not design a linter based on the actual execution of the code?

Sean Perry
@shaleh
May 20 2016 16:56
oh, there are those too :-)
LeonineKing1199
@LeonineKing1199
May 20 2016 16:57

Like, is this a big deal?

if (condition) {
    single_command();
}

vs.

if (condition)
    single_command();
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 16:58
At my last job, we had a jenkins box that would do builds on every PR, and any python was run through a PEP8 linter, it was brutal sometimes.
Sean Perry
@shaleh
May 20 2016 16:58
code is read more than it is written. Style linters aid reading. Simple as that. Yes, complaining about an extra line or space is annoying. But like I said, you run this before you commit. Fix the complaint then send it in. Once you are acclimated it is not an impediment.
LeonineKing1199
@LeonineKing1199
May 20 2016 16:58
I'm also radically hyprocritical because I think nested ternaries are the devil and they're purely styntactical.
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 16:59
I'm not convinced that Pep8 is always the best for reading, but it's a far sight better than letting everyone use their own style.
Sean Perry
@shaleh
May 20 2016 16:59
@LeonineKing1199 we have a linter called "hacking". It is for finding things the community feels are wrong even if valid. :-)
@palodequeso exactly. I HATE 79 char limit. But, a clear and sane base state ensures all code is fairly similar.
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 17:00
we used 79 characters for a long time, then when some employment "shifted", we went to 120, it was a beautiful thing.
Sean Perry
@shaleh
May 20 2016 17:01
Another lesson I learned when young: Debugging is harder than writing. If you wrote to the edge of your skill with lots of cute then by definition you cannot debug. Save the gnarly code for the times when you really need it.
I prefer something in the 100 - 110 range, but it depends on language. Some communities use longer names/APIs than others.
I'd be ok with 120.
LeonineKing1199
@LeonineKing1199
May 20 2016 17:04
Hmm. I'm too young for my own good :laughing:
I need to get pwned in the face more.
I only say that because I'm still young and rebellious enough that I try to defy the linter when I think it's being dumb. But that's just because I don't have the responsibilities of someone in a higher-up position nor the experience of getting burned.
I appreciate the wisdom, @shaleh
Sean Perry
@shaleh
May 20 2016 17:05
@LeonineKing1199 I understand. I grumble a lot about it myself :-)
@LeonineKing1199 the lesson is learning that it sucking for everyone but it is agreed is better than it working for a handful
LeonineKing1199
@LeonineKing1199
May 20 2016 17:06
You know what's absurd, our linter doesn't want single-line if-statments to have brackets but nested ternaries are okay.
Talk about being ass backwards...
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 17:06

Another lesson I learned when young: Debugging is harder than writing. If you wrote to the edge of your skill with lots of cute then by definition you cannot debug. Save the gnarly code for the times when you really need it.

This used to happen a lot, we had one super experienced Python guy who left, and when we had to start wading through his bugs, it was a lot harder for some of the team to decipher.

Sean Perry
@shaleh
May 20 2016 17:07
@palodequeso there is value in lifting up the skills of the team. I spend an hour or three a week mentoring for sure.
@LeonineKing1199 I believe all if/for/while/etc should have braces if the language has them. This is doubly true of if/else.
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 17:08
@shaleh it's true. I'm getting ready to start one hour, weekly "courses" on some basic concepts.
Sean Perry
@shaleh
May 20 2016 17:08
I find helping them solve a problem or walking them through a code review helps more.
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 17:09
I had to explain a linked list recently, and it made me realize that perhaps it was time at least learn some of the basics a little bit more.
LeonineKing1199
@LeonineKing1199
May 20 2016 17:09
Yeah, how do you guys handle code review?
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 17:09
yea, that's true
LeonineKing1199
@LeonineKing1199
May 20 2016 17:09
Do you guys both sit down and walk through it together?
We've tried just looking at them independently but I don't think there's any value in that because there's not enough context...
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 17:09
@LeonineKing1199 We don't, we make pull requests, and people comment on it. The prescribed reviewers just give a +1 when they're finally happy with the commits.
Sean Perry
@shaleh
May 20 2016 17:10
@LeonineKing1199 I do a combination of online reviews and in cube explanations when I am particularly harsh with the red ink
LeonineKing1199
@LeonineKing1199
May 20 2016 17:10
Yeah, that's what we do too but I don't like it.
Half the time I look at them and I'm just like, "Yup, that looks like code to me."
I like the idea of having the person who wrote it explain the problem they were trying to solve and how they implemented it.
I know code should be self-documenting but no one should be going hungry in the streets either...
Sean Perry
@shaleh
May 20 2016 17:12

code review is about

  • style
  • adherence to specs
  • maintainability
  • is this too simple? Could we solve more?
  • how does this move us closer to feature X a customer wants?

if you are just being a human linter you are not helping unless you are surrounded by newbs.

LeonineKing1199
@LeonineKing1199
May 20 2016 17:13

is this too simple? Could we solve more?

You'd think simplicity is a good thing O_o

Sean Perry
@shaleh
May 20 2016 17:13
It can be.
but sometimes you come to realize that this solution could be applied to more of the code and this ends up simplifying more
You also have something a friend taught me which is "locally correct, globally stupid"
when reviewing you have to consider the whole project not just the function/class/file
LeonineKing1199
@LeonineKing1199
May 20 2016 17:15

but sometimes you come to realize that this solution could be applied to more of the code and this ends up simplifying more

Good point, pulling out patterns is always a good thing.

You also have something a friend taught me which is "locally correct, globally stupid"

This sounds fine to me though... Solve the problems that exist where they exist.

Sean Perry
@shaleh
May 20 2016 17:17
think of a project/product like connected ecosystems. If one team starts dumping in the lake because that is expedient for them noone else may discover it for a while.
LeonineKing1199
@LeonineKing1199
May 20 2016 17:18
So, what counts as locally correct but globally stupid?
Sean Perry
@shaleh
May 20 2016 17:18
or you have hidden performance issues because they do not realize that their slow loop is part of a larger thread of execution. "Who cares if this function takes a little way, there is no rush." Might be true. But if it slows down a key loop or someone decides to refactor so it is used in more places suddenly that good decision goes bad.
Decisions that are made for a class / file / module without considering the whole system.
LeonineKing1199
@LeonineKing1199
May 20 2016 17:19
I see...
Sean Perry
@shaleh
May 20 2016 17:20
These are the items that are written in sprint X and seem ok but destroy in sprint X + 20 because now everyone has to use it or is affected.
LeonineKing1199
@LeonineKing1199
May 20 2016 17:22
Oh believe me, I've encountered those kinds of issues before... I guess I'm still just raw because I got chewed out for using a single-statement for-loop in lieu of a higher-level abstraction. I considered it unnecessary and when you said, "locally correct, globally stupid" my mind immediately went back to that.
If you can solve something in a single-statement for-loop, you should be thanking Programming Jesus!
Sean Perry
@shaleh
May 20 2016 17:23
Yes and no.
collection.map(op) <-- apply op to every item in the collection
for(it ; it != end) { op(it) } <-- apply op to every item in the collection
LeonineKing1199
@LeonineKing1199
May 20 2016 17:24
This was something where order mattered otherwise I would've done a map for aforEach
Sean Perry
@shaleh
May 20 2016 17:24
the first one I trust. The second one I have to check for edge cases, boundaries, funny stuff, etc.
LeonineKing1199
@LeonineKing1199
May 20 2016 17:24
I get that.
Colliding philosophies are an interesting thing.
Sean Perry
@shaleh
May 20 2016 17:25
also, once a "free" set of braces exist there is space for someone else to stuff another operation in the loop
using map you have to go and edit op
that simple for loop leads to one off code
"this time we loop and do X" later "this time we loop and do X and Y"
I would be likely to ding a naked for loop that was not clearly needed.
LeonineKing1199
@LeonineKing1199
May 20 2016 17:29
Hmm... That's interesting. My approach to software has slowly become building it in layers. Write the "unsafe" code first and then wrap in the safety scaffolding after. I mean, I hate to kill the magic of computers but ultimately, a memcpy really is just a loop...
Sean Perry
@shaleh
May 20 2016 17:31
true. But it is easier to think "memcpy" than "loop over all of the bytes and put them over here". This is the same reason we talk about named patterns. Forcing code to use them is silly. But a shared vocabulary lets us talk about bigger things without constantly explaining every item.
Plus, you have the reason for functions. Which is you write them, debug them, trust them.
New code is untrusted.
simple as that
LeonineKing1199
@LeonineKing1199
May 20 2016 17:32
You're alright, Sean Perry. This was a very engaging discussion. I feel like I learned a lot.
Sean Perry
@shaleh
May 20 2016 17:32
m . e. m . c . p . y . buffer . buffer2
or f . o . r . (case . case . case) { assign. assign ....}
less typing, less thinking, less bugs
same reason we do not code in asm every day
LeonineKing1199
@LeonineKing1199
May 20 2016 17:37
Unless you're doing CUDA and you inline some ptxas like a baws
Sean Perry
@shaleh
May 20 2016 17:37
gnarly code when needed :-)
LeonineKing1199
@LeonineKing1199
May 20 2016 17:38
I suck too much at programming to ever be good at CUDA
Sean Perry
@shaleh
May 20 2016 17:38
not just because you can
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 17:38
Never forget the invsqrt from Carmack
LeonineKing1199
@LeonineKing1199
May 20 2016 17:38
Lol I've seen that XD
It's because division is slow.
Sean Perry
@shaleh
May 20 2016 17:39
"division was slow on the hardware he had" you meant to say
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 17:39
I really did not enjoy that game. It's a Tom Clancy game where I can't sneak up and get a one shot headshot kill, and that bothers me.
LeonineKing1199
@LeonineKing1199
May 20 2016 17:39
Thank you for correction :)
Sean Perry
@shaleh
May 20 2016 17:40
@LeonineKing1199 it is an important distinction. Some would now copy and paste that code to every game because division is slow.
But maybe you do not divide that often. Or maybe your hardware handles division better.
always test, then optimize
LeonineKing1199
@LeonineKing1199
May 20 2016 17:41
Yeah, that's problem with wanting to be on the bleeding edge. People confuse fast with fast enough.
Douglas Eugene Reisinger II
@palodequeso
May 20 2016 17:41
I see my reference to the Rust subreddit being bombarded by Rust the game players didn't land :P
shaleh @shaleh hacks because he sucks at games