This is one of my favorite design discussions you have done. Thanks for being open and for laying out all of the trade offs and issues. I learned a lot.

I think what people were talking about (at near the 45 minute mark) about having a hash of the library was that it would guarantee that it was exactly the same, as otherwise it wouldn't match the hash? Maybe they meant that in order to deduplicate files? But if that is the concern, I think one could just handle that by doing weird stuff with ones file system if one wants instead of it being a language feature? (I don't know how file systems work. Maybe some filesystems already automatically store identical files as one copy with multiple references? I don't know.)

I like how you can "add" methods to a struct (or any type) in Rust. E.g. there's the Display trait that declares the fmt method for formatting a value for printing. Now there might be a library that exposes certain types that don't implement that trait, but you still want to be able to use them in a format string. No problem, you just implement this trait yourself. It won't do any dynamic magic (it can be used as something like a vtable, but usually its used with generics and its all resolved at compile time). Heck, you can have several implementations of the same trait for one type without any problem, you just have to explicitly say which one you'd like to use.

these are the issues that every programming language is trying to solve and after 60 years of compiler history, there is still no solution that works perfectly. i wonder how jai is going to end up dong it.

Hey man, you shold take a look to the package managers for the ELM (just called elm package manager) and Elixir (called hex) languages. With elm, the compiler literrally makes it imposible to break semver, and on hex I believe once you upload it, it's there for good, no backsies.

At #25:50: Maybe you don't need module parameters, just have a compile-time function in the library that people call after importing the library, and the function takes parameters and sets up things. Conflict resolution could be solved in the library itself; it wouldn't load the same feature twice or remove a feature that some module needs.

@Booone008

6 жыл бұрын

This. I feel like the only counter argument to explicitly registering "print routines" in some preamble was increased runtime complexity in setup and execution, but isn't it already possible to build a compile time registry/dispatcher system with the existing compile time execution?

In his keynote at CppCon 2017, Titus Winters was talking a lot about Google’s approach to the problems of versioning shared libraries, and how in particular they were going to be handing this in the newly open sources Abseil stuff. His general idea seemed to be that semantic versioning, version locking etc. Was the wrong approach, and instead advocated a “live at head” environment where libraries would typically be run at the latest version. His solution to breaking changes was to create a kind of contract between the library user and the library vendor, such that the library user had to accept certain reasonable usage restrictions of the library, and the library vendor was made responsible for providing an automated upgrade path for the user. It seems to me like Jai would be extremely well positioned for such an approach, because the powerful compile time meta programming features allow for a lot of contract checking ahead of time to ensure reasonable usage of a library, and also for performing code transformations to automatically fix code to work with library changes. Therefore I wonder if part of the proposed package management system that copies libraries into the local source tree on the first usage etc. Could include features for project owners to explicitly pull down the latest version and apply some kind of upgrade code transformation provided by the library author.

@jblow888

6 жыл бұрын

Titus' thing sounds like a nice idea, but I doubt it will ever work. We'll see I guess.

@sollybrown8217

6 ай бұрын

Response funny.

I hope libraries will be able to detect aliases / folder shortcuts.

Does anyone know by any chance what keyboard, or at least switches, he's using? They're definitely clicky, but they sound too clear and high-pitch to be MX Blues. Any ideas?

ML-style parameters are always modules, so here you would do: #import "Profiler"(#module "SOFTWARE_RENDERING") I guess. Modules are typed in ML in order to allow this and you can use them as variables too, which doesn't work too well with #s (unless you do like x :: #module "M")

With such powerful meta programing, would it not be possible to write code that checks and download libs and resolves URLs and such for the compiler at compile time? If people want that (like some people in the chat seemed to want), they can just add it themselves. I agree that it don't sound like something the compiler should have native support for.

@derstreber2

6 жыл бұрын

Yeah I would think so. You could very easily use a #run directive to run a function at compile time to call out to a server on the net to download a source file and then include that file into your program for compilation. So if you absolutely wanted URL include like features, it is already possible. You could even crawl the web for data of some kind and use that to generate a source file and then include that in your compiled program if you wanted.

