/dpt/ - Daily Programming Thread

What are you working on, Sup Forums?
Old thread:

Other urls found in this thread:

pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-the-rust-language/
pcwalton.github.io/blog/2013/01/21/the-new-borrow-check-in-a-nutshell/
github.com/rust-lang/rust/issues/44580
github.com/kostya/benchmarks/blob/master/matmul/matmul.rs
github.com/kostya/benchmarks/blob/master/brainfuck2/bf.rs
github.com/kostya/benchmarks/blob/master/json/json.rs/src/json_struct.rs
doc.rust-lang.org/1.12.0/book/custom-allocators.html
twitter.com/SFWRedditImages

First for Python/Julia is great

First for `#![feature(nll)]` is the best feature out there.

>/dpt/ - the rustlet's ultimate bait edition

rust took csp-style concurrency, which was its main selling point, out of their language hahahaha

>which was its main selling point
You're confusing Rust with Go. The main selling point of Rust is the borrow checker.

That also happens to be its worst feature.

Start autism
pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-the-rust-language/

pcwalton.github.io/blog/2013/01/21/the-new-borrow-check-in-a-nutshell/

The 2/3 letter abbreviation in rust drive me nuts.
Fuck fn, impl, mod, mut, pub, str, ref, vec, cmp, ord and a lot of the other shit.
Also fuck let, let number: i64 = 33; let number of type i64 is 33; just sounds retarded.
They reversed the syntax from type name to name: type but functions are still have the type first as in fn name(stuff: i64, other_stuff: i64) -> i64 {...}
The module system is a mess.
It's heavy focused on UNIX with windows as a 2nd rate citizen.
The val, &val &mut val nonsense.
All of these points make Rust worse than it should have been.

>Rust have both tho
Okay, how can I achieve a non-type parameter in Rust? and how wiill you implement `>` for a struct like this?
struct Point {
vals: [F; D];
}

>everything should be based on C

F E A R L E S S
E
A
R
L
E
S
S

For every pair of two permute the rest put pair on each end in order.

meant struct Point {
vals: [F; D];
} sorry

github.com/rust-lang/rust/issues/44580
Soon.

Without GC, Rust would be either yet another C++17 or yet another GC shit pretending to be a system PL, like Go or D. Borrow checker is that makes Rust actually unique and innovative.
What's your point? Rust had optional GC at some point, which was dropped in 2013, and it had BC from long before 2013, the post you've linked says so. It's not like Rust was all-GC and then suddenly switched to BC. Besides, all that happened before 1.0, so who cares.

Rust doesn't have non-type generics yet, they're working on it.
>and how wiill you implement `>` for a struct like this?
By implementing the Ord trait for it?

that's actually one thing i like about rust.
Besides having to label functions with "fn" and the impl stuff all that nonsense.
Who the fuck wants to type full words for something that everyone would know, when you can type a fraction with the same information? I especially like "use" instead of #import.

Coming soon. It's const-generics. Proposed syntax:
struct Point {
vals: [F; D]
}

>it's the rustshills raiding /dpt/ episode, again
Fuck off.

You'd think they get enough of their fix on reddit.

ITT: everyone is an expert on highly concurrent systems and has writes such systems with over 200 kLOC in C/C++ practically every day

Rust would be fantastic if it did indeed want to be C++ but without all the cruft.
C++ with first class sum types, tuples, traits and bounded generics but no OOP, no exceptions and none of the obtuse overloaded syntax or broken features sounds like a pretty solid language to me.

From those criteria Rust only fails to have decent syntax. But even that would improve if it weren't for the borrowchecker shitting &'a, 'b mut ref everywhere.

non lexical lifetimes are already in the nightly, isn't it?

>The 2/3 letter abbreviation in rust drive me nuts.
Sucks to be you.
>let number of type i64 is 33; just sounds retarded.
Just write ```let number = 33;``` and let the type deduction to deduce the actual type.
>They reversed the syntax from type name to name: type
What do you mean "reversed"? They're influenced by OCaml, not some shitty language like C.
>The module system is a mess.
They're fixing it.
>It's heavy focused on UNIX with windows as a 2nd rate citizen.
As it should be.
>The val, &val &mut val nonsense.
Oh, look, it's the "I haven't spent a minute to actually learn the topic but it looks funny to me so it's nonsense" argument again. Imagine someone without prior knowlege trying to make sense of pointer syntax in C.

