Multi-process Firefox brings 400-700% improvement in responsiveness - <AUTHOR> https://techcrunch.com/2016/09/02/multi-process-firefox-brings-400-700-improvement-in-responsiveness/ <comment><USER2> _"We can learn from the competition," said Dotzler. "The way they implemented multi-process is RAM-intensive, it can get out of hand. We are learning from them and building an architecture that doesn't eat all your RAM."_

That's the money quote here. I've been waiting for this for a long time actually. Every browser I've tried except Firefox just basically eats all my RAM and other app performance (e.g. compiling stuff) goes down the toilet.

Then on the other hand FF has not been so snappy and responsive traditionally. So responsive + soft on RAM is the combination I've really been waiting for. Let's hope they can deliver.

<comment><USER3> A few years ago if you'd told me FF would be the RAM-sensitive browser, I'd have laughed you off the internet.

<comment><USER4> And they're still at it, too: [https://areweslimyet.com/](https://areweslimyet.com/)

<comment><USER5> Maybe I'm misreading things but it looks like it's been constantly getting worse since 2012?

<comment><USER6> They're getting worse at a linear pace, while hardware improves exponentially. Effectively that's a pretty good improvement each year.

<comment><USER7> Hardware does not get exponetially better. Maybe it did in 90ties and 00ers. Right now hardwardware gets slimmer, less power consuming and cheaper. But not better. My 12 year old (then mid-end gaming pc) is pretty much exactly as fast as my current, 2(?) year old office machine. (x264 and other mulit-threaed cpu benchbmarks) But it costs a fraction and uses next to no energy.

/edit: Yes this is wrong. I made a mistake. My "gaming" desktop is "only" 8 years old. It has a 4 core AMD processor. It's on par with current atoms.

<comment><USER8> Love the redundancy of "90ties", but what's the etymology of "00ers"?

<comment><USER9> Augts?

<comment><USER8> But then, following the pattern it'd be 00ts or 00ghts...

<comment><USER6> two-thousanders? Not sure if anybody actually says that

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I switched to Firefox from Chrome about 12 months ago. It isn't as good as Chrome, but I was trying to reduce my Google dependencies.

It has been mostly fine (except for an annoying OS-X multi-screen bug where it screws up the sizing).

I was really looking forward to this feature to help close the gap on Chrome performance.

Until August (I think Firefox 48.x), when it became unusable on any site with... something. I'm not entirely sure what triggers it- I don't think it is just video alone. Something make the entire browser lock up entirely for minutes, and sometimes it even runs out of memory and I have to kill it via the OS.

No add-ins (except for Firebug).

Frustratingly, I can't replicate it well enough to be a useful bug report.

I'm _this_ close to switching back. Muscle memory and shortcuts to Firefox is the only thing stopping me.

So.. this will be great, but please make it a workable browser.

<comment><USER11> I've found Firefox performance to be absolutely awful at work on OS X. I have no issues at all with it at home on Linux, and didn't have any issues in my previous job on OS X either. I'm not sure if it's OS X specific, a change in recent versions, this laptop being underpowered, or the nature of the work I do (a lot of video stuff), but anything JS heavy severely slows down or locks up the browser. And if anything, it's gotten worse over the last few months.

I have to use Chrome for anything video related or JS heavy (monitoring/graphing stuff for the most part), but I'd hate to switch to it for everything. There are too many addons that I rely on in Firefox, on top of my general dislike for Chrome's minimalist UI and standard Google privacy concerns.

I've tried turning on the config option for electrolysis, but it breaks some addons, so that's still a no go for me for now.

<comment><USER12> For a while now I've suspected that memory management on OS X is actually terrible. I have no really proof, because I just run everything memory intensive on Linux. At work I have a few Python script that eats a few gigabytes of memory, it reads in data, and basically just loops over it, selects the stuff it needs an generate a few XML file (10 to 20MB worth of XML).

All this takes maybe five minutes on Linux, on Mac OS X it will freeze the OS for long periods of time and take 40 minutes to run. In terms of hardware, the Linux box has less RAM, CPU and slower discs.

Regarding the Javascript stuff: Part of it may be that Chrome is the new Internet Explorer. People develop on and test for Chrome (because everyone uses Chrome, right?). Chrome does have the better Javascript engine, still, I believe that much of the slow Javascript on Firefox (an other browsers) could be avoided if people bothered testing a little more.

<comment><USER13>
        Chrome does have the better Javascript engine, still, I believe that much of the slow Javascript on Firefox (an other browsers) could be avoided if people bothered testing a little more.

All major engines are pretty much comparable speed-wise. The biggest difference is probably in memory management (of the HTML & JS engines), which may favor some forms of site/lib structure and architecture over others – that's IMHO where the majority of slowness comes from (for any browser).

</comment></comment></comment></comment><comment><USER14> This should come as no surprise. It has always been an epic architectural mistake to use the same single non-reentrant Javascript engine to both render the UI and run JS for webpages in Firefox. This change will finally undo that huge mistake made so very long ago.

<comment><USER15> JavaScript was little more than a toy scripting language used to animate stuff and change layouts when html/Css wouldn't fit for the greatest part of firefox's early existence. At the time it was probably the appropriate decision.

Now, it's a huge burden on Firefox and it's good to finally see progress on this front.

<comment><USER16> Since Javascript is just a language that happens to execute client-side within the browser, why can we not use an existing language syntax (or an existing language entirely) for this purpose? For example, Go, Python, Rust, or perhaps Perl? It feels like a broken shell scripting language that really should have been replaced.

<comment><USER14> You can, but you should not run the UI script code _on_ the same non-reentrant JS engine that executes scripts delivered from the internet at large.

By doing so (running both the UI code _and_ scripts from the internet on the same non-reentrant JS engine) means that only one gets to run at a time (either UI code or JS from the internet). That's why FF's responsiveness sucks at times, any long running JS script from the internet also prevents the UI code from running.

The JS engine should either have been reentrant (so UI code could run even though some random internet script was still running), or there should have been two independent JS interpreters loaded, one used for the UI code only and a second for all the JS from the internet.

</comment></comment></comment></comment><comment><USER17> Instructions for enabling this feature (via about:config) are provided in the author's prior article on the topic: [https://techcrunch.com/2016/06/10/mozillas-multi-process- arc...](https://techcrunch.com/2016/06/10/mozillas-multi-process-architecture- project-cleared-for-takeoff/)

<comment><USER18> Please be aware that if you force-enable e10s while using incompatible addons, you'll end up with a very slow browsing experience. [http://arewee10syet.com/](http://arewee10syet.com/) has a compatibility list for some of the most popular addons.

<comment><USER19> Seems like e10s gets disabled if there is a incompatible addon activated.

Not sure I would trust that list, the only two addons I run, is Tree Style Tab and Greasemonkey, both listed as compatible on the website, but going to about:support shows:

> Multiprocess Windows 0/1 (Disabled by add-ons)

<comment><USER20> Addons are not supported by default in e10s mode on the release channel yet.

</comment></comment></comment></comment><comment><USER21> Every odd browser performance topic is dominated by people claiming Firefox has been faster and more scalable than Chrome for years. Every even one is dominated by people claiming the opposite.

This thread seems to be the latter, my experience is the former. If you see bad performance/memory usage with a small number of tabs, are you sure that it's not due to bad plugins?