Module flags was something interesting in Cargo.toml, explicitly adding features to enable in the imports.

Finally a good bike-shedding video!

What if you put a decorator (?) on the print routines that the compile-time meta-program uses to know what functions it should use for printing things? That way it wouldn't have to scan through the whole program, right?

@sourestcake

6 жыл бұрын

Assuming i remember correctly, there is a feature for "notes", which Jonathan uses to do versioning. I think that could work for marking the print functions, but then there is the possibility of a clash with another library.

Privatize all variables

Another thought, if you're checking in all of your dependencies out of fear of them changing, you could go to the extreme and check in your compiler, operating system, version control system... Where does it stop?

@jblow888

6 жыл бұрын

It's not "fear", it's appropriate action based on experience of what occurs when that action is not taken. Yes, in the extreme you might archive the compiler too (though most people don't worry about this, because in practice it doesn't create problems).

It's only half true that containers provide consistency. They also provide easy updates, including updates in reverse, aka rollbacks. They even encourage frequent updates because all developers' machines can all move to the same new version (and back) without worrying about irreparable consequences. So yes, you can use them to achieve consistency, but it's false to say they're no different from the 70s method. They also provide control of the underlying OS, which means you don't have to support unknown user system like games do. Your code must run solely on the system you dictate. Until you decide to update that as well. :)

@jblow888

6 жыл бұрын

Why can't you do all these things with just the 70s method instead? (Or a minor change to it)?

@NeXtdra42

6 жыл бұрын

Because different programs may have dependencies on different versions of the same package that's expected at a specific path. Linux simply does not have a way to handle this situation, if your program doesn't work with the version already installed and used by other programs on a user machine your program cannot be correctly installed without containers. Containers allow multiple versions of the same packages (and even different packages that conflict with each other) to run on the same system without requiring special user attention. On top of that containers make it trivial to migrate software to another machine or to host redundant versions in a cluster. Personally containers have made maintenance of my own server a relatively simple task, they take the burden of dependency management from me as an end user to the maintainer of the container, which is usually the company making the software installed in it.

when is this language coming out?

Your initial explanation of how you think it should work sounds a lot like what .Net does with Nuget. You select a version, its downloaded and kept in your solution with all the binaries necessary to use it.

maybe if a module needs something provided to it then you need to provide it, it can't just look in the global scope for it, you must provide it at compile time or the library will not compile

I like the talk from Linus where he talks about how he "Has to keep OS developers from breaking user-space". That is like his #1 goal. And the fact that he HAS to do this all the time, combined with the "rolling release" culture of OS development nowadays, I can see why computers become less stable over time instead of more. Also, making it harder for people to create tiny libraries (by making you check in all dependencies to your source) might reduce the bloat of stacking tiny libraries to the moon.

@Heater-v1.0.0

5 ай бұрын

I don't follow your argument. On the one hand you demonstrate that Linus keeps the API and behaviour of Linux stable, on the other hand you stand that up as reason why computers become less stable over time. This is a contradiction. I find it a bit of an odd assertion that Linux has become less stable. I have been using Linux since 1996 and it's as rock solid today as ever. Now, I do agree, there is huge and ever growing chaos in the Open Source world on top of that. Luckily the like software Johnathan and the Rust guys see all this and are fighting back.

@adamhenriksson6007

5 ай бұрын

@@Heater-v1.0.0 I'm not sure what I thought when I wrote this comment, but less stable might be the wrong term to use. Maybe unwieldy and prone to cause compatibility issues across dependency versions since devs still undervalue backward compatibility in many areas of software development nowadays. My time with cuda development this month has been nothing but hell for example. Might rewatch the video later to jog my memory.

@Heater-v1.0.0

5 ай бұрын

