Conversation

Notices

1. Embed this notice
   翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Sunday, 21-Jul-2024 03:40:39 JST 翠星石
   People keep shilling rust for "security", but also love to not mention that the rust "bootstrap" process consists of starting from a rust compiler written in C++ and then downloading every single version of rust in series (which requires >170GB of drive space and countless hours of compiling) while hoping that nobody managed to slip anything dodgy into every single rust version.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Sunday, 21-Jul-2024 04:05:02 JST 翠星石

     in reply to

     • gentoobro
     @gentoobro Yes - everything rust does could be implemented for C with tooling (aside from the "borrow checker", which is best implemented as an advisory thing rather than something that restricts how you program) - but nobody wants to do that and wants "new and shiny" things.
   • Embed this notice
     gentoobro (gentoobro@gleasonator.com)'s status on Sunday, 21-Jul-2024 04:05:03 JST gentoobro

     in reply to

     @Suiseiseki And the fact that you can just turn off the security in the code any time you want, and there's no way to write fast code without doing that in some situations.

     Nevermind that only the static typechecking (which both C and C++ have) and borrow checker (which is only useful in basic situations) happen at compile time; all the other memory safety features, like array indexing, incur a runtime cost in speed and memory. Just take a gander at some Rust disassembly on godbolt and you'll see it secretly dragging around array size data and doing bounds checks.

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Sunday, 21-Jul-2024 04:27:59 JST 翠星石

     in reply to

     • LisPi
     @lispi314 Yes, you should just write Emacs lisp.
   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Sunday, 21-Jul-2024 04:28:01 JST LisPi

     in reply to

     • gentoobro
     @Suiseiseki @gentoobro When your language starts to require the language plus over a dozen different tools to be barely usable, that's not exactly a ringing endorsement.
     
     Interlisp did it better.
   • Embed this notice
     gentoobro (gentoobro@gleasonator.com)'s status on Sunday, 21-Jul-2024 04:29:55 JST gentoobro

     in reply to

     • Zergling_man
     • LisPi

     @Zergling_man @Suiseiseki @lispi314 I agree.

     sudo emerge -av libpng.

     Then just link against/dynamically load libpng.so. It's not complicated. If your language can't do that, that's a language problem.

     翠星石 likes this.
   • Embed this notice
     gentoobro (gentoobro@gleasonator.com)'s status on Sunday, 21-Jul-2024 04:29:56 JST gentoobro

     in reply to

     • LisPi

     @lispi314 @Suiseiseki Official or semi-official language module/package managers always turn into an unmaintainable clusterfuck. Some worse than others, but no exceptions. People just import modules willy-nilly and all the sudden you can't compile a calculator without the lpad package which has been abandoned for 5 years and causes a compile error in the new compiler version. Nevermind the security footprint of hundreds of indirect deps, nor the constant maintenance you have to do to keep up with all the changes in your deps.

     At one job, I essentially spent half of my time just keeping up with useless "updates" to the roughly 1600 deps in the node_modules folder... (inherited project, of course)

   • Embed this notice
     Zergling_man (zergling_man@sacred.harpy.faith)'s status on Sunday, 21-Jul-2024 04:29:56 JST Zergling_man

     in reply to

     • LisPi
     • gentoobro
     @gentoobro @lispi314 @Suiseiseki MOTHERFUCKERS NEED PACKAGE MANAGEMENT
   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Sunday, 21-Jul-2024 07:24:59 JST LisPi

     in reply to

     • Zergling_man
     • gentoobro

     @gentoobro @Suiseiseki @Zergling_man I have to disagree with the C-centrism part.

     There's no particular reason C should be prioritized above any other ABI save for historical accident.

     Mezzano (to refer to a non-historical example) would also disagree on its consisting of baremetal (because it isn't).

     Baremetal (machine code) is distinct from system-supported ABI, which is itself distinct from but related to calling conventions.

     (WinRT has its own distinct ABI too.)

     An implementation for a given system should provide means to interface & interact with the system, yes. But the language itself shouldn't have any preference for arbitrary ABIs.

     :blobancap: :blobcattrans: :blobancap: :blobcattrans: :blobancap: :blobcattrans: likes this.
   • Embed this notice
     gentoobro (gentoobro@gleasonator.com)'s status on Sunday, 21-Jul-2024 07:25:00 JST gentoobro

     in reply to

     • Zergling_man
     • LisPi

     @Zergling_man @Suiseiseki @lispi314 I generally agree with this, but take it a step further. The package manager for modules/libraries in your programming language should be the distro package manager. NPM, rubygems, cargo, and the rest shouldn't even exist. Not only that, any language with pretensions to being a serious language should use ELF/PE as the module format. You can have header files too of course, and should have at least C headers. But the actual module should be a .so or .dll that is completely usable from C.

     Why C? Because it's not so much C as it is bare metal. At the bottom, in machine code, you have structured data (structs) and functions. That's all. There are a couple different calling conventions for functions, but they are largely immaterial and the standard ones vary by platform and architecture. If your language can't both use and output executable (library) files that export functions which process structs, it's not a serious language; it's a self-contained toy. It can't even do the most basic thing in computers.

     Does your language have secret overhead functions? That's fine. Export them too. C++ exports its constructors and destructors. Garbage collection? Custom allocators? Export hooks. Does your lib depend on other libs? Well, wouldn't you know it, ld already handles that automatically.

     If every language did this, like serious ones already do, then it wouldn't even matter what language your deps are written in. After all, it's all just machine code underneath.

     As for culture, you can't hand-wave it. Tards are gonna tard, and if your language gives krazy glue to tards, don't be surprised when they glue their hands together.

   • Embed this notice
     Zergling_man (zergling_man@sacred.harpy.faith)'s status on Sunday, 21-Jul-2024 07:25:01 JST Zergling_man

     in reply to

     • LisPi
     • gentoobro
     @gentoobro @lispi314 @Suiseiseki >This disaster leads to all sorts of "virtual environment" nonsense to try to work around it, which only works sometimes.
     >The other side is NodeJS and npm
     These are the same thing.
     Total venv death. Total docker death. etc.
     
     >spergs don't just flip their API's upside-down for shits and giggles because it wasn't RAII-y enough or whatever the latest fad is
     This isn't a technical problem, this is a culture problem; it's entirely possible to do this with whatever lib by randomly changing what symbols it exports, it's just that the sorts of people who like C aren't retarded, unlike webniggers.
     I say this but then I encounter situations like this with random libs frequently too.
     
     Motherfuckers really need package management.
     https://michael.orlitzky.com/articles/motherfuckers_need_package_management.xhtml
   • Embed this notice
     gentoobro (gentoobro@gleasonator.com)'s status on Sunday, 21-Jul-2024 07:25:02 JST gentoobro

     in reply to

     • Zergling_man
     • LisPi
     @lispi314 @Zergling_man @Suiseiseki

     Source-based

     gentoobro

     There is a real problem with this approach, and it's seen with Python. Python, by default, without all the tricks, has a global package list. There can only be one version of a package in it at a time. This is all nice and good in fairy-land where spergs don't just flip their API's upside-down for shits and giggles because it wasn't RAII-y enough or whatever the latest fad is, however in the real world this turns into a maintenance nightmare. Every package has to play keep-up with all its deps, all the time. And this means that it's entirely possible (and even likely, for non-toy projects) that you'll end up locked on some certain very narrow set of versions due to the overlap of compatibility for all the different packages you need to use and whether the drunken Russian in Siberia who maintains it has woken up from his bender yet and noticed the backwards-incompatible changes to a dep. This is real, and while I have avoided Python in all of my jobs, happened multiple times to my friends who weren't so lucky in their career. This disaster leads to all sorts of "virtual environment" nonsense to try to work around it, which only works sometimes.

     The other side is NodeJS and npm. Every package keeps a copy of its own deps in a big nested tree of source code. Further, each package can pin the version range of its deps. So either a package pins the version, including all the bugs and exploits of the version, or it unlocks it and you're left with the situation above. Nevermind that you have to compile slightly different versions of lodash several dozen times.

     C/C++/ELF shared objects leave these decisions to users and distro maintainers, who take a varied approach. Further, because there's no central package manager to just magically push changes to all the time, library authors tend to be a lot more thoughtful with their releases and breaking compatibility.

   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Sunday, 21-Jul-2024 07:25:03 JST LisPi

     in reply to

     • Zergling_man
     • gentoobro

     @Zergling_man @gentoobro @Suiseiseki Source-based languages with transparent recompilation on dependency upgrade have zero problem with sharing directories of libraries.

     Consider Common Lisp on Debian and Guix.

     (SBCL just transparently compiles source files into FASL object files, so any SBCL instance will just reuse them. Its FFI also supports native object files, though CFFI also allows for mostly transparent handling of C source.)

   • Embed this notice
     Zergling_man (zergling_man@sacred.harpy.faith)'s status on Sunday, 21-Jul-2024 07:25:04 JST Zergling_man

     in reply to

     • LisPi
     • gentoobro
     @gentoobro @lispi314 @Suiseiseki mfw trying to use shared objects in python