What do you meant?
Could you give some kind of example??

Yes actually. Except not every day.
I'm sick of how Rustlets think the solution to concurrent problems lie in safeing induvidual pieces of data.

>let number of type i64 is 33;
That's based on standard mathematical language. Mathematics is often written as a sequence of commands to the reader "Let x be..."

>I want Rust to be C++ with nicer syntax, I don't want them to fix the actual problems with the language which constantly cause stability and safety issues because that would make me to think about my code

>It's heavy focused on UNIX with windows as a 2nd rate citizen.
Is Rust, dare I say, /ourlang/?

>make sense of pointer syntax in C
Not that being right in this proves anything but I'm wondering what you think would be hard to get.

>CoC

I want them to fix problems with the language, just not those concerned with safety. I want the same expressiveness without the complexity. Fewer pitfalls without lessened utility.

he means like this:
you calculate one permutation (123) and its mirror (321), put the on the far ends (front and back) of the array and fill the middle with the other perm/mirror pairs
I'm guessing he didn't read your whole post and didn't notice you don't need the mirrors
the simple solution is to put each member of an array in front and then just recursively do this (and save the unique permutations somewhere so you can check for mirrors) until you hit a mirror, then you put something else in front etc
I'm pretty sure there's a way better way of doing this but I slept 2 hours this night so hopefully someone else has the willpower to explain it to you

You mean >>>/global/rules/?
Hardly, remember that the majority of develpers are on *nix.

Are you saying that Rusts features add additional burden to the programmer?
Mental overhead is not something we need more of in systems programming.

>It's heavy focused on UNIX with windows as a 2nd rate citizen.
Name a systems programming language where this isn't the case.

Well, nothing, if you actually spend like 30 minutes on it, that's my point. When people complain about lifetimes, val/&val/&mut val, or borrow checker, they basically complain that they don't immediately understand things they haven't spent a minimal effort to learn about, and that somehow makes these things bad.

>C++

So any of these features will take 30 minutes to learn from no prior knowledge? Interesting. I'll get back to you.

C++ on Windows is a nightmare. MSVC is the worst of the major C++ compilers. ABI stability hasn't been an issue on Linux for years, yet it still routinely breaks on Windows.

Enjoy your MSVSC piece of shit

> I want the same expressiveness without the complexity
Define "complexity" tho. What's more complex, to occasionally struggle with BC to get your code compiled, or to debug data race or memory corruption on production system? Also C++ has plenty of dark corners itself.

Rust in action

github.com/kostya/benchmarks/blob/master/matmul/matmul.rs

github.com/kostya/benchmarks/blob/master/brainfuck2/bf.rs

github.com/kostya/benchmarks/blob/master/json/json.rs/src/json_struct.rs

I say C is successfully pretty agnostic for both OS and platform.

Well Rust is heavily based on C, and nowhere did I state anything like that.
What I meant is that they write it as:
fn name(param1: i64) -> i64;
instead of:
name fn(parm1: i64) -> i64;
I actually like having a keyword for functions like func/function, I just dislike fn.
>let number of type i64 is 33; just sounds retarded.
>Just write ```let number = 33;``` and let the type deduction to deduce the actual type.
Still doesn't change the fact that it reads like shit.
>The module system is a mess.
>They're fixing it.
The proposed changes were a mess, the only good change is no longer needing to rename your file.rs to mod.rs in a new folder, the rest of the changes only make things more complex. the removal of extern crate is a bad one imo.

>C
How is your C99 support going, wincuck? Is it 2018 now? holy shit

If you're gonna flash your CoC don't do it at me.

>Are you saying that Rusts features add additional burden to the programmer?
No, they make programming easier, because you don't have to worry about memory and thread safety that much, the compiler providing you with nice guarantees.

Such concepts are not difficult to understand. How you can structure your program - especially if you care about efficiency - with the BC shackled to your ankle is something that increases the cognitive load significantly.

>Rust is heavily based on C
and also Haskell and OCaml

> name fn(parm1: i64) -> i64;
That's fucking awful

But you have to think more about your code apparently.
Not the program, the code.
I think I see the classic tradeoffs coming back here.

>Bitching about CoC
Never seen a person doing so at work or anywhere else. Where do these creeps hide irl?

