>>101584413
I would use rust if it had a sane syntax.

But sadly, it's retarded

>>101584413
No.
Generic Associated Types let you do HKT-like stuff sometimes if you're clever about it but that still doesn't meet the bar. I don't think I've even seen it in the wild.

>>101584454
Nobody cares about beginners' opinions about syntax (and people who think that syntax is the most important thing about a language are always beginners). I want to discuss the type system, which is way more interesting.

>>101584454
I prefer Zig, which has a bit more wonky syntax.

But regardless, syntax is just syntax. If you're getting turned off because of just syntax, then that speaks volumes about your capabilities as a software engineer.

>>101584528
It's obviously not widely used because it didn't always exist. That's why std has `Vec<T>`, not `Vec`.
Dislike for over-abstraction also contributes of course.

>>101584528
Interesting, thanks. Do you maybe have a link of hand that explains Generic Associated Types and how they differ from Haskell-style higher kinded types?

>>101585193
if you can explain to me what a higher kinded type is that'd be epic
a generic type is just a type that takes another type as a parameter when it's used

for example a Vec (that's what Rust calls arrays, because retarded historical reason) can be of any type because it has 1 generic parameter

let vec_of_ints: Vec<i32> = vec![1, 2, 3, 4];\
let vec_of_strings: Vec<String> = vec!["piss".into()];

I'm not those other posters and I realize this is off topic but Rust isn't just bad syntax. It's an overly complicated monstrosity of a language. It's still evolving, new features are being added all the time, there's a million ways to do something. Unraveling a typical Rust construct with tons of different symbols just to realize it's doing something simple like iterating over a collection of stuff or whatever is demoralizing. Maybe I'm not smart enough for it. But as long as I can earn a decent living developing in other languages, I don't have to be too concerned.

>>101585003
You have no idea

>>101586664
one can only think that Rust is complex if you come from a high level gc language
>doing something simple like iterating over a collection of stuff
this part is a dead giveaway that you're a javascript or python bro
(though i'm not necessarily using that as an insult)
iterating over a collection of stuff is NOT simple. It's just that your language was doing the complicated parts for you, and hiding them. Rust doesn't hide them as much. Rust is low level. Rust gives you control. And it has no garbage collector so you have to manage memory somehow

have you ever looked at C++ code?

>>101586208
Those are just generics, not GATs
>>101585193
Try this:
https://langdev.stackexchange.com/questions/3222

>>101586733
>Those are just generics, not GATs
ah shit
>Try this:
i'm still new to Rust is that just a type that's only used inside of a trait then

>>101586208
>if you can explain to me what a higher kinded type is that'd be epic
Sure. So a generic is like a function, but at the type level, right? For example, Vec takes one type and returns one type. It's the type-level equivalent of a simple function that takes one value and returns one value.
Now, what would be the type-level equivalent of a higher-order function that can take another function as an argument? It would be like a generic that can take another generic type as an argument. For example, Vec itself, rather than Vec<String>.
I don't know Rust so I'm going to use Java-like pseudocode.

class MyWeirdDataStructure<TMap<_, _> extends Map<_, _>> {
    val a = new TMap<String, Integer>();
    val b = new TMap<Hash, String>();
    val c = new TMap<Integer, String>();
}

>>101586733
>https://langdev.stackexchange.com/questions/3222
Thanks! I'll give it a read.

>>101586721
I don't take it as an insult. Rust evangelists are normally more hostile than you but it still doesn't bother me. I've never written JavaScript but I do like Python.
>have you ever looked at C++ code?
Yes, I'm not a fan of C++ either. We have some C++ projects at work. I don't normally work on them but I've had to go digging in there over the years. It's kind of a mess. It could be way worse but my company has standards and rules developers have to stick to so it's not a complete free-for-all shit show. Except for this one old project where someone decided to use SWIG heavily so there's auto-generated code all over the place. Yuck.
I'm actually a systems programmer who rarely picks his head above the level of freestanding C code. I do think Rust will inevitably get more popular but I think I will be retired before it's inescapable.

>>101586664
>It's an overly complicated monstrosity of a language. It's still evolving, new features are being added all the time, there's a million ways to do something
You seem to be confusing C++ with Rust. These were C++ problems, and was designed to address them.
In Rust there is very little feature overlap or features that were added for no good reason.

>Unraveling a typical Rust construct with tons of different symbols just to realize it's doing something simple like iterating over a collection of stuff or whatever is demoralizing.
Rust syntax isn't that complex. It can express very complex things, but it has very few constructs. In typical function/impl block you can find argument bindings(+destructuring), types, lifetimes, generic arguments, associated types/consts, where clauses, HKTBs and that's literally it. The symbols are literally the same you'd find in any mainstream language with generics, with extra ' for lifetimes.

>>101585003
Yeah, same here. I think that Zig's mixing of camelCase and snake_case looks like shit, but I'm not going to let that stop me from learning the language once it hits 1.0. It has an interesting system of allocators and error handling, so worth checking out. If you let yourself get babyducked on one language, and you reject anything that doesn't look like that language, then you're just pointlessly crippling your development as a programmer.

>>101587484
>In Rust there is very little feature overlap or features that were added for no good reason.
Not him, but you seem reasonable so I'll ask. Do you think that Rust is likely to become like C++ eventually, bloated with many overlapped features, or is the edition system strong enough to prevent that? In other words, how restricted by backwards compatibility is Rust's evolution? If added a feature to stable Rust and after a few years it turned out to be a dumb idea in retrospect, would they be able to remove it?

>>101588266
It's not really the result of "edition system". C++ standards work similarly to them.
The difference is how the changes are made. There is no committee that designs new features on paper just between themselves. In Rust anyone can make an RFC, anyone can discuss it, anyone can try to implement it. If a feature lands in nightly, hundreds or thousands of people will try it, they will give feed back, and the feature will get continuously refined until every question, every edge case, every bug is resolved. Only then it gets stabilized.
Another difference is that Rust doesn't care about being multiparadigm. Nearly everything in Rust is there for a good reason. There is never something included just so you can check a box next to another FOTM paradigm. For example there will never be inheritance in Rust even though it's one of the most requested feature. There is just no need for it. Everything you can do with inheritance, you can accomplish using other features in Rust, resulting in code that is just as, if not faster and more flexible.
Because of these two reasons I believe that Rust has significantly lower chance of becoming bloated. You probably shouldn't count for any drastic breaking changes. So far, C++ had more serious breaking changes than Rust(trigraphs for example). And of course no one can predict future. Even now there are already suboptimal things in Rust stdlib, like iterators not being designed with GAT in mind. But it's not that much of a deal, at least yet.

>>101584413
No, I wish we had lenses or something similar
The rust devs are too "down to earth" and """practical""" though (they already figured out lifetimes which are the hard part)

Brainlet here, what can do with this high IQ shit what I can't do in practical down to earth languages?

File: Zero.png (93 KB, 500x500)

93 KB PNG

>>101587667
>once it hits 1.0
I'm investing in learning it early.

Why do people like Zig again? It seems like a stupid mess which brings nothing new or advanced to the table. I'd actually say the same about Rust, but at least they're making some effort to mix functional programming with system level programming. (Whatever that means. Not much.)

>>101584616
im sure it's beginners and not actual developers who have to read other peoples code

>>101590016
Zig offers comparable speed to Rust, and hopes to be even faster with it's upcoming multithreading and incremental compilation, while also providing more fine-grained control over your software.

Zig and Rust are trying to solve different problems. Zig is trying to be fast, portable, and verbose.
Rust is trying to be fast and safe.

>>101590071
To me as C programmer, both look ugly as sin. I guess I don't have any real interest in them. In practice, when I don't use C, my choice of language is usually restricted by external decisions anyway.
Rust seems a bit like a dystopian nightmare, while Zig is just ugly and inelegant.

>>101590016
>Why do people like Zig again?
Contrarians who get their opinions from other people who don't code (the average /g/ poster). "I'm waiting for Crystal/Nim/Zig/Odin/Jai." None of these people make anything, they're just anti-Rust because they've been programmed to think it's a boogeyman. None of them write code let alone know how to write C or C++.

>>101590097
You are a nocoder and it's easy to tell.

>>101590196
You're also a nocoder.

>>101590071
Zig compiler is one of the slowest compilers I've ever used

File: Screenshot_20240727-12265(...).png (665 KB, 1440x3040)

665 KB PNG

>>101590016
It's just shilling and some newbies/C programmers who fell for it.
Notice how you never see anyone making any actual project in zig. Pretty much all zig discussion is just language flame wars. I don't think I have ever seen any zig thread that wouldn't incite a flame war in OP.

I keep hearing rust is not a automatic memory managed language but from the looks of it, it does have automatic memory management through borrow checking. So which is it?

>>101592181
It has RAII like C++. I don't think that's what people usually mean by automatic memory management, though it's certainly more automatic than calling malloc() and free().
Borrow checking is purely a compile-time check, basically part of typechecking. It has no effect at runtime. There's actually a bootstrap compiler for Rust that doesn't implement borrow checking at all.

>>101584413
and what are you gonna do with it once you have it? shove it?

damn, i probably need GATs but i dont understand them. i wrote a util function for newton's method, it only works with f32 right now because it takes two closures, Fn(i32) -> i32, and i want to also support f64, but i wasnt able to get the generic type into the closure type definition. is this something a GAT would solve?

pub fn newtons_method<F,G>(
    f: F, df: G, x0: f32,
) -> f32 where
    F: Fn(f32) -> f32,
    G: Fn(f32) -> f32,
{

>>101592181
Borrow checker is a static analyzer. It doesn't manage memory, which is a runtime task.
Idiomatic way of dealing with memory management in Rust is just RAII. It's the same thing you'd use in modern C++ and it's considered a manual memory management.

>>101592327
You don't need GATs for this. Your problem is probably that the stdlib doesn't provide any traits for numerics, so it's hard to make your code generic over numerical types. You can use the num-traits crate for this. And then it's just

use num_traits::float::Float;

pub fn newtons_method<N, F, G>(
    f: F, df: G, x0: N,
) -> N where
    N: Float,
    F: Fn(N) -> N,
    G: Fn(N) -> N,
{

Or with a little bit of syntactic sugar:

use num_traits::float::Float;

pub fn newtons_method<N: Float>(f: impl Fn(N) -> N, df: impl Fn(N) -> N, x0: N) -> N {

(You may also have to make a few changes like replacing "0.0" literals by "N::zero()".)

>>101592327
This doesn't seem to be any related to GATs. I'm not exactly sure where is your problem. Generic types are not constrained to only be the immediate types of arguments. You can add another type parameter, T, and make the F and G be Fn(T) -> T.
Also you probably don't need separate F and G unless you want them to different type.

>>101592413
awesome thank you
>>101592420
compiler doesnt like it for a dumb reason:

note: no two closures, even if identical, have the same type
= help: consider boxing your closure and/or using it as a trait object

>>101592451
>compiler doesnt like it for a dumb reason:
Oh yeah, I realized that only after making the post. It totally makes sense and is actually a good thing.
Here is a good video that explains why is this a case. https://youtu.be/SqT5YglW3qU
tl;dr if functions types only represented their signature, functions would have to be converted to function pointers and monomorphisation would produce much slower code(like in C++ if you pass functions as is, without wrapping them in lambda. Rust really dodged a bullet with this)

>>101592451
>a dumb reason
Because they're separate generic parameters the compiler can compile a different version of the function for each combination of closure arguments (monomorphization), which means that there are no function pointers at runtime and it's easy for them to get inlined. The optimizer can really go to town that way.
Depending on the details this could give an enormous performance boost or it could not matter at all. It also tends to lead to bigger binaries if you call it many different ways.
If you want to try it without monomorphization and without inlining you can use dyn pointers, &dyn Fn(N) -> N.