Serpent OS Infrastructure & Tooling Almost Completed

[ermo]

I think its more accurate to say that by picking up D you are effectively reducing the potential number of contributors to the project by a large margin. Sometimes the benefits of the language far outweighs this reduction in potential contributors, but I don't see how this is the case when comparing D with Rust. Both D and Rust effectively cover the exact same problem space. The only exception here is that D has an optional GC for the cases where you don't need top performance and don't want to manage memory it however can be argued that Rust solves this in a different way (i.e. it. tells you when there is a bug with memory access) however if you don't want to manage memory there is https://github.com/Manishearth/rust-gc.

There seems to be a misunderstanding here.

We're building the tooling for our project in Dlang because it works for us and I'm simply making the point that it's easy to pick up. People here are saying "but contributors!". And I'm going to counter that with "well, if you like the tools and processes, you're going to find a way to contribute and get to learn a nice language while doing so."

Keep in mind that most current Linux distributions today have tooling written in C/C++ and Python. Dlang is unequivocally an upgrade on that, while still being a very approachable programming language ootb IMVHO.

If others were building an alternative to a popular web-thing in Rust, I'd say "Good on them!", not "But golang is more popular for web stuff!" (or something similar according my specific preferences for PL "X" and its current market share).

[mdedetrich]

There seems to be a misunderstanding here.

I don't believe there is any misunderstanding, just differences of priorities and opinions. My claim is that you are ignoring that familiarity/approachability of language is a factor.

We're building the tooling for our project in Dlang because it works for us and I'm simply making the point that it's easy to pick up. People here are saying "but contributors!". And I'm going to counter that with "well, if you like the tools and processes, you're going to find a way to contribute and get to learn a nice language while doing so."

This is true, but its not the only factor. There are other factors as well (which is my point).

Keep in mind that most current Linux distributions today have tooling written in C/C++ and Python. Dlang is unequivocally an upgrade on that, while still being a very approachable programming language ootb IMVHO.

Don't disagree here, but its also not entirely true. While Python has obvious when it comes to performance and annoyance of not having static binaries, it is also much easier to learn and pickup compared to D for example. I would for example disagree with D being anywhere to approachability compared to Python, the people that usually such things form such an opinion due to familiarity bias.

If others were building an alternative to a popular web-thing in Rust, I'd say "Good on them!", not "But golang is more popular for web stuff!" (or something similar according my specific preferences for PL "X" and its current market share).

Ironically speaking if you wanted an easy to pick up language that is also decently fast while providing statically linked binaries, Go is actually what is being used the most (the biggest influx of programmers that Go got is from Python, not C or C++). While it is decently web/backend language, its actually biggest use in "glue" code which was heavily Perl's/Python's domain, i.e. its used a lot more in devops, scripts etc etc.

In my view this is largely because Go does have some severe shortcomings which does reveal itself more in web services

[dEnigma]

The fact of the matter is simply that Ikey Doherty enjoys writing, and is proficient in, D. If he forced himself to use Rust instead, there probably wouldn't be any progress, and without any progress people wouldn't want to contribute anyway, Rust or not.

[ermo]

I don't believe there is any misunderstanding, just differences of priorities and opinions. My claim is that you are ignoring that familiarity/approachability of language is a factor.

Wait, are you seriously going attempt to argue that e.g. Rust (per your earlier reply) is closer to C/C++/Python/Java syntax and idioms than Dlang re. familiarity/approachability?

Let? Immutable variables by default? Borrow checker? Ownership? Hello?

I'm not harping on Rust (or its rather well deserved success) here, mind. I have absolutely *nothing* against any of the above concepts (I was brought up on Standard ML, so let, immutable variables and strong higher order typing feels "right" to me).

But the fact remains that these concepts are different from the idioms and syntax in C/C++/Python/Java. If you have a passing familiarity with either of the aforementioned languages, Dlang will feel familiar to you. C++ was designed as an improvement on C. Dlang was designed as an improvement to C++. And Dlang has low-overhead abstractions such as slices, which will feel very familiar to Python programmers.

Heck, from personal experience, if you show Dlang to a C# programmer, it will feel very familiar to them too (anecdotes vs data be damned).