@@adamhenriksson6007 Ah, you mean "stable" as in not having constant change rather that "stable" as in does not crash and burn. I can only agree. Every damn thing gets changed under our feet all the time. From boot loaders to init systems to graphic systems etc, etc. Luckily some basics like the C language and the Linux kernel API's change much more slowly. Those poor schmucks in web development have to learn an entire new framework every month!

@adamhenriksson6007

5 ай бұрын

​@@Heater-v1.0.0 Do not feel sorry for web devs. Web devs are kind of spoiled. The browser is like an entire OS wrapped with a high-level language that lets you render directly to the screen. Frameworks are trivial in comparison to OS libraries and the browser itself, they are easy to understand and easy to build. No wonder people build new ones every month, anyone can do it.

@Heater-v1.0.0

5 ай бұрын

@@adamhenriksson6007 Ha! Likely you are right. They also have the luxury that nobody cares if what they create is slow and buggy. At least judging by a lot of web sites I have to deal with. They just move on to the next shiny thing.

Jonathan, you can pin programs to a certain version of a dependency with NPM. The use-latest feature isn't automatic-that's something that you opt in to by choosing to throw wildcards into the manifest that declares dependencies. If you don't want the use-latest behavior, then don't wildcard the version strings when declaring dependencies. PS: I'm not saying this as a fan of NodeJS/NPM. I actually hate lots of things that crowd does and am more or less totally removed from that community. This is *not* how things are done with Go, by the way. Someone lied to you. Go imports are very often of the form `import("github.com/user/stringutil")`. That's what you put at the top of your source file. Go's approach to versioning is, basically, "just don't change APIs, ever; maintain backwards compatibility from first publication to end-of-life". Disappearing packages and single point of failure are a big problem in basically every package manager, though. Dat is pretty sweet. You should build your package manager on top of Dat. They're content addressed, and it would mean that operating a registry scales *along with community growth*. It also wouldn't matter if the registry had a global outage, or if your dependency got delisted, because the content addressing scheme means packages more or less remain available forever, so long as people are still interested in using those packages.

@jblow888

6 жыл бұрын

" If you don't want the use-latest behavior, then don't wildcard the version strings when declaring dependencies." But how does this work when it's a dependency of your main dependency that wants that lib? This is really the main issue.

@nesvand

6 жыл бұрын

Jonathan Blow dependencies of libs are definitely a concern for Node/JS developers, but only in the sense that the nested dependencies aren’t something you have specific control of the first time they’re installed. However, thanks to lock files those dependencies can be frozen along with the package folder structure for consistent replicable installs. Instead of checking in the lib files (which you could do), you just check in the lock file and any developer that needs to install the libs gets a carbon copy of the lib versions and file structure. It’s still not perfect, but NPM has been rapidly learning from its mistakes (albeit with the lumbering agility afforded to a large organisation)

Actually, the C++ people say you should just download whatever fits your use case, that C++ is meant to be used along with many third party libraries, and that they only keep putting stuff into the standard library because users demand it or to offer a standard solution where many equivalent solutions exist that break compatibility between libraries that use those solutions

Speaking of libraries, C++17 is adding support for 'run in parallel' as a concept in STL. An example is given as `std::sort(std::execution::par, first, last);` github.com/tvaneerd/cpp17_in_TTs/blob/master/ALL_IN_ONE.md#parallel-stl

@llothar68

Жыл бұрын

As i expected 5 years ago already, it will not be used a lot without executors making it into the library and this will not happen before C++26. A decade later. Threads are not scaleable in general purpose libraries.

at 58:35 has he explained why it's bad culture to use urls and stuff to install packages / modules. i don't get it is, apart from the fact that it may cause vulnerabilities to slip through

I would prefer an explicit remote library import system. Reminiscent of quicklisp. I think an import library should be implemented by users rather than being a compiler supported feature.

regarding module parameters, i haven't thought this through extensively, but in your Profiler(false) and Profiler(true, "direct3d") case, perhaps if you could determine that the union of the two (or more) generated libraries don't conflict, you could just combine the them? obviously this can't resolve every scenario, but if people really care about minimizing the number of libraries that are generated, i think that's something they'll ultimately have to resolve themselves.

