4 ms·

From the OP: > ...there is no escaping that the entire dot-com era was a disaster for IT/CS in general and for software quality and Unix in particular. The do

by ekidd 9y ago

From the OP: > ...there is no escaping that the entire dot-com era was a disaster for IT/CS in general and for software quality and Unix in particular. The dotcom era was almost 20 years ago. The Netscape IPO (1995) is now closer to the IBM PC (1981) than it is to 2017. Yes, a lot of terrible engineering happened during the dotcom boom, and most of it was proprietary code running on old-school Unix servers. If anything, Linux was a pretty solid alternative in those days. Sure, the GUI was a bad joke, and driver support was hit or miss. But if you chose your server hardware well, then Linux would give you years of uptime. Windows fell over several times a week. (Microsoft didn't get truly serious about quality and security until sometime around XP SP2, when they finally got sick of malware and buggy drivers.) So in 2017, what does a "bazaar"-style project look like? One modern example of a "bazaar" is Rust. (If you dislike Rust, you can insert plenty of other examples here.) All major design decisions are made through RFCs, after community feedback. There's no benevolent dictator, but rather a core team. Several key libraries like "serde" are actually maintained by separate teams. The compiler is released every 6 weeks. And yet, I have absolutely zero complaints about Rust's QA. There are plenty of test suites, and no code gets merged to master until those tests pass. To prevent regressions, somebody downloads all public Rust packages from crates.io, compiles them, runs their test suites, and checks for regressions. And so at work, we can upgrade our Rust compilers without fear. Now, to be fair, Rust is not for everybody. Not everybody wants "a better C++ minus the foot guns," or enjoys references and generic types. But if you do want those things, Rust is a good example of a community-driven project which delivers reliable, well-designed software. And I could point out 20 more modern open source projects with solid design and solid QA. We know how to do this now. And those inexperienced dotcom-era graduates now have houses in the suburbs. They're planning how to pay for their kids' college educations, and more than a few of them have some grey hair.

erikbye 9y ago
> And I could point out 20 more modern open source projects with solid design and solid QA. We know how to do this now. Then you should point them out, if they are of a standard you think people should learn from.
- gurjeet 9y ago
  I can name Postgres project in that category.
kayoone 9y ago
I agree with what you are saying but keep in mind that the article is already 5 years old.
Tobba_ 9y ago
I'm not sure if I'd consider Rust to be a perfect example of this style of design. Most language-level decisions seemed to be mostly dictated by what anyone was actually able to implement in the compiler, a lot of which was a nigh-incomprehensible mess that only a few people ever touched.
- ekidd 9y ago
  > Most language-level decisions seemed to be mostly dictated by what anyone was actually able to implement in the compiler This is getting off topic, but that hasn't really been my experience as a user of Rust. Yes, the compiler is full of weird ancient code, but that doesn't seem to constrain the design of RFCs. As far as I can tell: 1. The ancient code in the compiler means that some highly desirable features have taken a couple of years to implement. Granted, some of this is being fixed by the MIR work. But things like stable async/await are probably going to take a while. 2. Some desirable features are constrained by backwards compatibility with existing Rust source. This has affected the module system work, for example. 3. Rust has moved into a particular ecological niche: Precise control over memory allocation and copying, generic types that are monomorphized at compile-time, etc. The best-known language in this space is C++. And so Rust needs to wrestle with many of the same issues that C++ has, such as whether to allow partial specialization. It's certainly not a perfect process, and not everybody will be interested in the particular tradeoffs Rust chose. But it's still one of the best "bazaar"-style projects I've ever seen.
- kibwen 9y ago
  As a longtime follower of Rust development, I can say for certain that language-level features have never been rejected for being "too tough too implement". Quite the opposite, in fact: major compiler refactorings in order to improve the language happen regularly (e.g. MIR, a new intermediate layer which was needed to support an improved borrow checker (and close about a dozen soundness bugs)). Rust is happy to make the compiler implementor's life difficult in order to make the language user's life easier. Rust also doesn't require anyone proposing RFCs to be at all familiar with the compiler internals; all that RFCs require is a loose approximation of how a given feature will change the documentation and the theoretical language reference. And while the Rust compiler was certainly a mess before 1.0 (due to being written in an ever-changing version of itself), nowadays the compiler is much cleaner. It would also be mistaken to suggest that only a few people ever touched the compiler, as the Rust repo has, AFAICT, one of the highest contributor counts on all of Github (apparently higher than Ruby, Node, Swift, Go, Clang... so far the only ones that I've found that exceed it are rails/rails and torvalds/linux (listed, cheekily, as having "∞ contributors")).
frik 9y ago
> Yes, a lot of terrible engineering happened during the dotcom boom, and most of it was proprietary code running on old-school Unix servers. That's not true. Linux was very popular in 1998-2000 already, with RedHat and SuSE distros everywhere. Server software was usually written with CGI api, in C, Perl or PHP. Also Windows NT 4 and 2000 servers with ASP (classic) with web server software written in VBScript or JavaScript (yes, ASP classic had JavaScript/JScript support on server). Well known top websites of dotCom era like EBay and MySpace run on Windows servers back then. Back then Windows was a lot more popular on servers than nowadays. Also old school UNIX wasn't such a popular choice - name me five well known dotCom era startups that run on UNIX (in 1998 to 2001) instead of Linux or Windows. @downvoter: care to explain?
- deleted 9y ago
  [deleted]
