Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hard Rust requirements from May onward

lists.debian.org

Post reply on HN
Print view View original

711–720 of 797 posts

Re: Hard Rust requirements from May onward

#711

Post by julian-klode »

pizlonator wrote: post #518
julian-klode wrote: post #465

Earlier quoted context omitted.

Fil-C is amazing but is much more problematic than Rust at this point since it only supports amd64 at this time and is maintained by a single genius. It also doesn't help you to attract new contributors. With the changes we made over in Ubuntu to switch to rust-coreutils and sudo-rs, we have seen an incredible uptake in community contributions amongst other things, and it's very interesting to me to try to push APT m…

> since it only supports amd64 Sorry to double-reply, but this is actually a super important point in favor of Fil-C . If you adopted Fil-C for apt, then you could adopt it optionally - only on ports that had a Fil-C compiler. Your apt code would work just as well in Fil-C as in Yolo-C. It's not hard to do that. I think about half the software I "ported" to Fil-C worked out of the box, and in those cases where I had…

As far as I understand, Fil-C changes the ABI of the system, therefore it requires a new architecture in Debian terminology, e.g. amd64fil. And then you'd need to use multi-arch to pull in amd64fil binaries where that works.

We'll have to see how this plays out but it's not super plug and play.

Re: Hard Rust requirements from May onward

#712

Post by gspr »

t43562 wrote: post #708
gspr wrote: post #699

Earlier quoted context omitted.

What's wrong with the primary documentation?

I was doing this months ago and have forgotten every twisty road I went down but I wanted to produce a binary package for a particular version of Ubuntu (and or Debian) and put it in a PPA so that people could use my code easily. It seemed like the rules file could be anything and I wouldn't have to implement a lot of targets that are either irrelevant or hard to understand the purpose of. So I used a script. Mistake…

This all seems to be criticism of how Debian chooses to build packages. You may well be right in some of it. But I fail to see where contradicting documentation comes in.

Re: Hard Rust requirements from May onward

#713

Post by ChocolateGod »

loeg wrote: post #675
ChocolateGod wrote: post #585

Earlier quoted context omitted.

Rust doesn't automatically add memory safety to all existing C code, which will need to be maintained for decades, Fil-C nearly does and its still early days. > We have an alternative that isn't 10x slower, and comes with many other benefits Anyone involved with development around a fruity company would say Swift ;)

I don't get the impression the Swift team is especially interested in use cases outside of OS X and iOS. (The context here is Debian.)

There seems to be a push to get Swift outside of just Apples platforms, namely Linux and Android support and backend micro service developnent.

Re: Hard Rust requirements from May onward

#714

Post by pezezin »

cbmuser wrote: post #439
estimator7292 wrote: post #325

Earlier quoted context omitted.

Sure, but almost nobody uses or wants modern linuxes on those machines. It's almost always described (in their own words) as "some ancient crusty version of Debian"

Nobody wants to play games on Linux given the small userbase compared to Windows. Yet people work on it. You could make this argument for so many usecases but apparently people just enjoy bashing retrocomputing here.

> Nobody wants to play games on Linux given the small userbase compared to Windows.

According to the last Steam survey, 3% of players use Linux. Steam has 130 million active players, so that means there are 4 million people playing on Linux. Definitely not "nobody", and way bigger than the whole retrocomputing community.

By the way, I am also one of those retrocomputing guys, I have a Pentium 2 running Windows 98 right here. IMHO, trying to shoehorn modern software on old hardware is ridiculous, the whole point of retro hardware is using retro software.

Re: Hard Rust requirements from May onward

#715

Post by paulf38 »

julian-klode wrote: post #696
amelius wrote: post #171

Can we please also have the hard requirement that code should run without warnings under Valgrind? Because that saves a lot of headaches down the line.

It's certainly what we aim for in APT. We do have an overwrite of course, since we need to copy uninitiated data around: The cache file is allocated as a whole and written at the end, but not all parts of it are used, but it triggers stuff. Don't want to introduce complex code to only copy the parts that are actually reachable would be silly and introduce bugs. But keep in mind valgrind is super buggy and we spend qu…

TBH most “false positives” that I investigate are wishful thinking or the result of ignorance of what is really happening. It looks like you are using Debian. That probably doesn’t help. Here is a typical Debian “bug” report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802778

10 years old. It never was a false positive. It was fixed a good few years ago. The fix did not involve suppressing the error.

Valgrind does need a lot of work, especially for missing CPU features and for Darwin. I’m not aware of many memcheck bugs that aren’t relatively obscure corner cases.