@jblow888

6 жыл бұрын

This might be a way to solve the problem, but it's also more expensive, since you'd have to compile both versions of the library at least through typechecking in order to determine whether they are the same or not. (And by the time you get through typechecking, you are almost done, in terms of the amount of CPU that is spent to compile).

@Decateron

6 жыл бұрын

Jonathan Blow Yeah, it's definitely not a cheap check to do. Perhaps it's something that's only enabled when an optimization flag is given? I imagine that the program should behave the same regardless of whether or not you combine libraries together behind the scenes.

The multiple libraries, and with the parameters... I wonder how one would want to do things, if one uses a library that can run with debug and security checks, or in high performance mode. If one library you use, uses it in high performance mode, and you want to use it in debug mode, it's not clear what to do. Like, if the library don't include static data that need to be shared (like singletons and other stuff all programmers love :P ), it's fine to compile and call two different instances for the different areas that want it... but if it includes static data that you assume they share... then it becomes an issue... a really complex case to allow different modes like that.

@MrMcCoyD4

6 жыл бұрын

In another stream he showed off compiling multiple instances of a library that was using globals and such - it essentially just uses name mangling. I guess the only problems would pop up if you were using some global mutex for non-shareable OS operations.

Have you checked out Rust's cargo build tool and crates.io? It sounds like it does most of what you want. When you ask for a dependency, it will download the latest version (or requested version) into a global cache if not already present and then makes a Cargo.lock file that specifies the hash of the transitive dependencies to make sure that even if upstream gets updated or another local project requests a different version, that you still built with the same versions. It's recommended to include Cargo.lock in source repositories for binaries, but not libraries. Unfortunately, crates.io completely ignores it regardless of type which is something which should be different. When it comes to diamond-dependencies of different versions, cargo has some way of determining what can be shared or not.

@jblow888

6 жыл бұрын

What I am suggesting, though, is that "lock files" for dependencies are not a good enough solution. You need to have the actual source that you built with available at all times, without relying on being able to download that thing from the internet someday.

@sephiroth179

6 жыл бұрын

Because it's pure bliss to just check out a project, hit compile, and it's done. No surprises. And it works the same for everyone that gets a copy of the source tree. That should be the standard way of doing things.

@RandomUser311

6 жыл бұрын

You can install packages locally to ./node-modules inside your project and then include it in revision control.Same goes for composer (like npm for php). I agree that it is often a bad idea to not commit dependencies to the repository. Some colleagues at work insist on having dependencies external despite having been bitten by that during deployment before.

@jblow888

6 жыл бұрын

Yep, you *can*, but the idea that this is a cache obliges the culture to take up some heavy burdens in other ways (I made a longer comment about this elsewhere on this page).

@Rajdadaj

6 жыл бұрын

cargo + crates.io can do this with: crates.io/crates/cargo-vendor And I also agree that dependencies should be stored and committed with the application code.

i love your voice

The discussion about importing methods and namespaces around 41 minutes is very similar to how racket uses require and provide. docs.racket-lang.org/guide/module-require.html, docs.racket-lang.org/guide/module-provide.html. Racket doesn't give a way to import things that are not provided mostly to prevent collisions, but if you are willing to handle those cases then there should be no issue.

Not saying this is a good idea, and specifically maybe it's a bad idea. But: Would you want to do environment and build support tools in this language/package ecosystem? NPM is frequently used for build tools and dev tooling, so downloads source and does a local native compile. They use it for transpiling, concat, dev daemons, etc. In a game dev environment, you could theoretically use it for things like packing, compression/format conversion (crnlib or some command line crn tool, .obj -> binary vertex blobs), job schedulers (for geometry/lighting build farms), etc. The problem with this is: Checking in native bins. Meta-programming might be useful for things like this, maybe, but maybe it's best to *not* try to bootstrap an entire environment from this language, as well? In which case, some people might choose to use containers (or NPM) to solve their environment building needs... (or good old fashioned "have another dev stumble through helping you get it running, once they get back off vacation") Just wanted to remind you to consider the build ecosystem, and if you want to encourage or discourage solving that problem in your dependency and meta-processing system