>increases the cognitive load significantly
But it also frees you from worries about minute things like freeing memory and thread safety, so you can focus on the problem at hand and not the way you're going to free all the resources on error.

Step back, I've got this.
fn(i64) -> i64 name = |x| {
...
}

I just don't like it when people shove their genitals in my face and tell me they're right to do this.

Rust is the perfect language for hugbox coders

And? Do you think you are doing anything different?

Just drop the 'fn' entirely, and strive for uniformity.

let name: (param1: i64) -> i64 {}

You can do this with any GCd language. If you don't care about memory management you use one of those.

If you do, Rust isn't suitable. How are you supposed to write a custom allocator in Rust? How do you use an arena?

Unironically, Rust is fairly difficult to master, more than modern C++, I'd say. C++ is a tamed beast now.

>But you have to think more about your code apparently.
It's the opposite, with Rust the compiler provides guarantees so you don't have to think about the code as much as in C or C++. For example, in C/C++ you have to ensure there are no data races by carefully considering all the paths, in Rust you get that automatically. In C you have to remember to free all the resources in the correct order in all the return paths (remember `goto error:` fiasco?), Rust takes that burden from you.

name : i64 -> _ -- i64
...

> let myfunction = |param: i32| {param + 100};

>tfw to intelligent to use Rust
>tfw have to write my browser engine in C instead

That looks more inline with the rest of the declarations.

>You can do this with any GCd language. If you don't care about memory management you use one of those.
Sure, if you don't care about performance and memory consumption. Also, even GC won't save you from data races.
>How are you supposed to write a custom allocator in Rust? How do you use an arena?
doc.rust-lang.org/1.12.0/book/custom-allocators.html

Yes I don't ever force my genitals in anyones face.
That guy just threw a bunch of code at me. How fucking rude is that? I never do that unless the discussion is specifically looking for an example.

That works too.

You can get rid of the parens.
name : i64 -> i64

see you in 8 years, user!

A = [1, 2,...., n]
for i in [1...n):
for j in (i...n]:
swap(A, 0, i)
swap(A, j, n)
for P in permutations(A, 2, n-1):
print P
swap(A, 0, i)
swap(A, j, n)


No.

I don't know why he posted codes however I hope codes don't look intimidating to you and that you don't feel harassed to see a bunch of codes.

improved version:
name: i64;

param1(i64), param2(i64) -> name -> i64 = { param1 + param2 + 1}

Looks great.

>t. brainlet who can't think with lifetimes

>Fuck fn, impl, mod, mut, pub, str, ref, vec, cmp, ord and a lot of the other shit.
This is great, makes code looks neat and short.
>The val, &val &mut val nonsense.
Right: char, char *, char const, char * const, char const *, char const * const, char &, const char &, char && and const char && makes much more sense.
>let number: i64 = 33;
Just use let number = 33_i64; or let compilator deduce type on its own. There is no point in specifying type of binding unless you use Iter::collect() or other function with generic return type.

That looks like a type declaration.

>Sure, if you don't care about performance and memory consumption
What a bizarre thing to say. How do you care about memory consumption and performance without caring about allocation and deallocation? If that's one of your goals then it's a critical part of the program logic, not something you can leave the compiler to prove for trivial cases alone.

#[no_mangle]
pub extern fn __rust_allocate(size: usize, _align: usize) -> *mut u8 {
unsafe { libc::malloc(size as libc::size_t) as *mut u8 }
}

#[no_mangle]
pub extern fn __rust_deallocate(ptr: *mut u8, _old_size: usize, _align: usize) {
unsafe { libc::free(ptr as *mut libc::c_void) }
}

#[no_mangle]
pub extern fn __rust_reallocate(ptr: *mut u8, _old_size: usize, size: usize,
_align: usize) -> *mut u8 {
unsafe {
libc::realloc(ptr as *mut libc::c_void, size as libc::size_t) as *mut u8
}
}

#[no_mangle]
pub extern fn __rust_reallocate_inplace(_ptr: *mut u8, old_size: usize,
_size: usize, _align: usize) -> usize {
old_size // this api is not supported by libc
}

#[no_mangle]
pub extern fn __rust_usable_size(size: usize, _align: usize) -> usize {
size
}
Rustfags think this is acceptable.

but mah uniformity

(flet ((name (param) param))
(name 10))

avoiding types will cost you performance