- bluedino 9y ago
  Never heard of Sun? And don't forget about all the ColdFusion sites, a few of which are still around
  - frik 9y ago
    MySpace was ColdFusion, running on dotNet based ColdFusion runtime on Windows servers. SunOS - which well known dotCom era startups run their web servers on SunOS? (beside Sun) There was also SGI with Irix, etc but beside some graphical niche market, etc. How is this relevant to dotcom?
    - ThrowawayR2 9y ago
      > SunOS - which well known dotCom era startups run their web servers on SunOS? Pretty much everybody. Remember those absurd Sun Microsystems ads that claimed "We're the dot in dotcom"? They had $15bn in revenue in 2000; even mighty Microsoft only had $22bn that year. Linux was so far behind Solaris and the other commercial UNIXes in features and security in 1998-2000 that it wasn't even a blip on the radar.
- 9y ago

by ekidd 9y ago

erikbye 9y ago

> And I could point out 20 more modern open source projects with solid design and solid QA. We know how to do this now. Then you should point them out, if they are of a standard you think people should learn from.

gurjeet 9y ago
I can name Postgres project in that category.

kayoone 9y ago

I agree with what you are saying but keep in mind that the article is already 5 years old.

Tobba_ 9y ago

I'm not sure if I'd consider Rust to be a perfect example of this style of design. Most language-level decisions seemed to be mostly dictated by what anyone was actually able to implement in the compiler, a lot of which was a nigh-incomprehensible mess that only a few people ever touched.

ekidd 9y ago
> Most language-level decisions seemed to be mostly dictated by what anyone was actually able to implement in the compiler This is getting off topic, but that hasn't really been my experience as a user of Rust. Yes, the compiler is full of weird ancient code, but that doesn't seem to constrain the design of RFCs. As far as I can tell: 1. The ancient code in the compiler means that some highly desirable features have taken a couple of years to implement. Granted, some of this is being fixed by the MIR work. But things like stable async/await are probably going to take a while. 2. Some desirable features are constrained by backwards compatibility with existing Rust source. This has affected the module system work, for example. 3. Rust has moved into a particular ecological niche: Precise control over memory allocation and copying, generic types that are monomorphized at compile-time, etc. The best-known language in this space is C++. And so Rust needs to wrestle with many of the same issues that C++ has, such as whether to allow partial specialization. It's certainly not a perfect process, and not everybody will be interested in the particular tradeoffs Rust chose. But it's still one of the best "bazaar"-style projects I've ever seen.
kibwen 9y ago
As a longtime follower of Rust development, I can say for certain that language-level features have never been rejected for being "too tough too implement". Quite the opposite, in fact: major compiler refactorings in order to improve the language happen regularly (e.g. MIR, a new intermediate layer which was needed to support an improved borrow checker (and close about a dozen soundness bugs)). Rust is happy to make the compiler implementor's life difficult in order to make the language user's life easier. Rust also doesn't require anyone proposing RFCs to be at all familiar with the compiler internals; all that RFCs require is a loose approximation of how a given feature will change the documentation and the theoretical language reference. And while the Rust compiler was certainly a mess before 1.0 (due to being written in an ever-changing version of itself), nowadays the compiler is much cleaner. It would also be mistaken to suggest that only a few people ever touched the compiler, as the Rust repo has, AFAICT, one of the highest contributor counts on all of Github (apparently higher than Ruby, Node, Swift, Go, Clang... so far the only ones that I've found that exceed it are rails/rails and torvalds/linux (listed, cheekily, as having "∞ contributors")).

frik 9y ago

> Yes, a lot of terrible engineering happened during the dotcom boom, and most of it was proprietary code running on old-school Unix servers. That's not true. Linux was very popular in 1998-2000 already, with RedHat and SuSE distros everywhere. Server software was usually written with CGI api, in C, Perl or PHP. Also Windows NT 4 and 2000 servers with ASP (classic) with web server software written in VBScript or JavaScript (yes, ASP classic had JavaScript/JScript support on server). Well known top websites of dotCom era like EBay and MySpace run on Windows servers back then. Back then Windows was a lot more popular on servers than nowadays. Also old school UNIX wasn't such a popular choice - name me five well known dotCom era startups that run on UNIX (in 1998 to 2001) instead of Linux or Windows. @downvoter: care to explain?

deleted 9y ago
[deleted]
bluedino 9y ago
Never heard of Sun? And don't forget about all the ColdFusion sites, a few of which are still around
- frik 9y ago
  MySpace was ColdFusion, running on dotNet based ColdFusion runtime on Windows servers. SunOS - which well known dotCom era startups run their web servers on SunOS? (beside Sun) There was also SGI with Irix, etc but beside some graphical niche market, etc. How is this relevant to dotcom?
  - ThrowawayR2 9y ago
    > SunOS - which well known dotCom era startups run their web servers on SunOS? Pretty much everybody. Remember those absurd Sun Microsystems ads that claimed "We're the dot in dotcom"? They had $15bn in revenue in 2000; even mighty Microsoft only had $22bn that year. Linux was so far behind Solaris and the other commercial UNIXes in features and security in 1998-2000 that it wasn't even a blip on the radar.
9y ago