If you release a STD lib, please please please add robust types/methods for forking and managing jobs and threads. A well flushed out iterator scheme for collections/arrays would be awesome too. This all sounds pretty interesting, can't wait to see it out in the wild.

Sorry for not seeing the Q&A part (40+ min) but have you considered obfuscation in any way? Also, about library versioning - Elm (statically compiled functional lang designed for web frontend) has the thing named Enforced Semantic Versioning. "Package system enforces semantic versioning based on the changes to your package. The system can tell if the package is making a breaking change and not allow for the minor version to be bumped and requires the major version bump to publish." (cited from medium.com/@rgoomar/why-i-think-elm-is-the-future-of-front-end-development-21e9b091fa05 ) In practice it is very convenient for me as a user of libraries (packages) because it reduces runtime errors a lot. You may have some inspiration from it.

@jblow888

6 жыл бұрын

We will enable some kind of obfuscation eventually, but we are not worried about that yet. "Enforced Semantic Versioning" is not good enough. The package has to be *exactly* the same as what you compiled with, which is why we will be copying the code.

@kamildabrowski2143

6 жыл бұрын

In cases where I'm not interested in exact version of anything (small apps, I guess) the ESV would be quite useful. Putting your binaries into repo should be optional. One more thing about versioning and overloading versions - I believe it should be done in some external file rather than directly in the code. It would be much easier to find out what app depends on. I know it sounds like `package.json` from NPM but it's practical. But still, needs improvement.

While PHP is one of the contenders for ugliest language in history I kinda like their sometimes stupidly pragmatic approach to such topics - at least to some degree. By default it doesn't know what to do when you import foo::bar::Braz and will just throw an error that it couldn't find it - but you can register your own callback function that knows what to do. Whether it just has to include a file from your libraries folder or bake it from pixie dust doesn't matter - if foo::bar::Braz exists in the end everything is fine. Have a few functions (loading from the default lib folder, your community server, ...) included with the compiler and let the user decide if any of them are applicable or if they have to come up with their own solution.

This sounds like RUST language :D

Jonathan, can you share your emacs color theme, please?

@criminaloffense7434

4 жыл бұрын

Some variant of the Solarized theme. ethanschoonover.com/solarized/

Wise words at about 1h:33m

Can you do this in your language? #if (Generic_Type == float32) { ... } #if (sizeof(Generic_Type) == 4) { ... } In C/C++ I want to be very strict with my compiler flags, but when I try to write code that is 32bit/64bit agnostic I sometimes get situations where I need to do `long x = library_function(); if (x > UINT32_MAX) { ... }` when I compile for 64bit. But when I compile for 32bit this will give me a compiler warning (or error with -Werror) that x never can be bigger than UINT32_MAX. So I'd wrap that in #if (sizeof(x) > 4) { ... }.

@qwesx

6 жыл бұрын

I am pretty sure I have seen him compare generic types like that before.

I'm only at around 17:00, but I don't think you know how npm works, dude..

@Inevitablerizzler

3 жыл бұрын

I only read your comment and can tell you probably didn't get the point

"Not being confused what fuck your program is doing is worth its weight in gold." -Haha! Absolutely! I get so frustrated at all the dynamic kiddies who tell me how awesome language X is because they don't have to declare types. So what? I would rather have a hard compile time typing error than a run time error for who knows why.?

@qwesx

6 жыл бұрын

I had that discussion with a colleague as well. Turns out he just writes small Python scripts which he simply doesn't document. They're like 10 functions where he does some serial communication using pyserial. My observation is that people who prefer dynamic languages simply never really had to write *and maintain* a huge program.