I think about:memory and about:performance could be helpful. I seem to recall they used to have some reporting on known problem plugins (perhaps as part of [https://www.mozilla.org/en-GB/plugincheck/](https://www.mozilla.org/en- GB/plugincheck/)).

</comment><comment><USER22> Does anybody know more about how Mozilla manages experiments? I'd always assumed that all users downloaded an identical binary and got the same behavior. How do they assign 10% of their users to an experimental group?

Is it possible that two users will see different functionality when they are both using the same OS and release, say Firefox from the latest version of Ubuntu?

<comment><USER23> As with most native A/B tests, the binary probably ships with code for both functionalities. When the browser launches for the first time they generate a random number, and if it's below a certain threshold you get variant A, above you get variant B. The information gets persisted on disk so it remains unchanged across sessions.

<comment><USER24> It seems that there is some communication back to Mozilla, since they claim that they can increase or decrease the number of users in each group over a week; that seems unlikely to come in the form of a new binary.

<comment><USER25> Non-stable channels get frequent builds, so it's not implausible it's a new binary.

</comment></comment></comment></comment><comment><USER26> Its incredible multi-process took this long. Just goes to show you that your architecture decisions last a long time and are often difficult to change. Chrome had this from day one and never had a big and old codebase to worry about. Yet it took Firefox many years to get multi-process going and my understanding is that its much more limited and simpler than what Chrome or Edge do.

I'm also a little surprised there hasn't been an attempt to launch a completely new Firefox from the ground up. Regardless of what they're doing right now, its still a legacy code monster and much more laggy than the competition. Maybe this is Servo's ultimate purpose, but every Firefox advance is welcomed but always feels like another layer of lipstick on this pig.

Disclaimer: I use Firefox as my main 'non-work' browser several hours a day. Its good, but its very obvious when I'm not in Chrome from a performance/stability perspective.

<comment><USER27> > I'm also a little surprised there hasn't been an attempt to launch a > completely new Firefox from the ground up.

It's interesting how the history goes.

We had Netscape 4, and it was crap (remember when resizing a window reloaded the whole page?)

So they was a ground-up rewrite of the rendering engine, resulting in Gecko, which was put in Mozilla.

Gecko was great but Mozilla was a bloaty amalgamation of features, so this was created a pared-down Gecko version called...

~Phoenix~ ~Firebird~ Firefox, which had the great rendering engine and a lean, native-like UI.

Then there was KHTML/KJS which was built for KDE, which had a lean architecture but didn't have the investment to get the compatibility 100% there...

Which Apple then poured into the project in their fork to WebKit, which paid off in spades on the resource-limited iPhone a couple years later.

But Safari was only on the Mac (aside from their "Cocoa on Windows" version and a few open source ports), which Google took as a reason to create...

Google Chrome, where the biggest innovation was rendering each page in its own process (since Safari could freeze up due to one page going in an infinite loop in JavaScript).

So will someone out-Firefox Firefox and do what Chrome was to Safari for multi-processing? Take the rendering engine and put a new chrome on top of it?

<comment><USER28> A few additions:

KHTML was originally forked from QHtml (part of Qt) I believe (or they shared the same origin?).

Webkit later became a Qt component, the circle of life.

I would argue chromes biggest innovation was the UI, putting the address bar as part of the tab where it belongs (cue holy war) and better tabbing in general.

Mozilla was also the first to integrate the search and address fields, which they unfortunately stripped out of firefox (and many people think chrome introduced it).

<comment><USER29> > Mozilla was also the first to integrate the search and address fields, which > they unfortunately stripped out of firefox (and many people think chrome > introduced it).

Do you know when this was introduced/removed? I'm curious as to what this implementation was as I don't recall when this happened.

<comment><USER28> It was in all versions of the Mozilla suite: [https://en.m.wikipedia.org/wiki/Mozilla_Application_Suite](https://en.m.wikipedia.org/wiki/Mozilla_Application_Suite) . It was never a feature of Firefox.

</comment></comment></comment></comment></comment><comment><USER30> At last, you'll be able to view other pages while Facebook's Javascript is in an infinite loop.

With thousands of MIPS and a gigabyte of memory on the job, it had better be responsive. It's pathetic how much compute power it takes to run a browser. Even when the pages aren't doing anything interesting. It's not like they're running a 3D game or something.

</comment><comment><USER31> I've got 732 tabs open at the moment and performance is still fine. The upper limit for my machine seems to be about 745 ish - much beyond that and FF runs out of video memory or something (new tabs render sites half black).

<comment><USER32> You need to get a better handle on your life.

<comment><USER31> Haha yeah :) TBH I have no idea what half of them are any more. I've just never gotten around to pruning them since FF works well enough and load up time isn't too bad (< 12 secs).

</comment></comment></comment><comment><USER33> Why? Except because of memory allocation serialization impact, there is no reason for a multithreaded process being slower than multiprocess. And if that's the cause, it could be solved using multiple heaps.

<comment><USER34> My guess is that the multithreaded-only design wasn't as good at exploiting the inherent per-tab parallelism. The original architecture probably had some synchronization points (perhaps related to the common GUI code) that did not allow processing each tab truly independently. Regarding memory allocation, yes, in theory one should be able to try to avoid sharing data across threads, which should eliminate serialization on memory allocation and deallocation. But I can easily imagine that in practice, in a codebase that was not explicitly designed to process each tab in parallel, you'll still end up sometimes sharing data across threads.

I imagine they could have instead changed the architecture to be multithreaded in such a way to avoid my imagined sequential bottlenecks, but performance is not the only goal in a multprocess architecture. Sandboxing is another design goal, and that cannot be fully achieved with a multithreaded design.

This is all speculation on my part, so if anyone who actually works on the Firefox codebase could correct me, that would be very welcomed.

</comment></comment><comment><USER35> I'm surprised by the responsiveness claims because my ancient Windows PC runs FF superbly. I think Win10+FF is already more responsive now than it has ever been.

I am also using Ghostery, however, with virtually everything blocked. It wasn't my intent to block ads, but that's mostly how it works out.

<comment><USER36> It depends on operating system. For instance on OSX Yosemite Firefox is sluggish, yet on Windows 10 it's fast. People should really mention what operating system they're running when they say "x is slow"

</comment></comment><comment><USER37> The speed is great as long as youtube doesn't autoplay a new video which freezes the whole browser for me until it is done loading.

<comment><USER38> Whole browser freezez for me on any amazon page. Just when it starts rendering it freezes everything inside Firefox window for a few seconds. It's so annoying that I'm considering dropping Firefox after over a decade for Opera or Brave browser.

<comment><USER10> I wonder if this is the same issue as I'm seeing: [https://news.ycombinator.com/item?id=12437130](https://news.ycombinator.com/item?id=12437130)

Amazon works for me though. Hmmm.

<comment><USER38> Very similar issue! My gf walked into it recently on ArchLinux, she had the same problem, for her e10 was enabled by default. When she visisted pons.com the whole browser was frozen for at least 10seconds, and if it didn't unfreeze itself after that time, it was just consuming memory and freezing whole OS until Linux killed Firefox process. My issue was solved by disabling e10s, for her it didn't help so she switched to Opera already.

<comment><USER39> I wouldn't switch to Opera though. Use vivaldi instead.

</comment></comment></comment></comment></comment><comment><USER40> This will probably have significant implications for web worker behavior.

If memory serves, workers are unable to directly communicate with each other in Firefox when the UI thread is blocked, because message handling runs on the same process as the UI thread. Chrome doesn't have that limitation since it's already a multi-process architecture.

</comment><comment><USER41> Ah, so because I use addons I might not be seeing these benefits for some time? Good to know.

Chrome is right now way faster for me, but I prefer using FF so I am in the Mozilla camp right now. Eager to see this rolled out. Early versions of e10s were very fragile and not so usable for me, so I switched it off.

<comment><USER42> I use quite a few add-ons and my e10 was disabled because of them. I force enabled e10 using Mozilla's guide [https://wiki.mozilla.org/Electrolysis#Force_Enable](https://wiki.mozilla.org/Electrolysis#Force_Enable) and didn't notice anything breaking (yet).

<comment><USER43> It's usually less so things breaking and rather just being slow. For example, if you use NoScript, it often takes really long to load up a page, because that's when NoScript becomes active, and because NoScript isn't yet properly e10s-compatible, it just forces Firefox to do things in a single-process way. But that actually makes things slower than when Firefox is running without e10s.

about:performance is a rather good indicator, if an add-on is causing slow- downs.

</comment></comment></comment><comment><USER44> I've been running Firefox Developer Edition (which has multiprocess) for a few weeks now, it's noticeably faster for most sites.

</comment><comment><USER45> I use both FF and Chrome. Chrome is more heavy-duty, so I use it for Dedicated Browsing. I've set it such that when something calls me away and I close Chrome, the tabs will reopen so I can continue where I left off. But sometimes I'll be doing something in another program and need to look up something quickly. In such cases, I don't wanna wait while Chrome reopens 11 tabs so I'll use FF instead. My FF-tabs aren't saved between sessions, so I only see a single fresh tab when I open it.

</comment><comment><USER46> You can install v51 nightlies from here: [https://nightly.mozilla.org/](https://nightly.mozilla.org/)

</comment><comment><USER47> I don't know. "Eating up all my ram" seems perfectly acceptable to me at first glance. I purchase ram and use it in my computer for expressly this purpose: to improve the responsiveness and snappiness of programs.

Where do you draw the line at what's acceptable use of ram and what's not? I have 32G on my desktop, is it unacceptable that chrome is using 8G?

<comment><USER48> I think it's "inefficient use of RAM" that they're talking about.

If Firefox should conceivably run in 8GB, but ends up trying to use 33GB (in your case), that would obviously be bad.

Mozilla just targets efficiencies that include people with much, much less RAM than you for their baseline.

</comment></comment><comment><USER49> Is there a list of commonly used extensions that are (in)compatible?

<comment><USER11> [http://arewee10syet.com/](http://arewee10syet.com/) has a list of addons and their compatibility.

I tried turning on the about:config option and the URL bar broke, so obviously something I have is incompatible - I suspect it's Classic Theme Restorer, although that site does list it as compatible.

</comment></comment><comment><USER50> Ive been testing Firefox e10s as in multiprocess Firefox for months now (in Nightly, and even before that).

At some point it became very usable and it still is today. HOWEVER while the interface is, yes, much more responsive, it is also NOTICEABLY slower.

I ended up reverting recently and I'm using single process Firefox right now. Its fast even thus from time to time the UI may block if there's heavy stuff going on.

Whatever makes e10s slow they gotta fix it... I suspect there's a lot of synchronization code.

</comment><comment><USER51> I hope this works out well, I often see my firefox freeze due to heavy extensions, and would much prefer if it just froze one tab. For me, higher ram usage wouldn't bother me if it meant no freezing, but I imagine it does matter to most of the audience, and it's too much effort to develop two feature sets.

</comment><comment><USER52> Is this different than multithreaded? What are the benefits? Is it really just about isolation/sandboxing?

Why so much RAM? I thought the OS could share pages across processes...

</comment><comment><USER53> How much extra memory is now used by it? All this improvement is meaningless if it hits swap on a typical machine.

<comment><USER54> We saw about 20% overhead going from one process to two.

</comment></comment><comment><USER55> On which OS? On OSX I almost gave up on ff because it frequently freezes for no apparent reason.

</comment><comment><USER56> Wonder if Graal.JS could offer any improvements to the browser

</comment><comment><USER57> So, finally, some emerging consensus among packers that pthreads is a brain- dead concept, and thousands of its advocates are just narcissistic idiots, loving to hear their voices?

</comment><comment><USER58> A pity it's now practically useless, since many add-ons need modification to keep electrolysis enabled. In a year or so things will be better I hope.

<comment><USER59> Only if addon authors fix them. Afaik mozilla devs aren't planning on adding additional compatibility shims.

<comment><USER18> There's currently a compatibility shim in place, however using it can lead to poor performance.

<comment><USER59> there are multiple shims, i'm saying they're not planning on adding new ones.

</comment></comment></comment></comment><comment><USER60> Does that mean my website will now fit on a 700% narrower screen?

</comment><comment><USER61> Why is there still a browser capable of having its performance improve by 400-700%? This browser is a decade old. It is clearly the CPU and RAM hog everyone has said its been.

<comment><USER43> Responsiveness is not the same as performance. Responsiveness is how quickly it responds to user-input. So, for example, if you click on the Back-Button, then it highlights the Back-button to let you know that you have indeed successfully clicked the Back-button and that it is working on going back a page. How quickly it highlights that button after you've clicked it, that's how responsive it is in that aspect. Actually going back a page, i.e. loading the page from cache and rendering it, that's then again a performance-metric.

But you are also quite clearly underestimating how terrible modern browsers are. Mozilla is also currently working on a research browser called "Servo", which has been written completely from scratch and employs a more modern architecture, and that isn't too far away from 400-700% performance increase over other browsers in certain aspects.</comment></comment>


The Emacs Package Developer's Handbook (2017) - <AUTHOR> https://alphapapa.github.io/emacs-package-dev-handbook/ <comment><USER3> Oooh, [https://gitlab.com/ambrevar/emacs-gif- screencast](https://gitlab.com/ambrevar/emacs-gif-screencast) looks interesting.

There's a ton of good stuff in here … there goes my weekend. The organisation is a bit idiosyncratic, but I think it works.

<comment><USER4> [https://asciinema.org/](https://asciinema.org/)

I sometimes record deployments, bug fixes, refactoring, etc...

</comment></comment><comment><USER5> I just started reading the geiser.el elisp code with the long-term objective of obtaining evaluation support for kawa scheme. I don't feel I master elisp yet but I'm at the point where I'm not afraid of hacking together some dirty elisp code. Even so, I didn't think there were so many relevant topics I didn't even hear about. Great resource for my objective and skill level I guess.

<comment><USER6> Interesting, I was just starting to dig into geiser as well! (But for Gerbil scheme, though Kawa is interesting to me as well)

<comment><USER5> I'm interested in kawa for scripting an application I'm trying to make in java/scala. Scala's Ammonite somehow works too and I just wrote one of those dirty hacks to wrap an ammonite repl running in a term window so I could use ammonite's completion and execution in an org-mode buffer to explore/script things. However, sometimes lisps make interactive exploring a little simpler and that's why I initially embedded clojure. Clojure's emacs tooling is spectacular, so much that it feels like I'm actually extending emacs with java libraries. But with clojure I had 2 problems:

\- embedding a clojure repl the usual way after the update to java 11 started giving some error I couldn't solve. Sure, I could just juse java 8. Or use my project as a jar dependency, but doing java -jar ... and already having a nRepl server running is simpler than adding a jar to the classpath from a repl

\- licensing: I still don't know which license to use between bsd/apache and gpl, but in case I go with the gpl there is that epl/gpl incompatibility for distribution. However, even for this I think there are workarounds that would be ok for my case

The point is that kawa doesn't have these last 2 problems at all, and writing geiser support is a good elisp practice that also produces something that may reveal itself useful later.

And that's why I'm interested in continuing the geiser-kawa attempt that [https://gitlab.com/mthl](https://gitlab.com/mthl) posted at [https://gitlab.com/jaor/geiser/issues/55](https://gitlab.com/jaor/geiser/issues/55). I evaluated several other languages/platforms before choosing java, but eventually only java and javascript had the killer library. I went java.

</comment></comment></comment><comment><USER7> I am always amazed at how many libraries and tools there are for programming in Elisp. One of the things that make it so fun.

<comment><USER8> It's always been a really rich environment, but it's amazing how much dynamism the whole ecosystem gained by introducing package.el and ELPA, plus to a lesser extent use-package.

Without package management, keeping even relatively simple Emacs setups working was not that easy. Now, it's trivial. And thanks to that lots of parts have been modernized and the whole community is really vibrant.

Emacs has now a really nice completion framework (avy) and auto-complete (company). Plus, IMHO the best git porcelain of any platform (magit), outliner (org) and mail user agent (notmuch, plus some bits of gnus).

<comment><USER9> Yeah sometimes I feel like I don't want to use emacs anymore, but then I think about magit and org.

After using spacemacs for a couple years, I've started rebuilding my own. There was too much stuff going on I didn't understand and when something breaks I have no idea what to do.

Now that I know about general, ivy/swiper/counsel, use-package, and some of the other building blocks... It's pretty cool.

You know what it reminds me of? npm ~ducks~

<comment><USER8> I do agree that building your own is the only way to progress learning Emacs and most complex pieces of software. I would also add that relying on as few packages as possible, and some that are well-known and maintained is important.

My .emacs is very short, and I strive to simplify it as much as I can so that it doesn't become fragile or a liability to maintain. It's just a bit of setqs, use-package boilerplate, and 2-liner configurations for ido, company, org, magit, notmuch, pdf-tools, auctex, ess, anaconda and a few others.

That way I avoid npm-like insanities.

<comment><USER10> Do you live as much as possible in Emacs?

How do you deal psychologically with all the niceties that you give up with so little configuration?

The first innovation outside of Emacs that springs to mind is find-and-replace that lets you easily switch between literal, case-insensitive, regex, current line/selection/whole file, and current file/across multiple files.

Do you just have to tell yourself, "Well, other environments have such niceties, but I'm giving them up in exchange for other niceties that Emacs offers?"

<comment><USER11> > _The first innovation outside of Emacs that springs to mind is find-and- > replace that lets you easily switch between literal, case-insensitive, > regex, current line /selection/whole file, and current file/across multiple > files._

Not sure what you mean, but from my experience, you can do all that in Emacs. They're not one feature, but a couple distinct one. Incremental find/replace with or without regex, literal, case-insensitive _within a buffer_ is one facility, easily accessible through C-s / C-r / C-M-s / C-M-r keys (they're all for the same feature, just "s" for forwards, "r" for backwards, also press Meta for regexes), you can switch "modes" on the fly, switch to replacement mode, or even show the whole list of matches, each with a single keychord.

Incremental searches across multiple files or open buffers can be done too, though it's not something I've tried personally (I usually pawn off multi-file searches to grep / find+grep combo, which have a built-in support in Emacs, and AFAIR also a polyfill for Windows). Consult [0] for discussion.

Editing-wise, I can't think of an outside-Emacs innovation that couldn't - <USER2> wouldn't - get ported over, ending up better than in its source place because of how Emacs deep interoperability makes all features together better than the sum of them. The main convenience you're abandoning when switching from an IDE to Emacs is the lack of deep semantic features - like _really_ smart autocomplete, or high-quality automatic refactors - but with the development and popularization of Language Server Protocol and Debug Adapter Protocol, one can hope this won't be a problem much longer.

\--

[0] - [https://www.reddit.com/r/emacs/comments/7tf1ln/incremental_s...](https://www.reddit.com/r/emacs/comments/7tf1ln/incremental_search_with_multiple_files/)

<comment><USER10> _Not sure what you mean, but from my experience, you can do all that in Emacs. They 're not one feature, but a couple distinct one._

That's why I said "easily switch between". As in, a single piece of UI. If you've used any modern editor or IDE I'm sure you've seen this.

 _I can 't think of an outside-Emacs innovation that couldn't - and wouldn't - get ported over_

The person I was talking to uses fairly stock Emacs, so that's not a useful point.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I'm in the middle of bundling some of my Elisp code into a production-quality package, so this will come in handy. Thanks 'rauhl for posting it!</comment>


American Growth Has Slowed Down. Get Used to It - <AUTHOR> http://www.politico.com/magazine/story/2016/09/economic-growth-jobs-recession-slowed-technology-214220 <comment><AUTHOR> "So despite all the cheerleading from the Bill Gateses and Mark Zuckerbergs about our recent innovations, Silicon Valley and even many economists have failed to take into account something crucial: The economist's basic measure of technical progress has been lagging. Overall, growth comes from improved productivity. ... And the data show the sad fact that TFP growth since 1970 has been barely one-third of the rate achieved from 1920 to 1970."

This makes me wonder, in a head-to-head measurement (which would be difficult to do in any sort of correct fashion) would refrigeration beat computers in a head-to-head competition of what raised GDP output more? I'm guessing it would. How about the combine harvester?

Morning dose of humility to our era and work.

</comment><comment><USER2> any system that relies on constantly rising consumption of resources (= growth) on a planet with finite resources is bound to fail at some point anyway. Perhaps it's time to think about better metrics?

Yes, there can be growth without a rise in consumption of resources, but realistically, as people make more money, they will end up buying more stuff/ taking more flights etc.</comment>


Building Sites with HarpJS - <AUTHOR> https://jaenis.ch/blog/building-sites-with-harpjs/ <comment><USER2> I'm curious why a fade-to-pink background was thought to be preferable, particularly in terms of reading comprehension.</comment>


Chronic - Python Instrumentation - <AUTHOR> https://github.com/davidcrawford/chronic

<comment><USER2> This is cool. I implemented an extremely similar system for my last job. The data was dumped into mongo and then we visualized it with stacked bar graphs.

One thing to consider since you're using a count+total model is that the most interesting timings will often be the 90th or 99th percentile, so by calculating averages you might be missing useful information.

I ran into some issues with the implementation after switching to using an async framework since the code was no longer a series of nested function calls. Since the current best practice is coroutines where this will still work I think it's okay, but you should consider how someone using callbacks might time their code. In my case I was in a hurry so I manually called the equivalent of your __enter__ and __exit__, but it was pretty ugly and left a lot of room for bugs.

<comment><AUTHOR> You're totally right on the averages. I'll add the percentiles but maybe I can also make it extensible somehow.

I haven't thought about callback code at all... if you have any ideas or sample code to share, it would be great if you could create a github issue for it.

Thanks!

</comment></comment><comment><USER3> See also: [http://pycounters.readthedocs.org/en/latest/](http://pycounters.readthedocs.org/en/latest/)

<comment><AUTHOR> Cool, thanks for the link. I like their logging support.

</comment></comment><comment><USER4> Trivial but useful. Next time, instead of kicking in my own custom timing decorator (5-liner, but...) I'll probably use this. [Edit: pycounter looks even nicer, didn't heard of them before, thanks for sharing!]

The only downside I see, it does record function name, but doesn't record module name (and, for class members, classname). For example, it wouldn't be too useful to see "authorize" instead of "ppp.common.authorize" in RADIUS server profiling logs. :)

<comment><AUTHOR> Yeah, the simplest thing to do would be to add the module name, which I may do. You can also pass a name parameter to the decorator.

</comment></comment><comment><USER5> We built a similar decorator/context manager for profiling, but it is really much more useful if you can export the data to statsite + graphite so that you can graph and view it on an on going basis. The insight into the runtime is much more valuable when you have historic data to compare it to.</comment>


Red Programming Language: Plans for 2019 - <AUTHOR> https://www.red-lang.org/2019/01/full-steam-ahead.html <comment><USER3> I still don't know what to make of this language. If anything, it sounds too easy, making me think "what's the catch?" Is this a small programming cult or is it Czech wizardry obscured by a language barrier? Are there no highly visible Red projects because of shortcomings in the language and its community, or because the language is so potent, its users so empowered, that big libraries aren't necessary?

<comment><USER4> I do not appreciate your remark about our community and Czech-speaking part of it. This is rude and uncalled for.

Regardless of gender and nationality of community members, and despite the fact that Red is an _alpha_ software, the following projects were created, which may qualify as highly visible:

* neural networks [1]

* computer vision framework [2]

* dataflow engine [3]

* ports of (cross-platform) GUI widgets [4]

* projectional editor [5]

* drawing apps [6]

* operating systems (an in-house project as of now, so no link)

If you don't know what to make out of Red, I'd suggest to grab the latest build [7] with a list of learning resources [8] and do a bit of research. Official About page [9] also gives a good list of main features.

Big libraries indeed aren't necessary, because most of batteries are included in a 1MB executable, and common needs are covered by core library. Full- fledged module system is missing, but is planned for 0.8.0 release. We also have a large Rebol ecosystem, from which various scripts and applications may be ported, if necessary.

[1]: [http://redlcv.blogspot.com/2018/11/neural-network-with- red-l...](http://redlcv.blogspot.com/2018/11/neural-network-with-red- language.html)

[2]: [https://github.com/ldci/redCV](https://github.com/ldci/redCV)

[3]: [https://gitter.im/red/red/gui- branch?at=5c018edb8fa4333e391b...](https://gitter.im/red/red/gui- branch?at=5c018edb8fa4333e391b867a)

[4]: [https://gitter.im/red/red/gui- branch?at=5c03fdbabe66d8252666...](https://gitter.im/red/red/gui- branch?at=5c03fdbabe66d825266600ac)

[5]: [https://gitlab.com/rebolek/values](https://gitlab.com/rebolek/values)

[6]: [https://github.com/toomasv/drawing](https://github.com/toomasv/drawing), [https://github.com/honix/Redraw](https://github.com/honix/Redraw)

[7]: [https://www.red-lang.org/p/download.html](https://www.red- lang.org/p/download.html)

[8]: [https://github.com/red/red/wiki/[LINKS]-Learning- resources](https://github.com/red/red/wiki/\[LINKS\]-Learning-resources)

[9]: [https://www.red-lang.org/p/about.html](https://www.red- lang.org/p/about.html)

<comment><USER5> > > If anything, it sounds too easy, making me think "what's the catch?

> This is rude and uncalled for.

I think she/he raise a fair point about how the Red language is advertised, and it's actually a rather friendly to assume that it's due to language barrier.

Many posts about Red/Rebol are unequivocal praise with very few details or any acknowledgements of short-comings or limitations of the languages.

Just to dig up some random ones:

Here's a speed comparison between Rebol and Python[0]: Rebol is faster ( _surprise!_ ), but the post doesn't contain or link to any of the code used for the comparison

Here's some grand self-praise from the _Why Rebol /Red_[1] on why it's _just better than all other languages_ :

> You may be familiar with Clojure, Python, Ruby, Lua, frameworks like Ruby on > Rails, or any of the multitude of Javascript frameworks which are purpose- > built to "ease" particular types of development work. Such > languages/tools/environments are certainly productive compared to > traditional tools like plain old C++, Java, etc., but they are absolute > behemoths when compared to Rebol. Virtually every other well known > development tool in popular use is built upon bloated layers of existing > technology, and encumbered by mainstream language syntax and development > procedures which introduce an extraordinary volume of unnecessary complexity > at many levels. Most developers have just never experienced the sort of self > dependent architecture, lightweight tooling, bare language and data > structure syntax, composability, and reduced code volume, which Rebol > prioritizes as its most important purposes.

(Are Red/Rebol creators seriously claiming that Clojure's syntax is complex?)

Of course there are sometimes programs about which you could make grand claims, like when SQLite claims to be "35% Faster Than The Filesystem"[2], yet they also clearly describe its limitations[3].

Edit: Even in this thread we get this kind of praise:

> Isn't Red a great language to teach children? I just tried Red and it's > amazingly simple to get started.[4]

About a year ago I _did_ try out Red and Rebol, and I couldn't get any of the examples to work, or figure out what the syntax meant, because there's just so many _cool examples of how few lines it takes to do X_ but very little explanation. It made me feel a bit inadequate, because if this language is _soooo easy to use_ , and yet I somehow fail to grok it, then I'm just not smart enough, right?

Here's one of the examples linked to in _Why Rebol and Red_ , with hardcoded IP, no comments and all:

        REBOL [title: "Live Camera Video Stream"]
        for i 2 27 1 [append b:[] rejoin [http://188.8.131.52/cctv i ".jpg"]]
        view w: layout [
          i: image 320x240  text-list 320x200 data b [forever [
            set-face i load value wait 1 if not viewed? w [unview break]
          ]]
        ]

It's great that someone found that so _easy_ to write, but it looks like one- off write-only shell script, and is _certainly_ not useful for "teaching children".

I know it might seem a bit harsh that I'm suggesting that Rebol/Red is being promoted in a somewhat dishonest way, but I'm mentioning this so that you could hopefully improve, not to make you upset.

Edit: More over-the-top praise.[5][6][7][8]

[0]: [http://blog.hostilefork.com/rebol-vs-python- performance/](http://blog.hostilefork.com/rebol-vs-python-performance/)

[1]: [http://redprogramming.com/Why%20Rebol%20and%20Red.html](http://redprogramming.com/Why%20Rebol%20and%20Red.html)

[2]: [https://www.sqlite.org/fasterthanfs.html](https://www.sqlite.org/fasterthanfs.html)

[3]: [https://www.sqlite.org/whentouse.html](https://www.sqlite.org/whentouse.html) (See the section _Situations Where A Client /Server RDBMS May Work Better_)

[4]: [https://news.ycombinator.com/item?id=18844770](https://news.ycombinator.com/item?id=18844770)

[5]: [https://news.ycombinator.com/item?id=18844002](https://news.ycombinator.com/item?id=18844002)

[6]: [https://news.ycombinator.com/item?id=18844185](https://news.ycombinator.com/item?id=18844185)

[7]: [https://news.ycombinator.com/item?id=18844746](https://news.ycombinator.com/item?id=18844746)

[8]: [https://news.ycombinator.com/item?id=18845102](https://news.ycombinator.com/item?id=18845102)

<comment><USER6> One of the reasons is that the Red community is very small and entrenched. They know everything that comes out of the language, and _to them_ everything is easy and understandable.

They will fight you to the death if you even try to say that "english-like syntax with no parantheses" is the opposite of readable or understandable when you don't know the system.

Go into any of Red's source files and you will end up looking at dozens to hundreds of lines of code with no comments and which often look like this:

        return old-gradient-pen DC cmds start tail cmd sym catch?
        OS-draw-brush-pattern DC size crop-1 crop-2 word as red-block! cmd sym = fill-pen
        _read opfd hash alg-digest-size type

etc. These are obviously impossible to look up and find.

The whole development is haphazard as well. Everything hinges on two may be three people who know Red internals wihch frantically move from subsystem to subsystem developing features and patching wholes.

Patching wholes are usually like this:

\- issue is raised on GitHub

\- it's acknowledge

\- a fix is written (with zero comments even for the complex issues) and merged

\- the issue is closed with a "tested" label [1]

About 0.001% of "tested" issues contain any tests. The majority of fixes are apparently only fixed and manually tested against the reported issue.

etc. etc.

[https://github.com/red/red/issues?q=is%3Aissue+is%3Aclosed+l...](https://github.com/red/red/issues?q=is%3Aissue+is%3Aclosed+label%3Astatus.tested)

<comment><USER4> I don't recall anyone fighting to the death over someones syntactic preferences. Code written by experienced users (and Red codebase in particular) is a hard nut to crack, that's true.

Regarding development: I'd appreciate if you elaborate over your critique. Concrete suggestions on how development and testing processes can be improved are always welcomed.

<comment><USER6> > Regarding development: I'd appreciate if you elaborate over your critique.

There's nothing to elaborate, really. If you list all "status.tested" issues, how many are tested?

Let's take the top few as of today.

1\. Malignant output from react/link, [https://github.com/red/red/issues/3713](https://github.com/red/red/issues/3713)

fix: [https://github.com/red/red/commit/644be4b1e3bfcf70a5f9f5e006...](https://github.com/red/red/commit/644be4b1e3bfcf70a5f9f5e0066fdd2cc964cd73)

One-line fix, sure. Where's the test?

2\. new-line flags are not cleared on subsequent calls, [https://github.com/red/red/issues/3707](https://github.com/red/red/issues/3707)

Fix: [https://github.com/red/red/commit/b7ee2846b58a1328d57002b3ed...](https://github.com/red/red/commit/b7ee2846b58a1328d57002b3ed2d076d65ca4b7e)

Severl line-fix. Where's the test?

3\. stack overflow on limited append/insert, [https://github.com/red/red/issues/3705](https://github.com/red/red/issues/3705)

The fix contains a single test even though the issue provided three different failure modes: [https://github.com/red/red/commit/bd41d35ee5a73cd5779647b503...](https://github.com/red/red/commit/bd41d35ee5a73cd5779647b50376b0d757c9e8a0)

And so on and so forth. I remember seeing a "status.tested" which added easily a hundred lines of new code with zero tests.

Funnily enough I see you've added a "test.written" label, which really shouldn't be there because that's what "status.tested" is for.

\----

But forget issues and tests for the moment.

Out of 44 contributors to Red, only two have anything significant to contribute: the people who actually develop Red.

Of all the issues reported almost none contain code to fix the issue. Almost all issues are fixed by the same two people who develop Red.

Perhaps it's due to the fact that about zero percent of Red code is documented? Or that "Code written by experienced users (and Red codebase in particular) is a hard nut to crack"? Which is kinda ironic, considering how the authors and proponents gush about Red's simplicity.

Go back to the first issue in the list above. It's a one-line fix. So, surely, it could be fixed by someone else but the author of the language?

Too bad the file where the issue is fixed is this: [https://github.com/red/red/blob/644be4b1e3bfcf70a5f9f5e0066f...](https://github.com/red/red/blob/644be4b1e3bfcf70a5f9f5e0066fdd2cc964cd73/environment/reactivity.red)

336 lines of no significant comments other than trivia for the author himself.

"New line flags not cleared" whose fix is just a few lines? Oh, it's in a 3000-line file with no comments, [https://github.com/red/red/blob/b7ee2846b58a1328d57002b3ed2d...](https://github.com/red/red/blob/b7ee2846b58a1328d57002b3ed2d076d65ca4b7e/runtime/natives.reds)

And so on and so forth.

And since very very few of those lines are covered by any tests (even for issues reported and fixed), how is anyone except the two authors can ever fix those issues or contribute?

If "Code written by experienced users (and Red codebase in particular) is a hard nut to crack", how can you expect people to believe in it's "simplicity and fun"? \----

<comment><USER4> Bus factor - fair enough. Lack of tests - have you counted them? [1]

2/3 of issues you showed are purely formatting concerns, so I'm not sure what needs to be tested there. "test.written" refers to test being written in a testing framework, "status.tested" means that the described bug was tested in multiple development environments and confirmed. So your remark is slightly off the base.

Small number of dedicated contributors: historically, Rebol (the ancestor of Red) was developed by Rebol Tech company in a closed manner. So, IMO there developed a particular community mindset, where everyone just lets the Boss do the job and watches the action from the tribunes.

Another reason, like I said elsewhere, is the fact that Rebol never became mainstream, hence there isn't much contributors ready to provide the code of acceptable quality.

Lack of comments and such: in the early days, Red planned to be minimal and bootstrapped early, so the whole codebase was written in a throw-away fashion, with no comments or afterthoughts. As the project growed and roadmap changed its curves, community started raising demands (macOS View backend, new datatypes, supporting other platforms, the list goes on), so the "quick bootsrap" plan was ditched, but the code remained. This is a stumble block for other contributors, which, alas, will be moved away only after 1.0 is reached.

"Simplicity and fun" is completely off the point though, but I get what you say, even with a snarky tone. "Simplicity" here refers to the use of embedded DSLs, in which it is generally easy to express ideas suitable for a particular domain, and to "self-contained small toolchain" goal of the project. So, _expressing_ ideas and _developing_ them is rather simple, once you got the hang of the language.

 _Reading_ Red code requires a prior knowledge of function's arity and evaluation rules; ambitious projects require knowledge of multiple dialects and thorough understanding of core concepts; dynamic pieces (i.e. metaprogramming) can be challenging, unless you're coming from Lisp or Forth camp.

Runtime is written in Red/System dialect, which requires C-level skills to write. Red and Red/System share the same syntax, but require a huge mental leap to switch the context (Lisp vs. C dichotomy) - another 2 cents to your "lack of contributors".

I'm not a fan of "Red is simple and for everyone" sales pitch either - it's misleading at best, sets the wrong expectations and usually comes from people who barely clocked 1 hour in REPL tinkering with available View examples.

Hope that answers your concerns, more or less. If you want to alleviate them more quickly - drop by our community chat and start contributing piece by piece ;) Cheers.

[1]: [https://github.com/red/red/tree/master/tests](https://github.com/red/red/tree/master/tests)

<comment><USER6> > 2/3 of issues you showed are purely formatting concerns

This is a bald-faced lie, and one can see that by following the links I provided.

A "formatting concern" is changing indentation or splitting a long declaration over several lines.

The issues I've shown, and the majority of others, are actual bugs that are fixed by altering code.

> "test.written" refers to test being written in a testing framework, > "status.tested" means that the described bug was tested in multiple > development environments and confirmed. So your remark is slightly off the > base.

It's entirely on point. Code for the fix is written, the issue is closed. The commit is merged into master branch. No tests are added in the commit that fixes the issue.

When are exactly tests for these changes "written in a testing framework", if ever?

I could count the tests until I'm blue in the face, but the fact remains: next to no tests are written for issues that are marked as fixed, and closed. And if you view the commit history, well, it's mostly fixes, and some superfluous tests remove. No commits show any tests added (I know such commits appear sometimes, for larger features).

> hence there isn't much contributors ready to provide the code of acceptable > quality.

I don't even know how to comment on this

> This is a stumble block for other contributors, which, alas, will be moved > away only after 1.0 is reached.

So, not in any foreseeable future. Original plan to release 1.0 was last year AFAIR. Then that shifted to release 0.6.5 AFAIR which is still not released.

So:

\- contributors aren't willing to provide code of acceptable quality for any foreseeable future

\- there won't be any acceptable quality, or even such an important thing as comments, for any foreseeable future

\- there will rarely be any tests for any of the issues found and fixed for any foreseeable future

See why my skepticism about Red is not unfounded?

> Reading Red code requires a prior knowledge of function's arity and > evaluation rules; ambitious projects require knowledge of multiple dialects > and thorough understanding of core concepts; dynamic pieces (i.e. > metaprogramming) can be challenging, unless you're coming from Lisp or Forth > camp.

Do not confuse Red with Lisp. Lisp (and even its expanded dialects such as Clojure) have clearly pretty much defined rules on how to read code.

No "previous experience" with Red will let you parse the "simplicity" of

       OS-draw-brush-pattern DC size crop-1 crop-2 word as red-block! cmd sym = fill-pen

> another 2 cents to your "lack of contributors".

It's not "2 cents". It's yet another weak attempt at finding excuses instead of facing criticism face on.

There's a reason I gave Elixir as an example. You could view it as a one-man show, as one contributor, the author, has an overwhelming input into the project compared to all other contributors.

However, it doesn't prevent him from:

\- writing acceptable code

\- writing tests for the fixes he provides to issues

\- writing comments in code

What this result in? Well, even the issue I referenced: it was reported _and fixed_ , _and documented_ not by the author, but by a different contributor. A miracle, by Red standards.

> Hope that answers your concerns, more or less.

Nope, it doesn't. It's a string of excuses, and see the concerns about the foreseeable future above.

> [1]: > [https://github.com/red/red/tree/master/tests](https://github.com/red/red/tree/master/tests)

Which of the tests contain the test for the "Malignant output from react/link"?

Or, and I swear to God, I found this by pure accident trying to be snarky and digging up some old issue: your own reported issue, [https://github.com/red/red/issues/3211](https://github.com/red/red/issues/3211)

It was fixed, with no tests, and don't tell me it was "formatting concerns". So, which of the red/tests contain the test "being written in a testing framework"?

<comment><USER4> > This is a bald-faced lie, and one can see that by following the links I > provided.

You call me a liar now? Tone down a bit, would you? By "formatting" I meant formatting output of error messages (changing size of the buffer down to 80) and data (ensuring that newline markers are preserved), not the source code cleansing.

> I don't even know how to comment on this

Then don't.

> Original plan to release 1.0 was last year AFAIR. Then that shifted to > release 0.6.5 AFAIR which is still not released.

Not entirely correct. This [1] article gives a context to what 1.0 was "then" and "now", and also explain why roadmap was adjusted.

> See why my skepticism about Red is not unfounded?

By all means, be skeptical, I'm not trying to convert you or whatnot. You've raised important points, so I tried to elaborate and explain why things are the way they are, so you can judge by yourself.

> Do not confuse Red with Lisp.

Well, I don't. As I said, reading code requires knowledge of funciton's arity, and your example only proves that. And you seemingly ignored what I said about "simplicity". Moreso, your example is Red/System, not Red, pulled out of Draw backend. I can similarly crop a random snippet out of the guts of Elixir and make googly eyes.

> It's yet another weak attempt at finding excuses instead of facing criticism > face on.

Again, tone down. I asked you to elaborate exactly to face the criticism, and provided some context, so you can make a fair judgement. Things turned out that way for reasons - I gave you my IMHO on them - you see these reasons as "excuses". Fine, point taken.

> see the concerns about the foreseeable future above

Time will tell.

[1]: [https://www.red-lang.org/2018/01/overview-of-red- development...](https://www.red-lang.org/2018/01/overview-of-red-development- history.html)

<comment><USER6> > You call me a liar now? Tone down a bit, would you? By "formatting" I meant > formatting output of error messages (changing size of the buffer down to 80) > and data (ensuring that newline markers are preserved), not the source code > cleansing.

1\. Once again, this is provably false.

2\. Once again, this is no jsutification for the fact that nearly all bugfixes contain no tests.

> You've raised important points, so I tried to elaborate and explain why > things are the way they are, so you can judge by yourself.

I have, and my initial an subsequent posts remains just as valid.

> Time will tell.

It has already told. At best, Red sees one minor version increment per year. At best. It's more of a one patch version increment per year.

So, going back to this statement: "hence there isn't much contributors ready to provide the code of acceptable quality.... [lack of comments as] a stumble block for other contributors, which, alas, will be moved away only after 1.0 is reached." This means that we will not see this for any foreseeable future.

Somehow this is viewed as a normal course of events even though it isn't.

Well, to each his/her own, I guess ¯\\_(ツ)_/¯

BTW, have you ever seen any tests to your own bug reports, or have you written any tests for the bug reports where you provided a fix?

<comment><USER4> > this is provably false

If it's provably false, then take your time to actually prove it before calling someone a liar.

> my initial an subsequent posts remains just as valid.

They remained as biased as the were. You waved away project's history and keep imposing "high" standards pulled from other projects, without respecting their retrospective history and goals.

> At best, Red sees one minor version increment per year. At best. It's more > of a one patch version increment per year.

Absolute nonsense. Read the changelogs, roadmap and Github releases before making such claims.

> Somehow this is viewed as a normal course of events even though it isn't.

Again, in retrospective, this is an expected course, and no one will adhere to your idealistic, unencumbered by reality version of how things should be done. Want an overnight improvement - start contributing.

> Well, to each his/her own, I guess

I guess. Feedback filtered out of your messages is appreciated, and taken into account. Thanks for taking your time to respond. In the meantime, I'm marking this as the end of discussion.

<comment><USER6> > If it's provably false, then take your time to actually prove it before > calling someone a liar.

1\. It was _your_ claim that it was "just formatting changes". Which they are not

2\. This doesn't explain why 99% of bug fixes contain no tests

> If it's provably false, then take your time to actually prove it before > calling someone a liar.

Testing and comments in code are not high standards. They are basic development hygiene.

> Absolute nonsense. Read the changelogs, roadmap and Github releases before > making such claims.

I've read them, that's why I'm making such claims.

Releases: [https://github.com/red/red/releases](https://github.com/red/red/releases)

Barely above one patch increment a year for the past three years:

\- Nov 2018, 0.6.4

\- Jul 2018, 0.6.3

\- Mar 2017, 0.6.2

\- Jun 2016, 0.6.1

\- Mar 2016, 0.6.0

Minor versions incremented from 0.1. to 0.6 in 7 years, and increments have slowed down.

So, we are expected to believe that 7 years from now when it maybe reaches 1.0.0 the devs will suddenly go through all the code, add comments and tests, and start caring?

> no one will adhere to your idealistic, unencumbered by reality version of > how things should be done.

Me: when you fix issues, you should really add tests to those fixes. At least strive to have more than ~0 tests in your fixes. Add documentation to critical parts of your system.

You: "your idealistic, unencumbered by reality version"

:-\

That's why I'm extremely sceptical. What is considered the norm pretty much everywhere is viewed as "unencumbered by reality" in Red world.

> Feedback filtered out of your messages is appreciated, and taken into > account.

I very much doubt it was taken into account.

<comment><USER7> Dimitri, you've obviously looked into Red in some depth, which is appreciated. And your comments and criticisms have been heard. It's easy for miscommunication to occur in chat like this, so we can probably close this particular thread of conversation, as I don't think it's productive anymore. As much as I now want to chime in to defend our position, it wouldn't help. You make valid points, but comparisons with other projects are hard.

If you don't like Red, or how the project is being managed or progressing, that's fine. Sharing what you've learned is also great, as long as others can form their own opinions from facts presented (again, hard to present deep info in chat). All we ask is that you try to be fair, and think about how harmful negative press can be to a project. When you've put a huge amount of time and effort into something you believe in deeply, it's easy to get defensive when someone criticizes it (in ways that may seem unfair).

How things are said is important, as well as balancing pros and cons. In re- reading the chat, I admit that I got defensive, which is why I didn't respond initially.

In conclusion, can we do better? Yes, of course. Is much of the code written by a very small core, who knows the system well, and isn't writing it with the expectation that others will read and learn from it? Yes. Can we do better on testing? Yes. Do we already have more than 30'000 tests? Yes. Are those core devs pretty darned amazing, considering what they've built (insert feature list here :^)? You bet they are.

Red isn't for everyone. Our approach won't be to everyone's liking. But we hope people will be fair, wish us luck, and maybe even applaud us for trying to build something that will make their lives better. At the very least, we hope they won't talk us down unfairly.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I'm I shallow if I stopped caring about this project after they started with all this crypto currency stuff?

<comment><USER7> If you read the old blog entries about why it was done, do you still feel that way?

<comment><USER8> I followed the project up until then.

<comment><USER7> Understood, so you know there was a reason for branching out into the blockchain space, as there's a real need for better langs there, and less competition, which leads to more visibility in an area that his hot technology. For the project to survive, we'll have to try a lot of things.

</comment></comment></comment></comment><comment><USER9> Things I find exciting about Red:

* Small

* Lisp like

* Cross compiler "done right" [1]

* Red/System is a cool concept (a language dialect for low-level/systems programming).

Things I find discouraging:

* Bus factor = 2 (IMHO) [2]

* Apparently, it took it 8 years to get simple (in words of author) G.C. [3]

* Docs and example code are not great, lack of existing apps (chicken & egg problem).

1: [https://github.com/red/red/blob/master/usage.txt#L68-L81](https://github.com/red/red/blob/master/usage.txt#L68-L81)

2: [https://github.com/red/red/graphs/contributors](https://github.com/red/red/graphs/contributors)

3: [https://github.com/red/red/tree/v0.6.4](https://github.com/red/red/tree/v0.6.4)

<comment><USER10> > * Apparently, it took it 8 years to get simple (in words of author) G.C. [3]

Apparently you didn't look close enough at the history and are making up fake information.

Preliminary work on GC started in 2017 for a month, then resumed in 2018 for about 3-4 months. So in total, about 4-5 months, mostly spent on adjusting the runtime library and tracking notoriously hard to catch GC-related issues.

<comment><USER9> Hey there, I did not intend to imply it took that long in actual development time, more in the sense that the g.c. feature did not exist in He language for that long, for different reasons (evidently it wasn't a priority).

A dynamic language without g.c. sounds dangerous to use. I'm just surprised it wasn't a priority for so long.

</comment></comment></comment><comment><USER7> There are a lot of topics here now, which is great, and the opening question about what to make of Red is a good one. The problem in answering it is the same problem we have when pitching it to people: it's hard to sum up.

Is there a catch? Yes. More than one actually. One is that, because we are building things from the ground up, we don't get things for free that other languages do. For example, JVM-based langs get a lot for free, but at a cost. Another catch, and a big one, is that Red is fundamentally different in some design aspects, both superficial (syntax) and deep (all is data, words and bindings, etc.). Those two things deter a lot of people. We get that. If you want to keep doing things mostly the way you always have, Red is not for you. If you just want lots of familiar libs and features, you may have to wait for them, or help build them. This makes us a self-selecting community. We don't want to be a cult, but we also won't compromise certain things with the hope of it making us more popular. There are few easy choices here.

For those who find Red, and give it a shot, not all will like it, and not all who like it will understand it or use it effectively. We also accept that. For those who have the courage to try something new (I mean, really try it), and who take the time to understand it (the process of which brings its own benefits, no matter what language you use), and who reach the moment where it clicks in their head, there is no going back.

Whether you support and commend features, or criticize them fairly, they are features. To have meaningful discourse about Red, we need to go deeper. Much deeper. If you only want to compare Red to other tools, on their terms, we'll often lose. But if you look at what Red can do, that they can't, and Red's fundamental goals, it becomes clear that comparisons don't mean much. That's true for any 2 languages. It can help, provide context, etc., but ultimately you have to evaluate a language or tool on its own merits, just as you have to evaluate yourself and see your own worth and value without comparison to others.

If you think the state of software development is just fine, and a few tweaks are all we need, Red probably isn't for you. But if you have nagging doubts about why things are so hard, so big, so complex, when it seems like they should be easy, small, and simple...maybe you'll be curious and brave enough to take the Red pill. Most, we know, just want the big juicy steak.

We can talk more, explain more, if people want. Gitter is our most active channel, but we can try to respond here as well. We're glad to hear what people like, and accept fair criticism.

<comment><USER5> > One is that, because we are building things from the ground up, we don't get > things for free that other languages do. For example, JVM-based langs get a > lot for free, but at a cost.

Red is implemented in Rebol2. That also comes at a cost due to Rebol2 not being free/libre and being abandoned.

<comment><USER7> But that was a very important choice. Do you understand why?

<comment><USER5> > But that was a very important choice. Do you understand why?

I'm sure you have your reasons for doing so, and I'm glad that it's working well for you.

I'm not having a go at you for making Red run on Rebol. But _I am_ having a go at you for having a go at Clojure for running on the JVM, while claiming that Red is built "from the ground up".

All this posting about how Red is better than all other languages, and that people, who use those other ones, are stuck in their ways or not smart enough, and defensively lashing out at people who point out limitations of Red, it just comes across as megalomaniacal. Being implemented in Rebol2 apparently also "has a cost" for Red, namely that Rebol2 is abandoned, and that there's no 64-bit support, and that a otherwise free/libre programming language has non-free dependencies, and you might be in a pickle if you want to include newer versions of libraries that are presumably statically compiled into the Rebol2 binary blob, especially your SSL library... but apparently, from what I read about Rebol[0], it's only the "pro" version of Rebol that has SSL- support, so what about Red?

Do _you_ understand those issues? It's too hand-wavy to say that I'm not looking at Red "on its own terms", especially because those terms include being a "good fit for any task!"[1]

[0]: [https://www.freax.be/2017/03/19/rebol/](https://www.freax.be/2017/03/19/rebol/)

[1]: [https://en.wikipedia.org/wiki/Red_(programming_language)](https://en.wikipedia.org/wiki/Red_\(programming_language\))

<comment><USER4> Can you back up your acqusations with palpable evidence? Neither Red author, nor any of official project representatives "made a go" on Clojure or any other language and its community, as far as I'm concerned.

As for "defensive lashing" \- you should make a distinction between informed, well-posed critique and arrogant, unbacked ranting. Everyone accepts the former and does not tolerate the latter - the team is no exception. And, again - either provide an evidence for what you say or back off your claims. Calling project megalomaniacal for fighting FUD is completely off base, and every criticism raised in this thread was handled politely. Heck, I can pull out any blog post from one of Clojure community members and start claiming that it represents opinions of Hickey. Would that be OK? I guess not.

Even if there is a cost in using Rebol2 as bootsrapping language, it will be gone with 1.0 release. And right now Rebol source code takes roughly a quarter of whole codebase (compilers and linkers for Red and Red/System) - the rest is pure Red and its dialects. So your whole paragraph is completely irrelevant and misleading: lack of 64-bit support has nothing to do with Rebol2, bold "non-free dependency" claim does not have any weight to it (since when bootstrapping language is a dependency?) and "SSL library" passage tells me that you don't have an idea of what you're talking about.

And use _official_ resources (Red and Rebol websites) as references, would you? Wiki page is an extremely weak testimony to whatever you have to say.

No project is ideal, but Red's terms are completely different from what you try to impose here. I do not say that we don't have holes in the housing - <USER2> do, and we have all what is necessary to close them.

<comment><USER5> > And use official resources (Red and Rebol websites) as references, would > you? Wiki page is an extremely weak testimony to whatever you have to say.

That's my mistake. The quote about Clojure I provided were from `redprogramming.com` which is linked to from the official website and from your Github, so it looked official to me.

The comparison with Python is from a blog of one of the Rebol developers. Not sure whether that qualifies as _official_.

If the Wikipedia article about Red is wrong, it might be a good idea to correct it..?

> Even if there is a cost in using Rebol2 as bootsrapping language, it will be > gone with 1.0 release. [...] (since when bootstrapping language is a > dependency?)

That's cool, and I wasn't aware of that. I just assumed Red was to Rebol what Hy is to Python and Clojure to Java, but that's great that that is a non- issue!

<comment><USER4> > `redprogramming.com` which is linked to from the official website

Official page links to learning resources provided by community, to compensate for TBD state of official documentation. We can't, however, control other people's opinions, or dictate them how to express themselves.

People can unintentionally say provocative things in a burst of excitement, I hope you understand that. And there are reasons to be excited about Red and Rebol.

> The comparison with Python is from a blog of one of the Rebol developers. > Not sure whether that qualifies as official.

As I said, we can't control other people, and are not responsible for other's bold claims. I too do not think that this benchmark was fair and objective. As for the wiki page - we'll note that. I'm just saying that any other person can go there and apply his/her edits, without project's consent.

> I just assumed Red was to Rebol what Hy is to Python and Clojure to Java, > but that's great that that is a non-issue!

It's good that this confusion is resolved. Hy and Clojure are hosted languages by nature, but Red is entirely self-contained (although you might think that it depends on Red/System dialect).

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> The Red Language has always described itself as _functional imperative_. I used to point out to people that functional programming can be imperative and nobody (I do mean nobody I spoke to about this) would believe me on this. Then I would point out to people Red Language as an example and they would scratch their heads in confusion.

Even the Wikipedia article gets this wrong: [https://en.wikipedia.org/wiki/Functional_programming](https://en.wikipedia.org/wiki/Functional_programming)

Functional imperative is the idea of using functions to define the shape of an application, which is to say the nesting of functions defines both the stacked structure and the resulting control flow opposed to describing units of logic or any sort of reflection.

[https://en.wikipedia.org/wiki/Function_model#Functional_deco...](https://en.wikipedia.org/wiki/Function_model#Functional_decomposition)

<comment><USER12> > I used to point out to people that functional programming can be imperative > and nobody (I do mean nobody I spoke to about this) would believe me on > this.

Interesting. Monadic Haskell can be quite imperative if you want it to be, as can SML or OCaml. Scheme and Lisp have imperative parts too.

<comment><USER13> Haskell's IO is literally the idea of sequencing commands reified, though, so the comparison is a bit apples-to-oranges.

</comment></comment></comment><comment><USER14> I was so worried when they announced their cryptocurrency plans that Red wouldn't survive when the cryptocurrency hype bubble would inevitably pop. Glad to see that they managed.

<comment><USER15> I was worried about it too. I hope they simply forget about the whole ICO thing and just move forward.

<comment><USER4> Unlike the majority of startups in crypto space, the team is actually dedicated to bring the value to this ecosystem.

Ethereum roller-coaster forced a constant change of plans, but, as far as I know, no one ditched gived promises and just moved forward.

</comment></comment></comment><comment><USER16> Isn't Red a great language to teach children? I just tried Red and it's _amazingly_ simple to get started.

<comment><USER4> Although Logo is said to be an ancestor to Rebol (which in turn is an ancestor to Red), there's more it than an apparent "childish" simplicity on the surface.

[http://www.rebol.com/article/0103.html](http://www.rebol.com/article/0103.html)

Language that hits the sweet spot between Forth and Lisp might be a good fit for some kids, but its scope is way outside of mere scripting and toying, and demands a respective approach - something that only grown-up engineers can fully appreciate. YMMW.

<comment><USER14> > _its scope is way outside of mere scripting and toying, and demands a > respective approach_

Maybe I misunderstand where you are coming from, but to me this appears similar to saying that using acrylic paint demands a respective approach because the great paintings of the last century were made with it.

To which I would say: no, not really. Acrylic paint only demands a respective approach in the sense that it may be toxic and you don't want kids to finger paint or risk swallowing it. But people can paint whatever they want with it.

Similarly, Red demands a respective approach because it's powerful enough to shoot yourself in the foot (oops, some kid deleted half of the files on the SSD by accident). Maybe that is what you meant with "scope", but it's not what I made out of it upon first reading.

Besides, the solution for that is simple enough: make a child-safe dialect.

<comment><USER4> My point is that Rebol and Red are extremely good chameleons - they hide all their power behind the approachable facade, and make a false impression of "oh it's just X, nothing serious". I saw a fair share of people who, based on that first impression, dismiss Red as a quirky alternative to Python, or a GUI- building kit, or a pretentious academical toy, you name it.

But that doesn't mean that these languages child-safe _by default_ , and indeed, foot-shooting starts as soon as you begin to harness that power - that's where the real fun is, which IMO kids can't appreciate fully. As you said, it's anything but a finger paint.

But if it clicks in kid's brain from the get-go and grows over him, then the world is ought to see some great paintings ;)

<comment><USER14> Ah, so we were more or less on the same page from the beginning.

BTW, is there a child-safe dialect for Red? How easy or hard would it be to create an environment like Processing or p5.js, without the foot-shooting risks?

[https://processing.org/](https://processing.org/)

[http://p5js.org/](http://p5js.org/)

<comment><USER4> That kinda a broad question.

Easy - you can create a live-coding IDE in 20 lines or so, Draw and View a pretty capable for interactive Processing-like demos, bottlenecks can be rewritten in R/S.

Hard - hit the academical papers and define what can be considered a "child- safe programming environment". Then implement a separate toolchain for that.

<comment><USER14> I was thinking more along the lines of

[Somewhere between Easy and Hard?] - _make the dialect operate in a safe sandbox that can 't destroy your computer_

... plus optionally convenience functions fitting for the creative problem domain like how Processing removes a lot of Java boilerplate, and p5 does similar things for using the various JS APIs. One can just look at the APIs of Processing, p5 and OpenFrameworks to get an idea of what works there, though.

<comment><USER4> Safe sandbox: Rebol had Protect and Secure dialects [1, 2], which are planned to be implemented in Red. Language is very dynamic though, so there's a certain limit on what kind of safety can be enforced at runtime.

Creative problem domain: that's what Red is all about in my point of view - slapping domain-specific languages one on top of another to pin down the exact problem space. Draw for 2d vector drawing, View for GUIs, Parse for, well, parsing and metaprogramming, et cetera. The crux is usage of same data format and common notation at every abstraction layer, be it low-level programming or high-level scripting.

I don't think that Red can handle large-scale projects the way language workbenches do (yet), but it can be used for moderately small embedded DSLs.

Does that answer your question?

[1]: [http://www.rebol.com/docs/words/wsecure.html](http://www.rebol.com/docs/words/wsecure.html)

[2]: [http://www.rebol.com/docs/words/wprotect- system.html](http://www.rebol.com/docs/words/wprotect-system.html)

<comment><USER14> Yes, thank you!

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> A great feature of Red is their cross platform GUI support. I see Android is also supported. Does anyone know what the status of iphone (iOS) support is ?

<comment><USER15> I wouldn't call its GUI really cross-platform yet. Linux GUI definitely isn't production ready. Android is somewhat usable. iOS is not working.

Nevertheless, I keep my fingers crossed. My estimate is in 2-3 years you will be able to start writing small cross-platform GUI apps in RED and not worry about trifle problems.

<comment><USER4> One major stumble block in GTK backend development is a monstrocious string- oriented API for setting widget properties. There's a more low-level one, but it's depricated.

FYI, development of backend happens as we speak [1].

[1]: [https://gitter.im/red/GTK](https://gitter.im/red/GTK)

</comment></comment></comment><comment><USER18> After seeing the first demos from Rebol View many years ago, nothing comes close yet.

<comment><USER19> At least once a year I'm tempted to play with Rebol. Its concepts scratches many itches of mine.

Do you have any suggestion on what I could write to showcase idiomatic Rebol? Networking? GUI? Command-line?

<comment><USER18> Take a look at these, source code is easy to follow

[http://www.rebol.com/pre-view.html](http://www.rebol.com/pre-view.html)

</comment></comment></comment><comment><USER20> A language with a GC does not seem appropriate for a "full-stack" language with which one would write operating systems, drivers, or game engines. I don't know why any language without full manual memory management would ever posit itself as being appropriate for these domains. It's naive at best.

<comment><USER21> I write kernel drivers and firmware code mainly in C and a little bit of assembler.

I agree with you pretty much.

That said, it's healthy to have some people exploring alternative paths. Maybe some of that exploration will be fruitful, way or another.

Especially firmware development is somewhat ossified to C. C is universally supported and a lot of people in this trade don't even see need for a change, despite vastly increased system complexity and exposure over open networks. It's not enough for the things to just to work — they need to work securely, otherwise ultimately our infrastructure is at risk.

C can work with 16 bytes to 16 TB+ (or a lot more) of RAM. It can span from a 4-bit single core microcontrollers to massive RDMA supercomputing clusters. C contender does not need to cover all of that, but should keep that enormous range in mind.

The contender should also be able to interface with C library and linking interfaces. Otherwise it's hard to compose working systems. No matter how amazing the new language is, you can't build everything from scratch.

So far I've placed my biggest hopes in Rust. But we'll see how the things evolve. One should keep an open mind. I wish good luck for the Red folks.

By the way, you often can't allocate or free memory in firmware or kernel drivers either. Like in a kernel IRQ handler or on an embedded device with hard realtime and stability requirements. In that kind of case GC or manual allocation would not make much difference at all — you'd only allocate at initialization or at teardown.

<comment><USER22> >That said, it's healthy to have some people exploring alternative paths. Maybe some of that exploration will be fruitful, way or another.

Exactly. Perhaps it is not appropriate to write production ready drivers and operating systems that people will use today in a GC language; but in the future that could change and change will only happen if people take the time to experiment.</comment></comment></comment>


All the Buildings in Manhattan - <AUTHOR> https://tbaldw.in/nyc-buildings <comment><AUTHOR> Data sources:

[https://www1.nyc.gov/site/doitt/initiatives/3d-building.page](https://www1.nyc.gov/site/doitt/initiatives/3d-building.page)

[https://www1.nyc.gov/site/planning/data-maps/open- data/dwn-p...](https://www1.nyc.gov/site/planning/data-maps/open-data/dwn- pluto-mappluto.page)

And code is open: [https://github.com/rolyatmax/nyc- buildings](https://github.com/rolyatmax/nyc-buildings)</comment>


How Uber's Hard-Charging Corporate Culture Left Employees Drained - <AUTHOR> https://www.buzzfeed.com/carolineodonovan/how-ubers-hard-charging-corporate-culture-left-employees?utm_term=.vqV45Y6J6#.lcXVl9xpx <comment><USER3> _Uber uses an algorithm to estimate the lowest possible compensation employees will take in order to keep labor costs down_

Of course they do.

I'd like to blame Uber. I'd like to blame Kalanick. But I keep coming back to blaming us, the engineers, for being the willing hands that let Silicon Valley dismantle every good thing we'd built up. We built algorithms to find out how little we could pay ourselves. We built apps to turn employees into contractors earning MacDonald's level wages. We routed around the government's limitations on surveillance and record-keeping by selling ourselves open microphones to Amazon's data centers.

It seems almost quaint, looking back on the 90s, how what we feared were bureaucrats in government offices.

<comment><USER4> Why does it make a difference if it's an algorithm estimating what you're willing to work for rather than some person in the corporation structure?

Yes, corporations will always try to figure out what's the least they could pay you. But it's still up to you to set that number.

<comment><USER3> You don't negotiate in a vacuum. If you participate in writing that algorithm that exerts downward pressure on salaries generally (because it's more efficient/effective, and it's applied at the level of a tech behemoth with a lot of influence), you're incrementally lowering the baseline from which you and everyone else negotiate. You're basically arming the other side of the negotiating table--and that other side is already a multi-billion dollar unicorn.

At some point, you'd think a basic sense of self-interest would remain. I swear, if someone held a contest to design a better rope for hanging engineers, we'd fall all over ourselves trying to win. If someone kickstarted that idea, they'd need new stretch goals in an hour.

<comment><USER4> It might be more efficient/effective, or it might just be more predictable and cheaper to run than person-to-person negotiations. I think I'd prefer a clear algorithm for salaries to "what you get depends on who your lead is and how much of an asshole you're willing to be".

</comment></comment></comment></comment><comment><USER5> While Uber seems to be the current whipping boy of Silicon Valley, I wish I could say that this article would sound different if I replaced Uber with any other big tech company.

Getting yelled at constantly, usually with profane language? On call for weeks at a time with no help? Put in a double bind by management? Put on an impossible task, or a task made impossible? Stack ranked that you don't drink enough? Staying around late trying to look productive?

I wish I could say any of those weren't ubiquitous in SV.

<comment><USER6> AirBnB is probably the anti-Uber in that regard.

<comment><USER7> Really? I found their interview process to be downright creepy...

<comment><USER5> Both of these comments sound interesting, and make me want to go interview there and report back! :)

<comment><USER6> They go out of their way to be the opposite of Uber, not completely intentionally. I'm not saying it's necessarily the best thing to be.

<comment><USER8> Do you have any examples? I'd never heard this before.

<comment><USER6> They go out of their way to interview for good culture fit, trying to preserve a very cooperative, nice, opposite of Uber type of environment. So much so that as others have pointed out, it seems cult-like, but in a way that is favorable to employees, or at least engineer employees. Many other unicorns just have the typical SV elitist cutthroat competitive environment that existed even before Uber.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> _As one former employee said, explaining why he joined the company, it seemed like a "libertarian playground where the best would rise to the top." But, he said, "I quickly realized that environment also means work becomes a blood sport."_

A libertarian is someone who is hell bent on discovering exactly why and how societies choose to govern themselves, the hard way.

<comment><USER10> If you believe people are essentially predatory, government can't save you from them, it just makes it easier to do predation on a mass scale.

<comment><USER11> The devil you know vs. the devil you don't.

</comment></comment></comment><comment><USER12> I've heard that the hard-charging culture at many investment banks and law firms is similar. People work ultra long hours, because if you don't, there's always someone who is willing to and ready to replace you. Associates at law firms routinely have billables of 2000+ hours a year. Bankers are often in at 7am and leave at midnight. Long hours seem to be par for the course. So then, why are we any different from law firms and banks like GS?

I strongly believe that this kind of toxic culture has no place in any organization. So I'm in no way condoning the culture at Uber or similar SV companies. I for one, never want to work at a place like that. I am curious though, what makes us different?

</comment><comment><USER13> > In May 2015, an on-call engineer failed ... At the time, Uber had recently > reached a valuation of $50 billion.

I find that astonishing. Outside Silicon Valley, I think that it would be quite unusual to leave $50 billion of plant running overnight, but pinch pennies by not paying anyone to stay up and check the oil levels during the dog watches.

<comment><USER14> I can understand not doing butts in chairs 24/7, but I'm really surprised they managed to make it to that scale without adding paging escalation. If someone doesn't respond after X minutes then page their manager. Repeat until you get to the CEO.

<comment><USER15> That was my initial thought as well. But, low disk space on the master DB? And you need a human to go futz around with it? There is either a whole lot of missing monitoring and automation, or those are completely worthless pages.

I understand the freakout, i assume it could take down the site. But, like, not responding to a page is like the very last on the list of things to fix. Calling in _random engineer_ is pretty much last ditch, hail mary, the world is on fire, oh fuck we're going to go out of business disaster. At a certain point, you kind of have to assume one possibility is your oncall person is dead. Whatcha gonna do then?

I seriously doubt all of their careful high availability planning failed. I would bet their paging is (hopefully was) just stupid.

<comment><USER16> From the article, it's not that the engineer never responded. The engineer acknowledged the pages but never did anything to correct the problem beyond that. I agree with you though that a random engineer might not have the tools and knowledge ready to fix something like that, but that is why you can let the pages escalate until you wake someone up who does.

</comment></comment></comment></comment><comment><USER17> Holy crap. I've seen people getting hard looks for even suggesting the project's team should stay after the 8 hours shift. Only once a manager asked me to stay, very dreaded and saying he was really sorry he had to ask me that all the time. And they paid me twice the time I've been there and my performance review skyrocketed because I came in when I didn't need to.

But I make about 15k USD (if converting currencies) so there's that haha.

</comment><comment><USER18> > But at a company with more than 15,000 people

Uber has over 15,000 employees? That seems a lot. That's almost the same headcount as Facebook. Why does Uber have so many people?

<comment><USER19> I would wager facebook has more employees than that, and uber likely has many more employees that aren't software engineers than facebook to handle operations around the world.

<comment><USER18> According to this[1] Facebook has 17,048 at Dec 2016. So it's more than what Uber has but not by that much. Good point about the local ops people Uber needs.

[1] [https://www.statista.com/statistics/273563/number-of- faceboo...](https://www.statista.com/statistics/273563/number-of-facebook- employees/)

</comment></comment></comment><comment><USER20> Goldman Sachs was an early adopter of stack ranking. Employees gamed the performance review process, politicking and gaming as annual reviews were to begin -- if you give me a high rating, I'll give you one (.. or will I), turning the office into a game of Diplomacy. Stack ranking and other human resource strategies created an electric atmosphere of productivity but unfortunately was accompanied by many negatives. Some elements of this story about Uber's culture, excluding hostility towards women, seemed familiar. It wasn't until long past the Financial Crisis that Goldman decided to reform its ways, retiring stack ranking in 2015/2016, adopting a continuous performance review process, and changing other managerial practice.

Emulating one leading organization's practices and expecting similar results is a fool's errand. These tech companies are learning that the hard way, I hope.

</comment><comment><USER21> > In college I took several business classes, and one was about Southeast > Asian business. The professor said ... there's this spectrum of stress > level. You want workers to be as stressed as possible, but not over the > line...

Anyone have links/references that name and describe this business style?

</comment><comment><USER22> This seems fairly accurate based off of the accounts of friends and colleagues who have worked at Uber.

</comment><comment><USER23> It's disingenuous (or misinformed) to talk about on-call engineers being annoyed that they're always being woken up by alerts. That's the job.

A lot of companies mis-manage their ops department and flood the on-call staff with after hours alerts because someone is not fixing the underlying issues. This situation is not unique to Uber. (One alternative is to have a 24/7 NOC staff to deal with recurring alerts (and resolving them using a NOC playbook) and escalate to engineers as necessary, which they may have already been doing)

Reporting on these specific issues in this way makes me wonder what other examples in this article might be commonplace in many industries. There's no easy way to know if Uber is a truly horrible place to work, or if they just dug up every inflammatory remark they could find, and confirmation bias is feeding what we want to be true. Although the executives (like the CTO) definitely aren't afraid to sound like dicks.

<comment><USER24> On call doesn't mean you're working. It means you might get a call.

The people I know whom were on call weren't paid at 100% but more in the 10-30% range (on top of their normal salary). They might get a call and were paid accordingly. If they'd get too many calls that had an obvious effect on their performance.

I completely disagree with your statement that being "on call" means that it is their job to "always being woken up by alerts". If you get so many alerts the company should have someone _working_ (roster, etc), not have people on call!

<comment><USER23> We are not in disagreement... you essentially re-stated my comment. But your experience of on-call may be different from mine. (I'm assuming you have also been on-call for a multi-million-dollar 24/7 production service?)

</comment></comment></comment><comment><USER25> I think Fincher should make a movie about Uber.

<comment><USER26> The Social Network (2010) movie was superb. Yes Fincher as director and Sorkin as screenplay writer would be phenomenal. It would take a good book about Uber internals though. Unfortunately the former head of Sony Pictures in L.A. screwed the dream team over the Steve Jobs movie.

</comment></comment><comment><USER27> I am uncertain on this.

Once said that most probably Uber and its culture are the roots of all Evil, there is something I smell as being fishy.

If it was a case of exploitation of "humble", "normal" labour it would be a thing.

But the exploitation of an "elite" of professionals in a "niche" field (such as programming/software engineering), people that are - at least reportedly - paid at a very high level and that every company is looking for (i.e. - <USER2> reportedly - a field where supply is not enough to fulfill demand)?

I mean, if you force a secretary or a clerk or a labourer to do more hours, and go back to the workplace at night and on weekends they have very likely no other choice than to comply.

I can undersatnd how people with a H-1B would have no other choice.

But a 100,000-120,000 US$/year programmer/engineer?

Does he/she have not another choice?

Cannot he/she resign and look for another job if the environment at Uber is felt as "toxic"?

(and find such new job at the same pay level and relatively easily?)

<comment><USER28> Did you read the article? It says on numerous occasions that they're 'trapped' by the lure of equity, they see this as their retirement fund.

<comment><USER27> Sure I did read it, but the whole point is that what they are "trapped" by is (in your words) "lure of equity" (I would personally call that a - _slight_ \- form of "greed", which while rhyming with "need" is not the same thing). It is a choice, from the article:

>"It's a money cult. People are putting up with massive amounts of abuse, mental abuse, constant threats to fire you so you're losing your equity,"

BTW: [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

>Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."</comment></comment></comment>


Running a Startup: Like Running a Russian Nuclear Power Plant - <AUTHOR> http://munjal.typepad.com/recognizing_deven/2007/04/episode_23_my_n.html <comment><USER2> Well, shoot. This guy never heard of bucket testing? Or controls? You have three changes to test. So you split your users into four groups: unchanged, A, B, and C, where each group sees one changed feature. Test & compare.</comment>