Steve doesn't really elaborate on the drawbacks to the features he listed, just kinda says he doesn't like them. I'll do some of that here:

• Function overloading: overload resolution adds a ton of complexity to the language for a feature with API-friendly workarounds (use different names, builders, etc).
• Default/optional arguments: can be confusing when the default value is initialized. For example, in Python, default values are static and reused across calls, meaning you can technically have def foo(a=[]), append to a on each call, and use that data on future calls to foo since the same list is provided as a default each time. In C#, default values are compiled into the caller's code, meaning if the caller's code was developed for an older version of a library and you use it with an updated version that has a new default, the caller will still use the old default. And so on, languages all handle defaults differently.
• Named parameters: the article covers some of the biggest issues. There's also the issue that API designers may not want their parameter names to be part of the API (consider the function is generated by a macro or build script, for example). Also, named parameters imply to new Rust devs that the parameters can be reordered, and it's odd to have them without optional arguments as well. Then there's the issue of code inspection (via macro or tool) if you can reorder parameters since you can only inspect source tokens, not query semantic information, so if parameters are reordered then it can become difficult to know which value goes to which parameter from the macro/tool.
• Varargs: to be honest, I don't really have a drawback for this in mind beyond them just being a fair bit complicated to implement. The C# params Foo[] args equivalent wouldn't be very useful, but varargs with variadic types would be powerful, just I assume very difficult to implement (for example fn foo<...Ts>(blahs: Ts...) or something, where Ts is a variadic tuple). In any case, that's a feature many libraries would take advantage of (axum, bevy, etc).

With newtypes you can also emulate named args with a single struct. This also allows them to be passed on together.

struct RectArgs{
    x:i32,
    y:32,
    w:32,
    h:32,
}
impl Default for RectArgs{...}

Then the call site looks like this:

rect(RectArgs{
    x:0,
    y:0,
    w:30,
    h:20,
}
// with default arguments
rect(RectArgs{
    w:30,
    h:20,
    .. RectArgs::default ()
}

Is it when you pick up an argument someone dropped?

Well it WAS the 5 second argument.

This greatly depends on language design and implementation.

For example, Clojure has all of these and much more, and it's still much simpler and hassle free than rust. The functions are just functions, but the forms and lists that are very powerful.

functions are just

(defn foo [a b] (print "do thing"))

(foo 1 2)

With the power of destructuring that maps provide us, we can have named arguments:

(defn foo [a & {:keys [b c]}] (print a b c))

(foo 1 {:b 2, :c 3})

and for multi-arity functions, there's no special syntax. It's still just plain functions and forms

(def foo
  ([a] (print "I only have one" a)
  ([a b] (print "I have two" a b)))

It also has more advanced ways of polymorphysm with methods and protocols.

It depends on the design of the language.

Is this the 5 minute argument?

Smaller incremental compile times and compiling rust on a raspberry pi? Looking forward to it.

I'm used to named arguments from other languages, and that makes me fairly partial to them. Having to tool around with builders feels a lot more complex and clunky.

That said, I do wonder at how many of the usecases aren't workarounds for long argument lists that are either stringly typed, or something similar. As in, with a signature of (i32,i32,i32,i32) -> whatever, named arguments seem like a way of getting the compiler to catch errors in confusing {x,y}_{position,length}; but if the signature were newtypes like Rect(Origin(i32,i32), Size(i32, i32)) -> whatever, then the felt need for named arguments drops considerably.

I don't know, it looks like the amount of issues is way higher than improvement in comfort. Beside, they mentioned a lot of corner cases that would definitely show up and become a problem

I've been using C++ for quite some time, and it also had some talks about having named parameters, but it only helps in some places and hinders in most, imo. I feel like in Rust you may use a struct as parameter containing all of function parameteres where you really want the names

Maybe

YES!

No.

Great write up. thanks for posting it was an interesting read.

The Rust-COVID conspiracy is deranged 😂 Wow. Maybe people just love a good conspiracy.

The use of MIT is problematic, IMO though. Big Tech loves the MIT license.

Phoronix forum posts should only ever be read as a source of entertainment. The only place where you may find even more ignorant Linux users is Lunduke's comment section. Some of these people genuinely believe that Rust is part of a "woke" conspiracy to weaken FOSS projects. I've read someone unironically call the timing of Rusts increasing popularity "suspicious" because it coincided with the COVID-19 pandemic.

I just seed everything. Most of the time nothing is actually transferring. Dunno if @dessalines@lemmy.ml actually has an upload problem and is using too much bandwidth. What actually made you write this?

P.S and why not on codeberg or Radicle?

There are people in those comments who won't admit Rust is actually useful and have a place in the kernel. Replacing 11k lines of C with Rust isn't nothing.

Ok boss, doubled it. What now?

double post

interesting, 10 has been my threshold for keeping on seeding for years

If a torrent is right on the threshold, would pausing make the seeds drop and cause it to reengage next time, making it oscillate?
And same for multiple seeds using it, they could start to each drop out and rejoin all at once if they have similar cron frequencies. Especially since trackers have some delay.

I also wouldn't un- and repause paused torrents every cycle. So having a 3rd condition function that filters for being under a somewhat lower seed count (hysteresis) where it unpauses would solve both.

I'd expect qbit to have some overhead for resuming, and also to dos the trackers a little, if there are oscillations or paused torrents are momentarily resumed every run.

Edit: should prob ping @dessalines@lemmy.ml since this is a crosspost.

Or they will hire him to spy on other brand

I hope the person has fun.

I mainly learned that I want this person in my squad in the apocalypse