@DoctorGester

6 жыл бұрын

Or they just endured through it not trying to understand why they are having a hard time. Tunnel vision is a thing.

@nameguy101

6 жыл бұрын

Many people write large (>1kloc) programs in dynamic languages. This is why you see them preach unit testing -- it's the only way they could possibly get anything done. Doesn't really matter anyway, since all they're doing is making another novel way to serve web content.

I believe you should not implement any of this, but instead leverage your directives. You should have a series of prepackaged library handling files that are shipped with the compiler and can be included or excluded from the project as needed. With the directives, your language has, all the functionality that everyone seems to be asking for should be trivial to implement. Making a download request to a URL; Checking for security updates; Checking for semantic version changes; even CMS handling. I propose in addition (while this may be ambitious) you ship a unified GUI to handle this, that runs at compile time (like your "go bananas" routine). The dependency managing directives kick off `#run Remote_Dep(/my/url/);` or `#run Security_Check('libName',/sec/path);` and any discrepancies are totaled up and brought up in a dependency manager. Then the user can select what to download what not to download or simply be warned. After resolving, the manager completes the necessary work then continues the compilation process. Also, include easy methods of tying in user-created directives with this handling process. This way it is not on you to create the best possible solution and when someone down the road figures out the one true answer (or whatever) they can easily implement it and tie it into the GUI.

if an EMP took out the grid and internet at least you can still compile your game.

@rzdexyz

10 ай бұрын

there's a significant difference between "omg there is no interenet" and "the specific version of a library is no longer available through the package manager" / "the package server is down, now all builds that don't have local copies will fail"

Does anyone know what he's talking about ("the variable") at 1:13:50? Sounds like maybe just some inside joke

@Nozdrum

6 жыл бұрын

Inside joke for over 2 years now.

@ClysmiC11

6 жыл бұрын

Yeah, it's just an inside joke that there is this extremely powerful and esoteric CS concept called "The Variable" without ever attempting to address what "The Variable" actually is

@nameguy101

6 жыл бұрын

FYI, Jon has said in the past that his language is not really powerful enough to do anything with regard to The Variable.

That is basically how Node.js manages a package?

@BobbyL2k

3 жыл бұрын

So you actually check-in node_modules ? Because that's discouraged by pretty much everyone in the node.js community.

re: first 15 minutes: Isn't what you're talking about with the downloading of dependencies into the folder exactly what npm and its node_modules folder is? `npm install leftpad@1.3.2 --save` creates `/node_modules/leftpad/leftpad.js`, and you get the exact version 1.3.2 saved, and if you check that into your VCS you're set and never need to get it off the internet again. You're only going to the internet on install if you don't have the node_modules set up. Maybe I'm not understanding what you're trying to solve there though.

@SethBattin

6 жыл бұрын

TankorSmash it is typical (might even be boilerplate for `npm init`) to generate a VC ignore file for the content of node_modules. It is not intended to be stored. That said, there's nothing stopping you from doing it that way. I thinks there's an infamous SO debate about just that, and the lone advocate of checking them in was sure to say "I told you so" when npm experienced a one-day outage. It's all a very apples and oranges anyway. A language that has no compile step or direct memory access has very different needs from one that does. If a node lib ships with a bug, it might still be worthy of use, but you want the bug fix as soon as it is available nonetheless. If a memory access lib fixes a bug but changes in any way, that might break your compile. So the two should employ different tactics.

@jblow888

6 жыл бұрын

It is my impression that almost nobody does it this way. A lot of people install things to /usr/local/lib/node_modules, or don't check in the contents of their local folder for the application, etc. In general node treats this like a cache, which is a different attitude. Because it's just a cache, the culture has to be different in other ways, for example, every single version of every single package ever released has to always be available on some server forever, or you may not be able to compile. Even if some particular users get smart and always check in their dependencies, because the culture is that this is a cache, the culture is obligated to maintain this super-memory of all packages. Why? Who cares about every minor revision of package X that was ever created? Why can't we just forget that stuff? Nobody cares. (And this becomes more important when you start dealing with binary assets). If we don't treat this as a cache, and just say "the way it works is that your dependencies are checked in with your code", then the culture doesn't have to take up this giant awkward burden of eternal availability of every change that was ever made sometime someone sneezed.

