jasory

joined 2 years ago
[–] jasory@programming.dev 1 points 3 days ago

Not hentai but "Anubis", the webscraper deterrent has an anime girl and it looks quite unprofessional, and what's worse is something like balancing Anubis' scales would be a much better image than a girl with a magnifying glass.

[–] jasory@programming.dev 3 points 1 week ago (1 children)

If what the original commenter said is true about simply replacing keywords with another string, then it's questionable if they are actually learning anything about language design or demonstrating skill.

[–] jasory@programming.dev 1 points 3 weeks ago

"Take them at their word"

Who? Has there been a survey of contributors?

"Genuinely think that coreutils would be better if it were written in Rust"

I feel like the skill-level of the contributors is high enough that they would not be so naive.

Programs in different languages can compile to the same machine code. Any advantage would be in language constructs. But if you already have an existing C implementation what advantage do you do from a Rust implementation?

I personally write in 3 languages: Rust, C++, and Fortran ( or rarely SPARK). I don't port my code across languages, because there is no advantage. If I wanted it better, I would work on my existing codebase.

Porting really only helps if the original language was hindering development, deployment or runtime. These arguments don't really hold with C, a fast, low-dependency language that is more widely used than Rust.

[–] jasory@programming.dev 1 points 3 weeks ago (2 children)

Being written in Rust has mixed effects. Rust is still less mainstream than C, so fewer people can contribute. However, it does attract more interest because it's different.

However, the reasons why you create/contribute to new-but-similar projects is to add functionality that the original project doesn't have. By nature a coreutils replacement has to behave like coreutils or else it will break many configurations. This severely limits the functionality you can provide. So why are people (and Canonical) contributing so much labor to something that still doesn't function as intended?

I say it's the licensing. I say this as someone who regularly gets requests to change the licensing of my software (more than any feature request). I think licensing is a big deal, and most software devs recognize that.

[–] jasory@programming.dev 1 points 3 weeks ago* (last edited 3 weeks ago) (4 children)

You are fixating on the incorrect premise. I noted that it was started a decade ago as a analogy for how labor intensive the project is. A project that by design has to mirror the behaviour of coreutils.So why are people investing the time in this? What makes it worthwhile? It's the permissive license. If uutils used GPL individuals would instead try to contribute to the much more utilised coreutils, where their contributions would be guaranteed to have an impact.

Edit: Some of the earlier issues date from 2013, so it has been a decade, although it probably was very obscure at the time.

[–] jasory@programming.dev 1 points 3 weeks ago

I'm fairly certain that people who advocate for teaching ethics, only do it under the assumption that people are being taught to do what the proponent wants. In reality learning ethics is just learning different theories of ethics.

[–] jasory@programming.dev 4 points 4 weeks ago

The only code generation assistance I use is in the form of compilers. For fun I tried to use the free version of Chatgpt to replicate an algorithm I recently designed and after about half-hr I could only get it to produce the same trivial algorithms you find on blog posts even with feeding it much more sophisticated approaches.

[–] jasory@programming.dev 1 points 1 month ago (2 children)

I write quite a bit of Rust, and I'm still at a loss.

It's easier to write a low-error program in Rust. But low-error program in any compiled language is going to be essentially identical.

19
submitted 9 months ago* (last edited 9 months ago) by jasory@programming.dev to c/rust@programming.dev
 

I wrote up a port of GNU factor that has a slightly nicer UI than the original, and runs in approximately 1/3rd the time for 128-bit integers, on average. This is just a preliminary release and I plan implementing elliptic curve arithmetic and extending it to 192-bit to cover all the small integers that CADO-NFS doesn't support.

The factorization algorithm is provided as a separate crate that provides a C-api, since fast factorisation algorithms are hard to come-by.

view more: next ›