If you have encountered bugs please report them to https://bugs.kde.org.

Re: Hard Rust requirements from May onward

#717

Post by tmtvl »

dokyun wrote: post #698
tmtvl wrote: post #299

Earlier quoted context omitted.

As a GC language Common Lisp is slow as molasses. However, in the realm of languages which are slow as molasses it's got quite acceptable performance. I suppose it's in part because it's alien technology from beyond the bounds of the multiverse, but also in part due to the fact that we had really interesting tech back in the '70s and '80s that kinda got lost during the so-called AI winter. To add on to that, with dec…

News flash, but Lisp compilers have gotten better since the 80's. In general, normal, unoptimized Lisp is probably on-par with Java, while optimized Lisp with a good compiler can get on par with C++. SBCL is a very good compiler, and GC technology has come a long way.

SBCL is fantastic, but the resources being poured in GCC and LLVM combined with CPU manufacturers including architectural features to help C and related procedural languages work better make it a massive uphill battle. I suppose that with proper use of things like sb-simd and arena allocation you can get in the ballpark of C, but with some tweaking C, C++, and Rust can get insanely fast (of course Fortran's better, but nothing compares to it, so let's leave that aside for now).

Re: Hard Rust requirements from May onward

#718

Post by uecker »

illuminator83 wrote: post #709
uecker wrote: post #682

Earlier quoted context omitted.

The package manager takes care of the dependencies. And one does not need to compile the libraries one uses, so how complicated this is does not matter. I install the -dev package and I am done. This works beautifully and where it does not the right move would be to fix this.

I think in most of my projects, many of the C++ packages I used for work (lots of computer vision, video codecs etc) I had to compile and host myself. The latest and greatest of OpenCV, dlib or e.g. gstreamer weren't available on the distros I was using (Ubuntu, Fedora, Centos). They'd lag a year or more behind sometimes. Some stuff was outright not available at all via package manager - in any version. So, yes, you…

Virtually every package is in cargo and npm because there is no curation. This is exactly why it is a supply-chain risk. The fix is to have a curated list of packages, but this is what Linux distribution are. There is no easy way out.

Re: Hard Rust requirements from May onward

#719

Post by t43562 »

gspr wrote: post #712
t43562 wrote: post #708

Earlier quoted context omitted.

I was doing this months ago and have forgotten every twisty road I went down but I wanted to produce a binary package for a particular version of Ubuntu (and or Debian) and put it in a PPA so that people could use my code easily. It seemed like the rules file could be anything and I wouldn't have to implement a lot of targets that are either irrelevant or hard to understand the purpose of. So I used a script. Mistake…

This all seems to be criticism of how Debian chooses to build packages. You may well be right in some of it. But I fail to see where contradicting documentation comes in.

It seems that there is a history of ways to build packages and the docs probably need to explain now versus then so that you can beware of what other people have written in the past. They also need to be comprehensive enough that you're not looking for other people's answers that may be out of date.

Back to my original point - I don't think Rust is going to fix this.

Re: Hard Rust requirements from May onward

#720

Post by qiu3344 »

drnick1 wrote: post #686

My main objection to Rust is how ugly it looks. Why did they have to change things such as how types and functions are defined? I really hate keywords such as def, fn, and other "explicit" function declarations. Also all the :: and from C++. Language-wise Java and C# did a much better job at introducing the features they needed without breaking the readability and familiarity of C.

The "spiral" type declaration syntax from C is hard to parse, both for humans and machines. That's probably why even C++ is moving away from it:

     C              modern C++
  "int foo[5]" -> "array foo"
It's easy to criticize simple examples like the one above, since the C++ (or Rust) version is longer than the C declaration, but consider something like this:

  char *(*(**foo[][8])())[];
and the idiomatic Rust equivalent:

  let foo: Vec Vec>; 8]> = Vec::new();
The later can be parsed quite trivially by descending into the type declaration. It's also visible at a glimpse, that the top-level type is a Vec and you can also easily spot the lambda and it's signature.

Another ergonomic aspect of the Rust syntax is that you can easily copy the raw type, without the variable name:

  Vec Vec>; 8]>
While the standalone C type looks like this:

  char *(*(**[][8])())[]
which is quite a mess to untangle ;)

Also, I think C# is generally closer to Rust than to C when it comes to the type syntax. A rough equivalent to the previous example would be:

  var foo = new List>?[]>();
I can't deny that "?" is more ergonomic than Rust's "Option", but C# has also a way less expressive type system than Rust or C++, so pick your poison.
Post reply on HN