@Dgc2003

6 жыл бұрын

For what it's worth Jon: In my experience use of the global node modules or composer packages is fairly rare. You need to explicitly pass a a flag to install packages into the global folder. I've only done so when the package is a CLI utility or similar. Also for dependencies on projects that I NEED to be always available and 100% reproducible I use an in-house GitLab server and configure npm/composer to use it as a repository.

Security issues around 3rd party source code checked into your tree - you still need to be able to know that 'lib xyz' has a security issue and needs to be updated.

@roberthickman4092

6 жыл бұрын

Also I don't think that having masses of example code and data pulled in by default is a good idea. This should be optional.

@jblow888

6 жыл бұрын

We'll figure it out as we go. Maybe it's cleaner anyway to break things into "TheLibrary" and "TheLibrary-Examples". I dunno. But I do think data by default is a useful thing and will get around some of the kinds of annoying steps that people have to remember to do otherwise.

@qwesx

6 жыл бұрын

So check the security advisories on the library's origin page and update the local tree if necessary before release.

@roberthickman4092

6 жыл бұрын

I can certainly see why this would be useful in game dev as the code and data are tightly coupled. Having examples is also good (lack of is a frequent cause of annoyance for me). My main concern is that it will end up emulating Photoshop and similar which come with a huge amount of stock data which may be useless depending on the user. Perhaps there could be a standardized 'include-example-code' flag on the package manager.

@roberthickman4092

6 жыл бұрын

+gwesx The point was that, while it can be fragile and break stuff, the model used by NPM can automatically handle security updates.

With the print vector to. You could have a function called ToString() that parses it self. Which is a virtual call. The default to string func is if it isn't overridden would call your print struct func

Rust cargo does a great job of this

Where does Jonathon blow stream?

@hasen_judi

2 жыл бұрын

www.twitch.tv/j_blow