> If that's one of your goals then it's a critical part of the program logic, not something you can leave the compiler to prove for trivial cases alone.
Right, this is why Rust supports custom allocators, just like I've shown.
>Rustfags think this is acceptable.
Again, what's wrong with it? You keep posting code implying it's somehow bad just because you don't understand it, but If you don't understand a language you haven't spent a minute actually learning, it's your problem, not a language's one.

dude JIT lmao

I harassment is a strong word but it's certainly insulting.
Coming here and inserting your own fucking ad where we're supposed to converse.
If you did that at a party you'd be brought out into the alley and get your teeth kicked in.

>The val, &val &mut val nonsense.
>Right: char, char *, char const, char * const, char const *, char const * const, char &, const char &, char && and const char && makes much more sense.
Rust also has *mut and *const, not saying c++ with it's retarded & and && is any good just saying Rust would have been better if it didn't make things even more retarded than in c++.
>let number: i64 = 33;
>Just use let number = 33_i64; or let compilator deduce type on its own. There is no point in specifying type of binding unless you use Iter::collect() or other function with generic return type.
My problem is the let part, name: type = value or name = value are both fine to me.

*runtime crash*
heh nothing personnel kid

>not testing your code
Are you OK user?

don't forget char*& and the rest if you're into sepples

Rust may require more difficult concepts to grasp and force you to write code in Rust way which takes some time to get used to.
But C++ is artificially hard because of legacy and 2137 ways of doing simple things like opening files or stdio.

>Rust also has *mut and *const
Which you shouldn't use unless you write some unsafe low lever code.
>My problem is the let part, name: type = value or name = value are both fine to me.
So you don't like the keyword itself? What should it be, auto? var?

struct x {
lock l;
int x;
};
void fn() {
x *p = get_x();
lock(&p->l);
// modify p
p->x = 10;
unlock(&p->l);
}

If there is only write operations when the lock is locked, is it thread-safe to dereference the lock from x pointer from non locked context?
Are read only operations thread-safe?

>freeing memory
I normally fight about this in GC vs MMM and this is the exact same argument.
But if you're a rust programmer and you don't understand MMM and how easy it is i don't know how to help you. With GC programmers it makes more sense because they never face it.
I'd surmise it as being a non-problem. It could be in a heavily memory constrained environment where you can't actually load your entire program but for platforms where you just lack the memory to efficiently allocate everything it's really not that hard. And if you wish to keep your footprint low its almost a completely orthogonal problem.
I'm sick of how you people consider MMM something you can comment on when you haven't even tried it. Using the smart ptr's in C++ really doesn't count. Almost nobody would consider such wild allocations/deallocations a valid strategy. I'm questioning if perhaps there's a complexity addiction in modern programmers. If it's too easy to do you feel bad or something.
Personally I don't see what a borrow checker could actually buy me. And that's actually assuming it's effortless to use, which commonly doesn't seem to be the case. It speaks to the complexity addiction again. Programming as a domain gets hard when you're writing code that's supposed to work extremely tightly with other work. I don't see how a person who structures themselves so poorly that they need a computer assisted system to keep track of if they're currently in possession of a variable could possibly write a good library.
Maybe this is just another set of training wheels I haven't caught onto yet.
>free all your resources in the right order
See again. Another person who doesn't have any idea of how C programs are written yet dares comment on it. Good luck running your rust program in that situation. Nevermind actually developing software like that. What a nightmare. No control.

new to python learning to write code with it. correct me if i'm wrong.
is self is only used on methods within classes?
and what's the proper way to do error handling?

>Which you shouldn't use unless you write some unsafe low lever code.
>not using consts and refs
Not him but what layer of ironic sarcasm are you on, user?

>is self is only used on methods within classes?
yes.
>and what's the proper way to do error handling?
the "pythonic" way is to throw exceptions for everything.

He's talking about using raw pointers in Rust, and he's right.

What happens when you use CMake to build a C++ project on Windows when you don't have any IDE installed? What does it do?

How do I into system programming?
Is reading books about kernel/os development enough to get me started?

But don't do the pythonic way, it's dumb.

>Which you shouldn't use unless you write some unsafe low lever code.
The same could be said for c++, but I write embedded stuff so it's only logical for me to write unsafe code.
>So you don't like the keyword itself? What should it be, auto? var?
I prefer no keyword at all.