In contrast, Rust (from what I can tell) went a different route than C from the outset. For instance, unlike Java, C++ and Python, it has no classes? (I'm not endorsing OOP as a programming approach here, just mentioning it as a point of difference).

Really, it honestly feels to me like you appear to be approaching your argument from the principle of "But I want everything to be Rust. Because reasons." ?

And yes, I'll get to golang in a sec.

Don't disagree here, but its also not entirely true. While Python has obvious drawbacks when it comes to performance and annoyance of not having static binaries, it is also much easier to learn and pickup compared to D for example. I would for example disagree with D being anywhere to approachability compared to Python, the people that usually such things form such an opinion due to familiarity bias.

Relatively speaking, building performant prototypes in Dlang is way closer to Python in development speed than C and C++ (due to the default GC of Dlang).

And once you start using static types in Python, it's effectively the same cognitive overhead as I see it, but with 10x the performance uplift for the same time invested (depending on whether you use pure Python or a combination of Python and C modules).

And we haven't even gotten into the Dlang niceties such as CTFE, UFCS or nifty template features at this stage.

Ironically speaking if you wanted an easy to pick up language that is also decently fast while providing statically linked binaries, Go is actually what is being used the most (the biggest influx of programmers that Go got is from Python, not C or C++). While it is decently web/backend language, its actually biggest use in "glue" code which was heavily Perl's/Python's domain, i.e. its used a lot more in devops, scripts etc etc.

In my view this is largely because Go does have some severe shortcomings which does reveal itself more in web services

And my point is that Dlang is likely as easy to get started with/get into as Go, but with arguably the higher performance ceiling for the same time invested?

Now, if your argument was "But Dlang is not as well known", then I have already pointed out that it's close enough to existing languages such as C/C++/Python and Java that it is easy to read and pick up and that, in addition, it has some really nice properties that implies that it is a legitimate (not to mention worthwhile) improvement over those.

Tooling in SerpentOS is not (and will not be) our primary burden. In our case, we're really productive and happy with Dlang's features, its documentation and the ongoing investment into language and library improvements and we genuinely *enjoy* working with it to realise our goals.

Never lose sight of the fact that building and maintaining a Linux distribution is the real burden/goal here.

In closing, as much as I have enjoyed debating with you, at this point, it feels to me like the best outcome here is to agree to disagree tbqh.

Have a lovely day, Sir.

[szymon_g]

oh, great, another distribution. we were short of them! /s

[Michael_S]

As someone who worked professionally in C and then Java in the early 2000s, picking up D was child's play - and I mean that as a compliment, not an insult.

I just couldn't find any employers looking for D programmers, so I let my skills in the language rot. But it's a fine language.

I have nothing against Rust, and I would love to work with it too. But for someone coming from C and Java, Rust's learning curve is far steeper.

oh, great, another distribution. we were short of them! /s

Why do you care? Nobody's bullying people and forcing them to adopt it.

The packaging systems in Debian's .deb, Red Hat's .rpm, Arch's pacman and FreeBSD's portage are not the end-all-be-all of packaging. There's a lot of room left for innovation in terms of dependency management, reproducible builds, space optimization, and plain old speed. Conary (anybody else remember that one?), Nix, Guix, Xbps... what's one more? (Edit: There's also innovation space left in terms of ease of use for package maintainers. I know some of the projects building or using alternative package systems are trying to reduce the amount of work that packaging requires. I think SerpentOS's moss + builder is trying to do that too.)

Best of luck to you and your teammates, ermo (no sarcasm!)

[ermo]

The packaging systems in Debian's .deb, Red Hat's .rpm, Arch's pacman and FreeBSD's portage are not the end-all-be-all of packaging. There's a lot of room left for innovation in terms of dependency management, reproducible builds, space optimization, and plain old speed. Conary (anybody else remember that one?), Nix, Guix, Xbps... what's one more?

Best of luck to you and your teammates, ermo (no sarcasm!)

Cheers mate, thanks for the kind words.

And yes, I remember Conary. I was contributing to the Conary-based Foresight Linux project way back when and became a proper fan of what Conary could do. Many of the features/properties I've suggested/advocated for internally for the Serpent OS tooling are related to Conary, including our distributed build system, guaranteed dep complete releases (via the property of transitive closure) and a proposal for a declarative `system-model`, which is very useful for reproducing specific system configurations.

Other features/properties are inspired by Paludis, including up front guarantees and the idea that it ought to be perfectly possible (and essentialy transparent) to use source (metadata-only) and binary (metadata + compiled artefacts) packages interchangeably in a system, because this allows for some really convenient use cases in terms of local specialisations (compilation with specific flags, such as -march=native and what not) and convenient local development/testing/benchmarking of packages and stack upgrades.

[Michael_S]

Cheers mate, thanks for the kind words.

And yes, I remember Conary. I was contributing to the Conary-based Foresight Linux project way back when and became a proper fan of what Conary could do. Many of the features/properties I've suggested/advocated for internally for the Serpent OS tooling are related to Conary, including our distributed build system, guaranteed dep complete releases (via the property of transitive closure) and a proposal for a declarative `system-model`, which is very useful for reproducing specific system configurations.

Other features/properties are inspired by Paludis, including up front guarantees and the idea that it ought to be perfectly possible (and essentialy transparent) to use source (metadata-only) and binary (metadata + compiled artefacts) packages interchangeably in a system, because this allows for some really convenient use cases in terms of local specialisations (compilation with specific flags, such as -march=native and what not) and convenient local development/testing/benchmarking of packages and stack upgrades.

Oh wow, I hadn't seen anyone reference Conary in about seven years. That's really cool that you worked on it! I used to run Foresight Linux.

Your experience there makes me even more inclined to believe that you have good context for the design decisions you're making.

And I forgot to add one more area of innovation for package managers, which SerpentOS does look to try to address: lowering the burden of effort on package and distribution maintainers. I understand that package management is inherently work-intensive, and anything that can be done to reduce the effort is valuable.

[ringo32]

he started over and over again a distrobution... i am sure he wil stop again if he can't handle the pressure , he is a monster.. but never finished stuf.