I think static linking is surely good for games and the like, but my Linux Desktop has hundreds of Qt and Gtk programs. If they all would link Gtk/Qt statically this would not only blow up their sizes, it would mean they all would need to be recompiled and redownloaded on every Qt/Gtk update. That's unfeasible. One could look at this problem like the following, though: A Linux system is basically one huge application where every program is compiled and maintained by the same people. No use to statically link every program if they all end up with the same library anyway. But programs that do not come form your Linux distribution (like games and other commercial software) are different. They are usually few, but big and they can't make any assumptions about the Linux system they will be used on. So for them statically linking is the way to go. I don't want /bin/echo & co to statically link all its dependencies. Yes, under Linux that's only libc, but have you looked at the situation under macOS? Ugh. These are the recursive dependencies of /bin/echo under macOS: /usr/lib/libDiagnosticMessagesClient.dylib /usr/lib/libSystem.B.dylib /usr/lib/libauto.dylib /usr/lib/libc++.1.dylib /usr/lib/libc++abi.dylib /usr/lib/libobjc.A.dylib /usr/lib/system/libcache.dylib /usr/lib/system/libcommonCrypto.dylib /usr/lib/system/libcompiler_rt.dylib /usr/lib/system/libcopyfile.dylib /usr/lib/system/libcorecrypto.dylib /usr/lib/system/libdispatch.dylib /usr/lib/system/libdyld.dylib /usr/lib/system/libkeymgr.dylib /usr/lib/system/liblaunch.dylib /usr/lib/system/libmacho.dylib /usr/lib/system/libquarantine.dylib /usr/lib/system/libremovefile.dylib /usr/lib/system/libsystem_asl.dylib /usr/lib/system/libsystem_blocks.dylib /usr/lib/system/libsystem_c.dylib /usr/lib/system/libsystem_configuration.dylib /usr/lib/system/libsystem_dnssd.dylib /usr/lib/system/libsystem_info.dylib /usr/lib/system/libsystem_kernel.dylib /usr/lib/system/libsystem_m.dylib /usr/lib/system/libsystem_malloc.dylib /usr/lib/system/libsystem_network.dylib /usr/lib/system/libsystem_notify.dylib /usr/lib/system/libsystem_platform.dylib /usr/lib/system/libsystem_pthread.dylib /usr/lib/system/libsystem_sandbox.dylib /usr/lib/system/libsystem_stats.dylib /usr/lib/system/libunc.dylib /usr/lib/system/libunwind.dylib /usr/lib/system/libxpc.dylib These under Linux: linux-vdso.so.1 (this one is dynamically linked into every program by the kernel, so doesn't really count) /lib64/libc.so.6 /lib64/ld-linux-x86-64.so.2 Anyway, I wonder does Steam provide a set of dynamically linked libraries for it's games? Steam is a its own known environment almost comparable with the package manager of a Linux distribution.

@lunabob-ie5qx

5 ай бұрын

"they all would need to be recompiled and redownloaded on every Qt/Gtk update. That's unfeasible." - no it's not, his compiler compiles large programs in under half a second gentoo, iirc, already does this, just with a mega slow C compiler

@blenderpanzi

5 ай бұрын

@@lunabob-ie5qx The download part still is a problem in a lot of parts of the planet.

Maybe the IDE should be able to launch the compiler with a special option to fetch dependencies even before the user launch the first build. But I love the idea that the code is "shipped" with all his dependencies in a way that we will be sure that it will compile, because on some open source project I tried to contribute, it was always harder to make it build than doing the fix I want to do. In all day job I worked I am taking care that the setup of the development environment is straight forward and the project fully compilable just after the checkout because IMO it is critical that it works that way. If a developer want to customize the building environnement it should be able to do it after, but the default configuration must be completely versioned. Personally I put binary dependencies (dll, lib,...) on the svn, and generally internal tools I also put a pre-build version of tools because if they depend of the code it can be break silently as they aren't always tested. I hope that the fetch of dependencies will be integrated to the #build directive instead of being directly managed by the compiler.

Wouldnt something like maven work? Yes, you would fetch libs from the network,(at least once) but you can specify the lib version and the lib is downloaded to the local system. Maybe introduce something similar to the pom.xml.

Just have modifiers like c#, public, internal and private. And by default global scope for each library is internal. Unless specified

Containers are still terrible for reproducibility. Container itself is maybe reproducible but build of container isn't. rebuilding container from say Dockerfile gives you different container based on what Dockerfile is doing (pulling stuff from internet etc). To make it worse this is also completely non transparent because of caching - based on what layers are cached you either have thing based on what you already had or new thing. So even 2 people running build at exactly same time might be getting completely different thing. Don't trust anyone who claims that containers solve reproducibility of build. They just encapsulate runtime environment but in terms of builds they actually make things worse.

The solution is easy. Don't provide module support.

cetralized or decentralized is i dont think the cornerstone of communism, but the decreased freedom of expression for the individual, some supposed oppressive regimes did in fact let the people express themselves artisticly for instance, you dont have that with communism...

One word: SxS

1:33:49

It should be just like nuget. Have a package

Honestly i still dont know what an enum is...

Why emacs jonathan ?

If it's centrally controlled "communism" it's state capitalism. The only change from capitalism is the state takes the role of capitalist. The sorry definition of communism we have now comes from the failures of Lenin and Stalin's vein attempt to hide those failures, combined with the red scare. It's not a big deal. You're not wrong in using the phrase, since that's the modern definition. It's just like hearing somebody describe an apple as if it were a shoe. Co-ops and communes are good examples of communism, however effective. The purest examples of communism are mostly in the past, in tribal societies unchecked by central governments.

@mukco

4 жыл бұрын

Trace Myers 0 b