| programmerjake | read this interesting article about dependencies and comparing rust, go, C, debian, and a few others: https://wiki.alopex.li/LetsBeRealAboutDependencies | 02:17 |
|---|---|---|
| programmerjake | basically, C programs have waay more dependencies than you'd expect, they're just not obvious so people look at a Rust program with 200 dependencies and say wow, crazy but don't realize that's average for non-trivial programs and not unique to Rust at all. | 02:19 |
| ghostmansd[m] | Let's be real: author confuses static linkage and build models, and thinks that the fact go offers go build automagically solves the infamous dependency issue. No, it's not go build, it's simply the fact that the program is static. "But mah boi you can do it in C!" — you might claim. And yes, indeed, you do. | 05:13 |
| ghostmansd[m] | I spent a lot of time reading this article, and kinda feel I simply lost it. There's a much simpler summary: dynamic linkage might be harmful depending on how the tech process is organized. It has nothing to do with the fact that C has no analogues of "go build". | 05:19 |
| ghostmansd[m] | http://harmful.cat-v.org/software/dynamic-linking/ | 05:19 |
| ghostmansd[m] | The fact that go prefers static binaries has much to do with the fact that Plan 9 people participated, by the way. | 05:21 |
| programmerjake | hmm...i totally ignored dynamic vs. static linking cuz i think that wasn't the article's point as much...just dependencies in general, not dynamic libraries specifically | 05:31 |
| ghostmansd[m] | The dependencies issues are not solved at all. The approach go or Rust use is simply "let's make these poor random folks responsible for dependencies, let 'em download the full GitHub" and similar. As for go, don't know as of now, but initially it even couldn't choose the version or branch from GitHub to take. That's what these people call "we solved dependency hell"? Hell no. | 05:37 |
| programmerjake | and how C has just as many dependencies, just they are often less obvious because they might be vendored or copy-pasted or full on custom (e.g. vlc's xml parser), rather than the way rust, npm, go, etc. tend to work, where any non-trivial library is usually worth adding as an external dependency rather than vendoring or reimplementing it yourself | 05:37 |
| ghostmansd[m] | So, instead of being a package management pain in the ass, these dependencies end up being a pain in my ass. | 05:37 |
| programmerjake | idk... | 05:38 |
| ghostmansd[m] | I'm a fan of static linkage BTW. | 05:38 |
| ghostmansd[m] | So kinda agree. | 05:39 |
| ghostmansd[m] | And also, taking the vlc as an example... Hell yeah. Why don't take e.g. `cat`, compiled statically, and then compare? | 05:41 |
| programmerjake | cat is simple in the extreme... | 05:42 |
| programmerjake | if it links to more than an arg parsing library i'd think there might be something wrong | 05:43 |
| ghostmansd[m] | Author mixes several unrelated concepts: | 05:43 |
| ghostmansd[m] | 1. Static linkage has some pros and cons, and some languages don't use dynamic linkage at all. | 05:43 |
| ghostmansd[m] | 2. Dependencies can be handled at different layers. | 05:43 |
| ghostmansd[m] | 3. C doesn't have either build system or dependency management or whatever. | 05:43 |
| ghostmansd[m] | (well, they might be related a bit, but not dramatically) | 05:44 |
| programmerjake | :) | 05:45 |
| *** kylel1 is now known as kylel | 12:46 | |
| *** exit70[m] <exit70[m]!~exit70@user/exit70> has left #libre-soc | 18:19 | |
| octavius | When looking at yosys diagrams, I wanted to look at a specific process. Without calling "proc;opt;show", is there a way to focus on a specific process? I tried "select $group_1" (name of the process), but I got a "Selection did not match any module" warning. | 19:54 |
| octavius | I found my issue, but wondered if there was a way to focus on processes (not modules) | 19:55 |
| lkcl | the concept of "processes" does not exist | 21:05 |
| lkcl | don't run "proc opt" | 21:05 |
| lkcl | just "show {modulename}" | 21:05 |
| lkcl | and if you cannot understand what you have done and cannot relate it to the graph, then that is a clear sign that you should be subdividing the design into smaller submodules so that you *can* understand the graph | 21:06 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!