Backslash must die - chris-at https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13314285-backslash-must-die <comment><AUTHOR> The sad thing is Microsoft never wanted the backslash. It's all IBM's fault.

DOS 1.0 had no subdirectories. There was no slash: you didn't type A:\FOO.TXT, you typed A:FOO.TXT, and the prompt wasn't A:\>, but rather A>. Incidentally, this still works today, and sometimes DOS boots with a A> prompt.

In DOS 2.0, Microsoft decided to add UNIX-style directories, with . and .. for navigation, / as the separator, cd to change directory and so on. But there was a problem.

DOS 1.0 had used / for flags (e.g. DIR /W). Microsoft's solution to this was to switch to - for flags, but IBM didn't like this change. So Microsoft compromised on using \ as the directory separator and kept / in use for flags.

However, Microsoft clearly didn't like having to make this change. How do we know this? Well, DOS nonetheless also supported / for directories (and thus its successors, including Windows NT do), and, at least for a little while, contained a setting which let you use - as the flag character.

<comment><USER2> A more detailed representation of this topic: [http://www.howtogeek.com/181774/why-windows-uses- backslashes...](http://www.howtogeek.com/181774/why-windows-uses-backslashes- and-everything-else-uses-forward-slashes/)

P.S.: VMS/OpenVMS, which was designed by David Cutler (the same guy who later designed Windows NT after he was poached by Microsoft), used . as directory separator ([https://en.wikipedia.org/w/index.php?title=Files-11&oldid=68...](https://en.wikipedia.org/w/index.php?title=Files-11&oldid=680322555))

<comment><USER3> Comments in TFA also links to an official source [https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh...](https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/why- is-the-dos-path-character/)

<comment><USER2> Thanks, this was the article I was originally looking for.

</comment></comment></comment></comment><comment><USER4> So the thing is, low-level Windows APIs (such as CreateFile) have supported forward slashes for a _long_ time. And since libc/posix-ish stuff like fopen() is implemented with that API on Windows, nearly all programming languages are magically forward/backslash agnostic on Windows. As a programmer, this means that in places where it really matters, you're usually just fine with forward slashes.

Many UIs get confused on forward slashes though (file open dialog, stuff like that), and given that the vast majority of people, worldwide, that understand what files and directories are, believe backslashes are the way to go, I doubt MS is ever going to change this.

But from personal experience - I've programmed cross-platform stuff on Windows for very many years, and I never bothered about backslashes. In all honesty I never understood all the open source stuff that comes with DIRECTORY_SEPARATOR global constants or eslint rules that tell you to use path.join() instead of `dir + "/" \+ subdir`. The forward slash just works, and it has worked for ages.

The only "problem" is that at times you end up concatenating paths together and end up with stuff like

        C:\Temp/mydir/2/..\file.txt

That's a bit quirky in log file and in the debugger. But fopen eats it just fine.

Sure there might be cases where this is a problem, probably the libraries I've seen code around backslashes have good reasons, but really for end-programmers it's no biggie.

Now, MAX_PATH, that's something else. _That_ should die in a fire and it blows my mind that it hasn't been addressed yet.

<comment><USER5> Do you have a source on "vast majority of people ... believe backslashes are the way to go"?

And if you do, do you have a source on why?

Also, yeah, can anyone clarify what the deal with the max path length is? And why it's possible to create a path above the max length but not to simply delete it from the filesystem?

<comment><USER6> Probably no source other than: there are 1B+ Windows users (like me) vs. maybe 100M Mac users + a few million Unix-y users.

<comment><USER7> What proportion of Windows users actually deal with file paths on a regular basis?

<comment><USER8> Out of people young enough to have missed everything prior to Windows 95, I'd bet that easily 90% have never typed a file path.

<comment><USER9> Almost every single working person who deals with URLs or buys things online...or uses facebook has typed a file path styled URL.

</comment></comment></comment></comment></comment></comment><comment><USER10> And, after that, kill CR LF as a line separator. That's an idea which belongs to the era of mechanical Teletype machines.

<comment><USER11> CR LF is the Internet standard, however. TELNET, SMTP, FTP, and most significantly HTTP/1.1 all specify CRLF is to be used as the line terminator (not LF). Many popular implementations will accept a bare LF as well, but messages containing a bare LF are strictly not standards conforming.

Given this is fixed in RFCs, it is unlikely to ever change

<comment><USER12> This is not why Windows uses CRLF, nor is it some original reason that is now obsolete. It was standard for both DOS' predecessors and early internet standards because teletypes considered carriage return and linefeed separate commands, and both were built to operate with those things.

None of that stopped UNIX from getting away from it, and the internet is basically built on UNIX. What transformations the C FILE stream implementation makes to linefeeds has nothing at all to do with TELNET, SMTP, FTP, or HTTP. These are very separate areas of concern. In Windows if you're writing socket code you have to explicitly write the \r and the \n, just like on any other platform.

<comment><USER11> "the internet is basically built on UNIX" is an odd thing to say. In the early days of the Internet (early 1980s, 1970s if we want to include ARPANET as the current TCP/IP-based Internet's predecessor), it was a very diverse place, with lots of DEC operating systems (TOPS-20, VMS), IBM mainframes, and various other mainframe and minicomputer vendors, with Unix by no means predominating. The Unix monoculture (and later Unix/Windows biculture) grew through the 1980s and was well-established by the 1990s. Major protocols such as IP, TCP, UDP, TELNET, FTP and SMTP were all developed prior to that Unix monoculture taking hold. FTP in particular shows the pre-Unix heritage very clearly, with support for record-oriented filesystems (STRU R, MODE B, MODE C) for DEC and IBM operating systems, support for systems that don't use 8-bit bytes (e.g. TYPE L36), built-in ASCII-EBCDIC translation (TYPE A and TYPE E), support for ASA carriage control (TYPE A C and TYPE E C), and support for TOPS-20 paged files (STRU P). (These are all features pretty meaningless on Unix systems, which is why Unix FTP clients and servers largely do not implement them.)

<comment><USER12> Feel free to insert "as we know it", because I do not believe that the pre-1980s internet is recognizably the same thing. I will not strongly argue the point since I wasn't there.

But to clarify on the salient part, I was trying to say that UNIX diverged (successfully) from what came before it, and the CRLF behaviour was from the teletype era that the early internet started in. My point about UNIX being a building block of the (modern) internet was more about pointing out that if UNIX could diverge from that and be a key component of the internet, it's absurd to think that Windows could not.

I can definitely understand how you got where you did from what I said, though.

<comment><USER13> Thing is, UNIX _also_ came from the same teletype era that the early Internet started in.

</comment></comment></comment></comment></comment></comment><comment><USER8> Forward slash has worked just fine on Windows for a LONG time. Backslash will probably still be around in the year 3,000 for backwards compatibility though.

<comment> chris-at You should say it 'works sometimes'.

I actually forgot where it works because

\- if I try to open a file `i:/foo/bar/test.txt` I get `The file name is not valid` (from Notepad)

\- if I try to open a folder `i:/foo/bar` I get `The folder name is not valid`

\- if I try to `cd /foo/bar` I get `The system cannot find the path specified.`

<comment><USER14> It doesn't help that the various Windows dialogues treat '/' differently.

Windows really should have _just one_ file open dialogue, etc.

<comment><USER15> I _hate_ that reimplementing the open dialog is an acceptable practice on Windows. I have one dialog in Acrobat, another one in AutoCAD, another for AGI32, and (I think the standard one) in Chrome. Probably others that I'm forgetting.

Each of these has its own special list of "favorites" on the left, so if I want to add a shortcut to a commonly used folder, I find myself doing it in 8 different places. Or in some cases I can't; Acrobat has a sidebar with large icons of Recent Places, Desktop, Libraries, Computer, and Network. If you wanted to add somewhere more useful, you're shit out of luck.

Anyone know why this happened? Was there a period around Windows XP where the built in dialog was just godawful and everyone said "Fine I'll make my own" and then they never went away?

Compare to OS X where any time someone rolls their own dialogs for system features (especially Open and Print), I immediately assume the developer is an asshole. And for the most part, nobody does it. The only one I can think of off the top of my head is printing from Chrome, and theirs even includes a "Print using system dialog…" button.

<comment><USER14> It's been one of my many pet hates about Windows since first having to use it regularly, around NT or 2000. Windows isn't even consistent _with itself_ over the look of things bringing elements of previous and future versions of Windows to your desktop.

To add to the sibling comments...

From MSDN _" Windows continues to support the old-style Open dialog box for applications that want to maintain a user-interface consistent with the old- style user-interface"_

No, no and thrice no. If I'm on Win 7, _everything_ should look Win 7 consistent. Likewise if I'm on 10 it should all look 10, perhaps with necessarily reduced functionality if it's a deprecated call.

If I'm running Visual Studio on 7, I don't want all my icons, and GUI to be of 10. No matter how diligently you upgrade, there is always something visually out of step. Even with only MS software.

I suspect it was the very late arrival of a Windows Style Guide made a lot of developers get the habit of doing their own thing. Then they'll start faffing around with variations so you can have preview in open. Hell, might as well do our own everything. The rules didn't say you shouldn't.

Mac always had a pretty tight, and extensive, Style Guide with apparently thought down to individual pixels; Windows seemed not to care, or not understand when it did care. Around XP Windows started caring more about UX, but probably far too late.

<comment><USER16> More than a decade ago, MS used to kind of have that, and mostly consistent at the architecture level, but I think it was only by chance (win 3.1 programs still had all their legacy dialogs, including open file), because they just did not have had the time yet to implement 1000 different graphical frameworks for example, or to evolve dozens of ribbon interfaces from various unrelated teams. Now it is nothing else than an absolute mess: Win32 programs are very different from UWT stuff (and not just the drawing of the control, the whole interaction model is completely different), and you've also got layers of unrefreshed designs inherited from the guidelines (or informal practices) of the day of the version of windows the component was first introduced in, with inspiration flowing from other teams (or even other systems) but with no common technical framework continuously shared between them, so for example Office also has its very own stuff.

This is a big difference, and in the end a classical one, in the way companies typically work compared to open source projects (not just open source code, I'm really talking about the whole project being open): in companies teams or individuals just don't collaborate as much, because projects are often extremely closed even within the companies, with all kind of access rights. And also some app team might want to support really old OS (who uses a Linux distro of 2009 today? Well, OTOH tons of people are using a Windows version from 2009...) for a few more years and that OS certainly won't add any kind of support for the UI the app guys want, and the app guy might not want to use loads of resource to make their app look neatly graphically integrated in old OSes.

In summary, for proprietary stuff, this is an hard problem both at the technical and at the organizational level, especially if you like to change your graphic experience so often like MS does. And now everybody is used to seeing widely inconsistent stuff on the same screen anyway, so old on new / new on old / different on different cases will remain, I guess. Plus converging UI from vastly different devices is also a hard problem in itself, and UWP is actually not bad at it -- but the price is obviously that it must be irrecoverably different from old Win32 programs.

<comment><USER14> That's true, I'd forgotten. Win 2k was fairly consistent about things, and even XP had a fairly decent classic fallback mode.

I understand a lot of the baggage they're carrying for keeping compatibility and suffering 20 year old choices etc. I can't help but feel that 7 or 8 should have drawn a hard MacOS/OSX like line under things and given us a modern windows with newer choices. Add a VM for running your old XP app. Throw cmd and dos away entirely.

I actually respect MS for being brave enough to experiment with the GUI as much as they have, yes and get it terribly wrong sometimes. A classic fallback, or a 7 fallback for 8 would have made the 8 fail easier to bear.

Not entirely sure the company / open comparison is the whole story. Someone somewhere designed metro (or 7, or 10), figured out a UI and design language, and had some principles behind it. Those could be made the contract for the team's software being seen in the world. Again Windows has it more complex as so much of the GUI ends up in the .exe, so what you see is when it was made not what it runs on.

I think you're right in that having got where we are, it's unlikely to easily improve.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Many Windows commands use "/" to introduce options (much like most Unix commands use "-"). Since the default command shell doesn't require whitespace after the command name and permits options to follow other arguments, it would be difficult to use "/" as a directory separator in all cases.

An example from Microsoft's documentation:

        dir c:\*.txt /w/o/s/p

<comment><USER18> I'm not sure if this normal or not, but I have a lot of trouble telling the back slash and forward slash apart.

<comment><USER19> Either your system font is weird, or you're dyslectic. Seriously.

<comment><USER20> *dyslexic

</comment></comment></comment></comment><comment><USER21> The best part of using backslashes in paths is that for character encoding historical reasons, backslashes are printed as ¥ in Japan.

C:¥Windows¥System32.

</comment><comment><USER22> It would be nice if we could get Windows internally to use paths like / for the C drive and then use /mnt/d for the D drives, and use Bash as the default shell instead of cmd.exe. I suspect it will take some time, but if they do so, it would make Windows a first-class POSIX development setup.

I can only imagine the difficulty of something like this, given all the legacy code and backward compatibility issues. Perhaps intelligently rollback to C:\ style paths when apps use backslashes. For Program Files, they might as well continue using /Program Files/ since it's not all too different from /opt.

<comment><USER23> You _can_ mount drives at empty directories in other drives, just like Unix. I have C: on an SSD and mount a HDD at C:\Stuff

I remember one installer that didn't understand this (I think it was Steam) and concluded it wouldn't install to C:\Stuff\foo because there was insufficient disk space under C: - it was looking at the free space of C: (the SSD) instead of C:\Stuff .

There's also plenty software out there that confuses volumes with drives and tries to enumerate the latter when it should be enumerating the former.

</comment></comment><comment><USER24> I thought this was about people still misreading URLs more than 20 years since the popularization of the web as "example-dot-com-backslash-tour"

I've never understood that. The only way I could explain it in the 90s was because "computers use backslashes" due to the ubiquitousness of DOS and Windows paths. Now, who types a path on their local machine besides developers using a command line?

</comment><comment><USER25> Would that involve also adding smb://HOSTNAME as opposed to \\\HOSTNAME?

<comment><USER26> PS C:\> cd ~/..

PS C:\Users> cd /

PS C:\> cd //localhost/c$

PS Microsoft.PowerShell.Core\FileSystem::\\\localhost\c$>

</comment></comment><comment><USER27> I don't even have a working Windows image to try the new bashy goodness, but this was my first thought when it was announced: what about the slash/backslash difference? But even twenty years ago, bouncing back and forth between DOS/Windows and some flavor of Unix, I wished MSFT would get with the program and ditch the hard-to-reach backslash.

<comment><USER28> And the path length limitation

<comment><USER29> Windows already does accept forward slash in paths and has for a while. The back slash still lives for legacy applications and unfortunately probably will for a long long time.

<comment><USER30> How is it possible I didn't know that? Thank you. Does anyone know the history of it? I did a little research:

* I found someone asking the same question as me in 2005 (!) [1]

* Per someone on Stack Overflow: "/ can be used as a path separator at the API level, but you aren't calling the API directly. You're using cmd.exe, and cmd.exe parses the / as a command line option" [2]

* Later in the same Stack Overflow discussion someone performs a series of tests on Vista, with some inconsistent results. [2]

* Here's a history by veteran Microsoft developer Larry Osterman, which takes us back to the developers of MS-DOS and also mentions other undocumented ways MS-DOS can/could be made Unix friendly. [3]

\-----

[1] [https://bytes.com/topic/python/answers/23123-when-did- window...](https://bytes.com/topic/python/answers/23123-when-did-windows- start-accepting-forward-slash-path-separator)

[2] [https://stackoverflow.com/questions/10523708/why-does-the- cm...](https://stackoverflow.com/questions/10523708/why-does-the-cmd-exe- shell-on-windows-fail-with-paths-using-a-forward-slash)

[3] [https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh...](https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/why- is-the-dos-path-character/)

<comment><USER31> > How is it possible I didn't know that? Thank you. Does anyone know the > history of it? I did a little research:

According to the history, DOS 2.0:

[https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh...](https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/why- is-the-dos-path-character/)

[begin quote] Here's a little known secret about MS-DOS. The DOS developers weren't particularly happy about this state of affairs – heck, they all used Xenix machines for email and stuff, so they were familiar with the _nix command semantics. So they coded the OS to accept either " /" or "\" character as the path character (this continues today, btw – try typing "notepad c:/boot.ini" on an XP machine (if you're an admin)). And they went one step further. They added an undocumented system call to change the switch character. And updated the utilities to respect this flag.

And then they went and finished out the scenario: They added a config.sys option, SWITCHAR= that would let you set the switch character to "-".

Which flipped MS-DOS into a _nix style system where command lines used "-switch", and paths were / delimited. [end quote]

</comment></comment></comment></comment></comment><comment><USER32> I think this post is a little bit confused, since it talks about Bash in Windows, but I've seen no evidence that Bash supports backslash as a path separator in Windows. I agree it's unfortunate that backslash paths are still around, but I guarantee you that won't be the most annoying issue with running Linux userspace tools on Windows.

</comment><comment><USER33> The really sucky thing about working on Windows is the paths. On Linux my applications are in /opt or /usr/apps. On Windows the path names seem super long and include all sorts of parens and spaces and such.

<comment><USER34> That was intentional to force programs to work with spaces and "special" characters.

<comment><USER35> Naw, it was just to give users "friendlier" directory names like "Program Files" and "Documents and Settings".

</comment></comment></comment><comment><USER36> Why is backslash called BACK slash when it actually points forward?

[http://ux.stackexchange.com/questions/92390/why-is- backslash...](http://ux.stackexchange.com/questions/92390/why-is-backslash- called-back-slash-when-it-actually-points-forward)</comment>


FuckIt.py - The Python Error Steamroller - <AUTHOR> https://github.com/ajalt/fuckitpy <comment><USER2> If anyone is curious (or lazy), FuckIt works by opening up the AST [0] and wrapping almost every statement (except those that declare functions) in a silent try-catch block [1].

[0] [http://en.wikipedia.org/wiki/Abstract_syntax_tree](http://en.wikipedia.org/wiki/Abstract_syntax_tree)

[1] [https://github.com/ajalt/fuckitpy/blob/master/fuckit.py#L70-...](https://github.com/ajalt/fuckitpy/blob/master/fuckit.py#L70-L77)

<comment><USER3> I tried doing something similar with Perl, which as I understand matters does not actually have an AST. It does have something called "source filters", which I gather are almost entirely unlike Lisp macros; despite that seeming like the best available option (the filter, in this case, being one which wraps the whole script containing 'use fuckit' in a quoted eval whose $@ is ignored), the closest I got with it was segfaulting the Perl interpreter, which certainly counts as some sort of result.

</comment></comment><comment><USER4> The test suite is amazing.

[https://github.com/ajalt/fuckitpy/blob/master/tests.py](https://github.com/ajalt/fuckitpy/blob/master/tests.py)

        def test_chaining():
            fuckit(fuckit('fuckit'))

            assert 'false' # Good thing this isn't PHP

<comment><USER5> This guys got a good sense of humor.

</comment></comment><comment><USER6> There's something to be said about the quality of programming API-kids do these days, if FuckIt.lang projects are so popular. Not to jab this project itself by any means, but hiding defects _" on your way to doing that million dollar demo to investors"_ makes my skin crawl. How many con men are in this industry? This is damn sad. If you need a tool like this beyond your private debugging needs, you don't understand what you're doing and should step back and take the time to reason things out.

<comment><USER7> Assuming this project is satire (which I hope it is), it's amazing because it:

\- does something rather novel

\- does something that, to the sufficiently desperate or inept developer, might seem like a half-decent idea or a cunning shortcut

\- does something that is just asking for trouble and that nobody in their right mind should do without expecting terrible, terrible things to happen

<comment><USER8>
        - does something that is just asking for trouble and that nobody in their right mind should do without expecting terrible, terrible things to happen

It makes Python run about like JavaScript or PHP. I guess that's accurate.

<comment><USER9> Some people use Python as JS or PHP, why not also make it behave like that?

In reality, even if this is satire (which I believe it is) I'm sure if enough people will know about it, at least one of them will use it seriously.

<comment><USER10> > Some people use Python as JS or PHP, why not also make it behave like that?

If you want to go the other way, try

        window.onerror = window.close;

</comment></comment></comment></comment></comment><comment><USER11> Based on fuckit.js, although fuckit.py seems to eat errors while fuckit.js reruns code while removing the offending line until it runs:

[https://github.com/mattdiamond/fuckitjs](https://github.com/mattdiamond/fuckitjs)

<comment><USER12> That reminds me of Vigil[0], a Python-derived language that defends supreme moral vigilance.

[0] [https://github.com/munificent/vigil](https://github.com/munificent/vigil)

</comment></comment><comment><USER13> "Still getting errors? Chain fuckit calls. This module is like violence: if it doesn't work, you just need more of it."

I feel like writing some Python now.

<comment><USER14> I like this one: "Keep in mind that the decorator form of fuckit can't stop syntax errors. For those, you have to use the import form."

</comment></comment><comment><USER15> As the author of FuckItJS, I approve of this effort. And thanks for the attribution!

</comment><comment><USER16> "Don't silence KeyboardInterrupt or SystemExit. We aren't monsters." Hahahahha

</comment><comment><USER17> This module is not satire, and the existence of this module does not indicate anything about the quality of programmers of this generation.

For those who think so, try doing some machine learning, data handling code, or even web crawlers. Error tolerance is much needed.

For scientific experiments, sometimes the results of the experiment is still valuable even if there's a trivial bug (malformed row). A partially-correct execution is still more information than an unhandled exception causing an early exit.

<comment><USER18> Having worked on all of those, this module is satire and foolish to use in normal code. The rule is protect your boundaries and whenever data comes in it requires careful handling and thoughtful error policies. The entire notion of taint from Perl comes to mind.

If anything, your error messages are more important then.

</comment></comment><comment><USER19> _" This module is like violence: if it doesn't work, you just need more of it."_

if for nothing else, I am in love with this for its sense of humor

<comment><USER20> From Nokogiri's homepage: XML is like violence - if it doesn't solve your problems, you are not using enough of it.

</comment></comment><comment><USER21> I just wrapped all my testcase's in fuckit and all my tests are now passing. I'm ready to ship!

</comment><comment><USER22> I like the opposite approach, where broken code is explicitly removed. vigil ([https://github.com/munificent/vigil](https://github.com/munificent/vigil)) attempted to do this

<comment><USER23> Well, when importing a module, it removes lines until it imports.

</comment></comment><comment><USER24>
        On Error Resume Next

<comment><USER25> That makes me shudder.

At one point in a previous life, I was the administrator for HP Quality Center at my company. On the good side, HP exposes the entire workflow in VBA (ok, I guess that isn't that good actually, but still better than black box).

On the horrible side, EVERY SINGLE FUNCTION in that application began with the line "On Error Resume Next". I quite nearly quit on the spot the first time I looked at the code. A couple years later, I would regret that decision.

</comment></comment><comment><USER26> I wrote a library so you don't have to use this:

[https://github.com/kislyuk/ensure](https://github.com/kislyuk/ensure)

(Though I know how frustrating exception juggling can get... especially when they get pickled and re-raised)

</comment><comment><USER7> > "the test suite actually found a bug holy crap"

I'm sad to say I say this every time this happens to me as well.

</comment><comment><USER27> A python version of PHP's '@' operator, nice!

</comment><comment><USER28> Loved reading tests.py:

def test_context_manager(): with fuckit: pass

        assert 'P' != 'NP' # proof is left as an excercise for the reader

</comment><comment><USER29> This gave me an idea which is probably terrible. Instead of eating errors or ignoring them, use genetic programming on the code until it passes all your tests and doesn't give any errors. It would still be terrible to actually use, but it might actually get the code to work.

<comment><USER30>
      import fuckit
      from string import ascii_lowercase, digits
      from random import choice, randint

      def defuckify(test_fn, fn_name, n_arguments):
      ''' Randomly generate functions until the test passes
      '''
          defuckified_fn = ('def %s(' % fn_name)
          for i in range(n_arguments):
              arg_name = ('arg%d,' % i) if i != n_arguments else ('arg%d' % i)
              defuckified_fn += arg_name
          defuckified_fn += '):'
          exec('def '+ fn_name + '():\n    pass\n')
          while not test_fn():
              for i in range(randint(100,10000)):
                  defuckified_fn += choice(' \n,[](){}\'"=+-*/%:'+ ascii_lowercase + digits)

              with fuckit:
                  exec(defuckified_fn)
          print(defuckified_fn)

Edited to use fuckit instead of try/catch

Edited again to add that it has been over an hour and it hasn't been able to make a function that returns 3

<comment><USER31> It seems like `unfuck` might be a more pythonic name.

That is not a pair of words I ever thought I'd use in the same sentence. :)

<comment><USER29> How often do you say "unfuck"?

<comment><USER32> Do you know a better term for "debug others' code"?

</comment></comment></comment></comment></comment><comment><USER33> Is there an actual use case for something like this? I'm legitimately curious.

<comment><USER34> On a semi-unrelated topic, can anyone imagine a use of write-only memory? I swear I'd came up with one few years ago and unable to recall it anymore.

<comment><USER35> There was some april joke like that, they even created data sheets if I remember it correctly

edit: found it [http://www.repeater-builder.com/humor/signetics- wom.pdf](http://www.repeater-builder.com/humor/signetics-wom.pdf) I love 0V +- %2

</comment></comment></comment><comment><USER36> Because after 48 hours of working on the same bug, there's nothing quite so satisfying as going completely John McClane on its ass.

\- Yippie kai yay, motherfucker.

</comment><comment><USER37> Most appropriate choice of copyright license ever.

<comment><USER38> seems pretty restrictive to me :

"...and changing it [license] is allowed as long as the name is changed."

edit: i was joking :)

<comment><USER39> That's the licence for the license, not the license for the code itself.

The licence for the code itself is "0\. You just DO WHAT THE FUCK YOU WANT TO." The license for the license is similar, with the caveat that you're required to change the name if you change the content. Which makes sense; we wouldn't want confusion about what the WTFPL refers to.

</comment></comment></comment><comment><USER40> This truly appeals to the difference between Engineer and Scientist in all of us. I can see myself getting heavy use out of this.

</comment><comment><USER41> I just can't believe how many commenters here don't get it's a joke or are carefully unsure. A. Ma. Zing.

</comment><comment><USER42> It's like the exact opposite of Perl's "use strict" pragma. ;)

</comment><comment><USER43> Reminds me of [http://criso.github.io/ChuckNorrisException/](http://criso.github.io/ChuckNorrisException/)

<comment><USER44> Is there a Python version? If so does it beat Fuckit.py?

</comment></comment><comment><USER45> I think my favorite part of it had to be the readme for using it with decorators:

@fuckit def func(): problem_solved

That has to be the best piece of code I have ever seen.

</comment><comment><USER46> i've used this for a while now--really useful debugging tool in my workflow. Does exactly what it says on the tin.

just wrap the offending module and get on with your life; and in those rare (for me) instances where you still get errors, this module supports chaining syntax--declarative syntax, to say the least:

fuckit(fuckit('imported_module'))

<comment><USER47> How could this be helping in debugging? I'm curious!

<comment><USER48> It's a joke

</comment></comment></comment><comment><USER49> I'm assuming this is a joke. If so, it is funny.

</comment><comment><USER50> Does this fix circular import for me...?

<comment><USER51> yes

</comment></comment><comment><USER52> I'm so tired of the use of profanity in names. Why is this acceptable in this industry?

<comment><USER3> Because we're all adults with functioning senses of humor, where 'all' is defined as a 'mostly' whose exceptions tend to be both immediately obvious and unbearable in social settings.

<comment><USER52> OK. Adult. Got it.

</comment></comment></comment><comment><USER53> this library should actually be called "phpify"

</comment><comment><USER54> made my day

</comment><comment><USER55> wtf!</comment>


Enough already with the lame "tutorials" - <AUTHOR>

Is it just me or are there way too many To Do List tutorials and "application boilerplates" floating about? It's great that people want to try out new frameworks, as I do all the time, but it would be much better if people tried building something a bit more detailed than the standard To Do app. And if you're going to do a To Do app, or any tutorial for that matter, it should include tests as testing is a priority when building real world applications. <comment><USER2> TodoMVC is great because every framework has to implement the same thing. That lets you see some of the warts of the framework.

Skimming over the official Angular docs and examples you probably wouldn't guess that ngRoute won't let you use $routeParams if the app doesn't include an ngView.

The TodoMVC example makes that obvious, since that's the only reason it splits of part of the page into a separate template.

Framework authors and evangelists will naturally show off examples that make the framework look good. People complaining about a framework usually don't understand it well.

Implementing a standard task is a great introduction to a framework.

</comment><comment><USER3> > It's great that people want to try out new frameworks, as I do all the time, > but it would be much better if people tried building something a bit more > detailed than the standard To Do app.

And, you know, people do. A _tutorial_ app isn't the extent of what the author tried out, its something where the author felt would provide a good basis for pedagogy on the tool it is a tutorial for.

> And if you're going to do a To Do app, or any tutorial for that matter, it > should include tests as testing is a priority when building real world > applications.

Plenty of tutorials include testing, but if the framework being demonstrated isn't particularly special in terms of testing given the language and other aspects of the platform, there's not necessarily a compelling reason for every tutorial to do so.

Seems to me the complaint here is "people supplying job-relevant training material to the world for free aren't always doing it exactly the way I'd prefer to have it", which is pretty entitled.

<comment><AUTHOR> I'm not asking for job-relevant training material. It would just be more fun if tutorials were trying out different ideas. I relate it to if all authors wrote the same story you would be frustrated after a while that no authors were telling different stories.

For instance, whenever I find a new framework or methodology, I'll build out a replica of a whatever phone app is the du jour of the moment. Building the same app over and over again gets boring after a while and doesn't push your line of thinking. But that's just my opinion.

</comment></comment><comment><USER4> This is why I like what the guys at Onemonth are doing. The Python/Django course guides you through building a Yelp style app while the Rails and Swift courses build a Pinterest / Instagram clone.

I've done both the Rails and Django courses and while I'm nowhere near being experienced in either, I'm far more motivated to keep learning the languages than I have been after doing any other course/tutorial

[http://mbsy.co/onemonth/10695276](http://mbsy.co/onemonth/10695276) (affiliate link)

</comment><comment><USER5> I also think there are lots of tutorials, and many of them doesn't even help at all. But, remember that tutorials are for beginners, and they should be simple. If it include testing, I believe it could be even more complex (it may not be complex for everyone, but tutorials are mainly for newcomers) to understand.

I would rather see less but more effective tutorials.

<comment><AUTHOR> As a teacher of web development for people who are 100% new to programming, every application I have class build has tests. If you're going to teach people, especially newcomers, we should stress the importance of testing what you build and show how fun and easy it is to test as you build. :)

<comment><USER6> It's good that testing is covered as part of your teaching strategy, because as you said, in any real world environment that experience will come in handy.

But the audience reading and sharing links on Hacker News are likely to have a deeper body of knowledge in this area than pure beginners. People posting tutorials (for free) may be targeting this more experienced group of people, who may take it for granted that a beginner's tutorial will not cover everything necessary to go from a prototype to production-ready software.

I also feel that as people progress through tutorials, they will organically come up with questions that the tutorial has not covered at all, like "how can I test this to make sure it's bug free and can withstand lots of concurrent logins?"

</comment></comment></comment><comment><USER7> The To Do List MVC isn't all that great, but thankfully it beats the "I'm building a new language and here is my best effort 'Hello World' example, which should be good enough for you to code anything from."

Try starting your own blog and coding a more lengthy example OP. Be the change.

</comment><comment><USER8> This is why I don't write Haskell tutorials. I am learning and would love to write them, but I don't want to pollute the space when more experienced Haskellers can write better ones. I just need to be patient :-). Actually I do write them but just keep them on my dropbox (private) for a memory refresh on a topic later on.</comment>


Existential crisis at Railsconf - <AUTHOR> http://railsbird.tumblr.com/post/117076597115/existential-crisis-at-railsconf <comment><USER2> LOL at the idea that every Rails programmer will be switching to Clojure or Elixir! While they might be interesting languages (particularly Elixir) I don't see any 10x advantages their web stacks have over Rails for the typical "majestic monolith" use case.

Re. EventMachine: As I understood DHH's speech, the idea is that ActionCable abstracts all the messiness around EventMachine, Websockets, Rack and threads. We won't know until some ActionCable code is released but it sure didn't look complicated.

It does seem odd that -api takes years to get in, but ActionCable gets a go- straight-to-core pass without any community review first. It certainly seems like a weakness in the process, which should be addressed, although I'd agree with the eventual result & priorities. -api probably isn't something I'd ever use: even if I eventually created an API-only app, I'd probably have started from a regular Rails app and gradually optimised things out.

Edited to add: I'm actually quite bullish on TurboLinks 3 if it can help me to avoid ever having to write a Javascript MVC app again. It's not so much that these apps are hard to write, it's that they're freaking hard to debug, particularly in the hands of users.

<comment><USER3> > the idea that every Rails programmer will be switching to Clojure or Elixir! > [...] I don't see any 10x advantages [...]

I do. While I cannot speak for Clojure and Elixir, I can speak for Haskell, which I have moved to from Rails.

10x for me is:

1\. A 70MB all-in binary to deploy, using 1-3MB of memory when running (has a build in HTTP(S) server), responding in 2-10ms to my requests. Compare that to 700-1500MB of gems, using hundreds of MB while running, serving requests in 50-200ms... More then 10x! And my framework of choice (Yesod) consists of 23kLOC, where Rails has 210kLOC (source: openhub.net)... Another 10x!

2\. Less bugs when growing the codebase; "strong compile time guarantees" is now my main weapon when fighting maintenance curve.

Back in my Rails days I'd say "typing is a very narrow form of automated testing", which given my exposure to C++/Java was defendable opinion.

Now I say "strong typing is a wonderful test suite you get for free and automatically stays up to date". Not that it replaces tests; but it literally a wonder how Haskell's HM-typesystem it rejects broken code at compile time.

TL;DR: I believe 10x frameworks are out there.

<comment><USER4> Strong typing on the web has been an intractable problem for me so far. Sure, I can have strong typing in my server-side code. But so many errors result from the interaction between the server, CSS, HTML, and JS. For example, you define a route at the path `/apples` but send an AJAX request to `/oranges` instead. Or you write `<div class="apples">` but query it with `div.oranges` instead. These are very much like type errors or name errors, except they occur at the boundaries of languages and processes.

Have you worked out a way to catch these sorts of things at compile time? If not, do you think it's possible in the framework of the future?

<comment><USER5> The examples you give don't seem to be typing problems, they seem to be wrong- value problems. They might incidentally _also_ involve typing issues (e.g., "/oranges" might not exist or might be an endpoint with a different signature than "/apples"), but that doesn't seem to be the central problem in any of the examples.

> Have you worked out a way to catch these sorts of things at compile time? If > not, do you think it's possible in the framework of the future?

To the extent that they are typing problems, it would seem conceptually possible to catch them through a strongly typed language and framework that abstracts all the underlying technologies and compiles to a combination of backend executable(s), and front-end HTML, JS, and CSS, and includes all the routing for both ends.

Actually building such a beast would seem to be a non-trivial engineering challenge.

<comment><USER6> _" [I]t would seem conceptually possible to catch them through a strongly typed language and framework that abstracts all the underlying technologies and compiles to a combination of backend executable(s), and front-end HTML, JS, and CSS, and includes all the routing for both ends"_

That would certainly do it, but I think all you need is some definition of interface that you can check your code against on both sides. This could be generated by one side and consumed by the other, or produced directly by the programmer(s) and consumed by both. You would need some means of actually checking your code against the specification on the consuming side(s), but they needn't be part of some broader framework (beyond the trivial sense in which they already are).

<comment><USER5> Sure, you can do that; but the problem is that you then have to worry about type system mismatches between the interface definition language, and the back- and front-end application languages.

There have been _lots_ of things that do something like this: SOAP and the associated WS-* standards are probably the best known.

<comment><USER6> Very true, and certainly still a big undertaking, depending a little on how well the type systems at either end line up.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> > Unfortunately, we don't have better options in Ruby for working with > websockets.

We do! Celluloid (the actor model) is vastly superior to EventMachine in my opinion. It fits much better to Ruby's OOP style and I suspect would integrate into Rails very cleanly. I am positive that bringing any EventMachine technology into the Rails stack would be a mistake.

I am saying that with a bit of a bias as I have written my own celluloid- websocket[0] gem that comes with a Rack adapter. But I wrote it because I put a project using EventMachine websockets into production and was not happy with it. Now in a new project I can just hook up the celluloid-websockets Rack app and run it using `passenger start` or any of the Rack application servers.

Even though so many people seem to flock to Node.JS for these kinds of servers, the fact that as a language Ruby is superior to Javascript remains, even if Javascript VMs are a hundred times as fast. As long as Node.JS is run on standards compliant VM's things like promises are just lipstick on the callback hell pig. You can write clean and understandable Ruby to solve any problem, including Websocket servers. We as the Ruby community were just late to the asynchronous I/O party. Now Celluloid is production ready, there's really no reason (except for performance of course) for a Ruby developer to write Javascript on the server side.

(sorry for my extreme opinions, if you want a more nuanced deliberation on a point just ask ;))

0] [https://rubygems.org/gems/celluloid- websocket](https://rubygems.org/gems/celluloid-websocket)

<comment><USER8> >> the fact that as a language Ruby is superior to Javascript remains, even if Javascript VMs are a hundred times as fast.

As someone who frequently switches between Ruby/Rails and NodeJS (sometimes in the same day), I wonder about this statement (err, fact).

You mentioned that the Ruby language is superior and that this is a "fact". What about the Ruby (I know Node isn't really a language, but for the sake of discussion, Node,JS,npm) is substantially better that the speed trade-off is worth it (besides familiarity)?

In my case, I'm familiar with both, and I prefer Node,JS,npm. Node,JS,npm are definitely not perfect, yet still, I like it over Rails,Ruby,Gems/Bundler.

I'm not looking to "win" here; I'm just very curious now given your assertion.

<comment><USER7> > What about the Ruby (I know Node isn't really a language, but for the sake > of discussion, Node,JS,npm) is substantially better that the speed trade-off > is worth it (besides familiarity)?

It's a bit stupid, it's hard for me to even consider the idea of Javascript being in the same category as Ruby. Of course, with Node.JS existing it's totally fair to bunch them in the same category, they're both server side scripting languages.

Ruby was designed from scratch to be a perfect generic scripting language, merging the OO concepts of Smalltalk with the power and unix-friendliness of Perl. No constraints, just an implementation of a programmers dream.

Javascript on the other hand was designed to be a language ran in the browser, with a tightly controlled I/O system a very domain specific standard library and a very short schedule. It's got warts and plain mistakes, it took decades for people to see past them and value Javascript for its redeeming qualities. The redeeming qualities being first class functions and the unexpectedly useful asynchronous I/O model.

You state that you like Node.JS over Rails. I would hesitantly agree. Rails isn't of this time anymore, they made the mistake of not embracing JSON APIs as the future of web development, and are foolishly continuing work on serving HTML. That both Rails-API and ActionCable were not in Rails 4 demonstrates they are simply behind the times. At the time that it became clear JSON APIs and Push protocols would become important people looked around and saw the Ruby ecosystem simply had nothing to offer. Rails wasn't serving them, and all other Ruby projects were either small, not production ready and in either case had no community following. It was a perfect moment for Node.JS which put the modern web right up front. At least, that's how I view that history.

Of course, 90% of web applications being developed today are not 100% single page apps with JSON and websocket backends, so Rails isn't quite dead yet. But perhaps if you're to looking to build such a modern app the Ruby ecosystem isn't the ideal place to look for it anymore. That doesn't mean it's not viable anymore. I wrote celluloid-websocket in a few dozen lines, it basically connects Faye's websocket protocol implementation with Arcieri's Celluloid and Rack.

I really want to write half a book more about why I think Ruby is so much better than Javascript, but it's getting late so you'll have to excuse me.

<comment><USER8> >> ...it's hard for me to even consider the idea of Javascript being in the same category as Ruby.

Indeed. I think anyone would agree...they were not built for the same purpose; however, let's set some expectations here. As it relates to backend JSON APIs, what is better about Ruby/Bundler?

>> Ruby was designed from scratch to be a perfect...dream

OK, that's fine. Though, I've never heard of a proven perfect language/platform, regardless of intention.

>> I really want to write half a book more about why I think Ruby is so much better than Javascript...

Please, no book, but I would be happy to read one concrete example of why Ruby/Bundler is substantially better hands down. Of course, you are free to argue that you just don't like JS. I'd be fine with reading that, but I'm still curious to see a real example. I'm willing to accept that I may be wrong, but without proof, we can't get there.

Yes, Ruby is a nice looking language; still, I have not come across any proof that writing, maintaining, and deploying Ruby/Bundler is __substantially __better than writing, maintaining, and deploying Node /npm for backend JSON APIs __especially __given the gratis performance benefit and ease-of-use of Node /npm.

The same or better result with lower overhead and better performance. Before I ever wrote a line of JS intended to be executed via Node.JS, I actually thought Ruby was better as well :)

 __*

NOTE: I am quite aware that some Haskell lover is probably laughing and sticking their nose up at this entire conversation. That is perfectly fine because I'm willing to bet they can actually provide the concrete example I am looking for.

<comment><USER7> > Please, no book, but I would be happy to read one concrete example of why > Ruby/Bundler is substantially better hands down.

One illustrative example might be the existance of Celluloid. The idea that you as a developer of Ruby apps can swap out the I/O system to something that's arguable better than what what the default style is. The reason Javascript can't do that is because it doesn't have synchronous I/O, nor multithreading, it's simply lacking those primitives.

I don't like the callback style, and I'm not entirely sold on promises.

In any case both those 'issues' might be close to fundamental differences between Ruby and Javascript but if I'm honest, this is going to sound like I'm back pedalling, but in real measurable terms they won't affect the quality of your codebase. I don't think porting a library from Javascript to Ruby would solve any real problem (as Haskell would), and it would result in your library being slower.

The dozens of little things that make Ruby a more pleasant language, they are what keeps me on the Ruby side for most projects.

> I am quite aware that some Haskell lover is probably laughing and sticking > their nose up at this entire conversation.

Haha, I'm actually also a Haskell programmer. My top 3 is Ruby, Haskell, C# ;) I do Ruby and CoffeeScript for a living, build games in C# as a hobby and am building a C compiler in Haskell as my secret plot to take over the world. I have a sideproject that's a REST API in Haskell as well, but I'm not 100% convinced yet that Haskell is right for that.

Easy proofs for Haskell superiority: You can compile into a static executable. You can make the typesystem enforce the correctness of your user input parsing (this is crazy effective in JSON Apis, so effective that I now use Grape in Ruby to do sort of the same thing). Its lack of OO and focus on processing data leads to very clean architecture. Its level of abstraction is so crazy that they can actually swap out their entire I/O system for another one without changing any application interfaces, this one blew my mind, it's the change that makes GHC 7.8 run the Warp webserver twice as fast. They actually changed it so the 'fork' system call does not actually spawn a new thread, it spawns a fiber that's run in an event loop type system, and changed all the I/O functions to use asynchronous I/O on that event loop. All of this without changing a line in Warp, they just transparently made every traditional Haskell use modern I/O principles. Academics man, they're smart ;)

C# is cool because it manages to stay clean, fast and structured even though it's super powerful and implements almost every paradigm known to man. It's a statically typed compiled language with near native performance, yet code in it is nearly as succinct as Ruby. If I'd jump ship from Ruby because of performance reasons, it'd be to C#, not Node.js. Provided it runs smoothly on linux of course ;)

<comment><USER8> > Haha, I'm actually also a Haskell programmer...building a C compiler in > Haskell as my secret plot to take over the world.

Haha; I got a kick out of reading that. Nice!

> I have a sideproject that's a REST API in Haskell as well, but I'm not 100% > convinced yet that Haskell is right for that.

I'd be interested in what you are finding there. I have been wondering if I should start moving toward Haskell or Erlang/Elixir. So far, I've spend much more time with Erlang and Elixir and I'm liking it.

What has given you grief on the Haskell side?

> Easy proofs for Haskell superiority...

Wow! I had no idea Haskell was so flexible. Perhaps I really should spend a bit more time there. I've never read anywhere else about this level of flexibility in Haskell.

If nothing else, this conversation was well worth it just for that...thanks :)

<comment><USER7> > I have been wondering if I should start moving toward Haskell or > Erlang/Elixir. So far, I've spend much more time with Erlang and Elixir and > I'm liking it.

I wouldn't know about that, I only took a glance at Erlang, didn't really like the syntax but Elixir seems really pretty (Rubyist speaking of course ;)). I'm also a bit put off by how Erlang has distributedness integrated in its language, I didn't really try it out so take this with a grain of salt, but I have the feeling that it makes it more of a domain specific language, and it perhaps would be in the way of generic programming. I also had to deal a lot with a misbehaving RabbitMQ at work, so I might have channeled my incompetence into a opinion of Erlang :P

> What has given you grief on the Haskell side?

Well, both web projects I did using the Scotty framework, which I adore. The first was a web adaptation of a school project, you can take a look here[0], I like that a lot. But the second project was a docker container provisioning tool, and it had to do a bunch of stream processing and such. It's not that the libraries are bad, but there's a lot of research being done and there's 5 different popular I/O stream libraries, with various amounts of super high level abstractions, it just slowed me down a lot having to research all of it and dealing with some really high level Haskell.

That's one down side of Haskell. There's an easy way to do things, with nice pure functions and a I/O monad here and there. And there's the hard way of Haskell with monad transformers and generic type classes and what have you. You can easily avoid the hard stuff, but if you get sucked in you'll feel like a total dumbass and it'll cost you time and motivation :P

> If nothing else, this conversation was well worth it just for that...thanks > :)

No problem, thanks for making me back up my ludicrous opinions ;)

0] [https://github.com/tinco/Ergo/blob/master/scotty.hs](https://github.com/tinco/Ergo/blob/master/scotty.hs)

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> As someone who's done the bulk of the work for Action Cable, I wanted to clear the confusion re: cable and eventmachine. Cable is currently using EventMachine because it uses faye-websocket for dealing with websockets. And Faye is one of the very few well maintained ruby library dealing with websockets.

And in fact, Action Cable uses Celluloid threadpool to run all the application code in threads. So the model is a combination of EventMachine + Threads.

There's absolutely no reason it can't use Threads + Celluloid all the way. But building on top of Faye was the simplest way to get things up and running.

<comment><USER10> As someone who's tried to use Faye and EventMachine (separately) back in the Ruby 1.9.3 days: Have they stabilized enough to be used for anything?

My memory of them is rather horrible.

Memory leaks, segmentation faults(!) and obscure deadlocks eventually made me scratch EventMachine from the list of things I'd ever want to touch again.

And Faye, well, I don't think I even got it fully running at the time. I still re-call my astonishment when I realized that _neither_ of their two different server-impls at the time would pass even most basic tests (e.g. browser connect/disconnect, redis start/stop) without crashing, locking up or losing messages.

Admittedly it's been a while... Is anyone running Faye in production and can comment?

Edit: Thanks for the feedback. I guess it's time to give Faye a second chance.

<comment><USER9> You can't use Faye without eventmachine. Cable only uses faye-websocket though - [https://github.com/faye/faye-websocket-ruby](https://github.com/faye/faye- websocket-ruby) . Do let me know if you had any negative experiences with that. I don't know about the state of the things in the 1.9.3 days, but faye- websocket has always "just worked" for me.

</comment></comment></comment><comment><USER11> Is this just a really polite, introspective take on (Rails|Ruby) is a Ghetto? I can't point out one really valid critique in this entire rant. While I imagine that you've had enough kool-aid to actually believe the things you said, I think you should probably do a few google searches to find out how many shops are hiring Rails devs versus Clojure or Elixir. You can do more experimenting by seeing who else is actually working those jobs, what kind of professional experience they have, and if you're really lucky figure out what they get paid.

Rails needs websockets, just like years ago when it needed a better way to handle organizing and deploying assets. The modern application demands it, and if you've ever had the pleasure of trying to build a websocket application in Ruby you'd understand why it's actually really exciting that we're going to get the Rails community to build this for all of us.

If you want to be disenchanted about some aspect of Rails then pick the fact that the need for diversity at RailsConf this year has yielded some of the worst presentations I've ever seen (like, literally, the presenter spoke poor/broken english and the Docker oriented talks were about 6 months behind).

Rails moves the way it does and absorbs the ideas it does because they become popular. It's much easier to add a feature that everyone wants, instead of inventing a feature that makes a solved problem that much easier/faster/what- have-you. DHH seems to have to explain this every few years, but go back in time when Rails adopted sprockets and you'll see posts not unlike the one you just wrote.

Realistically, Ruby and Rails jobs are still among the highest paying in the industry. Startups and other more established companies still choose Rails as their platform, and not just for bullshit brochure sites. Certainly there remains a "best tool for the job" mentality but, right now, the alternatives are to: build it yourself, hop on a less "mature" framework -- Pheonix? I don't even know what you pick when you adopt Elixir as your platform language and need to build an API or front end apps but Pheonix won the google -- or choose from one of the popular technologies like Express.js, Laravel(?), or Django. That part of building technology (and business) didn't change, and there are still hundreds of thousands of Ruby and Rails engineers out there.

<comment><USER12> > Startups and other more established companies still choose Rails as their > platform

As far as I can tell, this process has come to a grinding halt in the past few years.

I certainly see established companies ditching Ruby, not so much because of the language or framework itself, but because of the community that only seems to be able to solve problems "the Rails way", even if that's far from the most appropriate architectural solution.

It's shocking how many Ruby developers are architecturally ignorant about anything not applied by Rails, and it's biting many companies in the ass.

<comment><USER13> Frankly, I'm surprised anyone would still make comments like yours after all these years. Comments like this probably peaked in 2008-2009 ("Rails can't scale" was even earlier) after the zed shaw article and there was a bunch of hype about everyone supposedly moving to Django and how Rails was supposedly dead, yet that didn't happen then, or any of the other times.

The reality is that lots of companies have been and continue to be created around Rails applications. An AngelList job search focused on server-side technologies currently returns 1267 startup results for "rails" while "node.js" returns 832, "node" returns 854, "django" 434, "python" 1461, "flask" 69, "go" 441, "php" 1192, and "Java" 3163.

JavaScript has become bigger, and it hasn't killed Rails on the server. Java remains huge, and it hasn't killed Rails. Python, Django, and Rails have roughly the same relationship as they did back in 2009.

A lot of very smart people who have extensive experience with many technologies choose Rails for new projects for very good reasons, this has been the case for the 10 years people like you have been making the same FUD- filled comments, and it will likely continue to the be the case for some time.

<comment><USER14> PHP -> Rails -> Node

<comment><USER13> That's what everyone predicted half a decade ago, yet it hasn't happened, not even the PHP death part. The relationships between these technologies have not really changed dramatically for the past 10 years. For example:

[http://www.indeed.com/jobtrends?q=php%2C+javascript%2C+ruby%...](http://www.indeed.com/jobtrends?q=php%2C+javascript%2C+ruby%2C+python&l=)

[http://www.indeed.com/jobtrends?q=php%2C+node.js%2C+ruby%2C+...](http://www.indeed.com/jobtrends?q=php%2C+node.js%2C+ruby%2C+python&l=)

<comment><USER15> As a brand new Rails developer/web developer altogether, I'm an outsider looking. But it feels to me the chants of "Rails is doomed" mirror that of "PHP is doomed". Yet as you state (and show in your links) PHP is still very healthy and nowhere near death. Sure it might not be the hottest thing on the block, but really JS won't remain the hottest thing on the block in 20 years either, but JS won't die. Neither will Rails. Rails might not the new scorching hotness that it was in 2006, but it's still plenty hot. Rails has quite a bit of life left in it.

</comment></comment></comment></comment></comment></comment><comment><USER16> Websockets isn't really HTTP and so it doesn't really conform to the request/response model in HTTP that is centered around retrieving document objects.

Most web service implementations, including Rails, are built around that paradigm - they get a request for a document, they return it, then they can forget about it (stateless) and move on to serving subsequent document requests, which are likely to be entirely unrelated to the first request. The Rack framework that connects Rails to webservers like Unicorn is just a thin (pun not intended) abstraction on top of that.

Websockets, on the other hand, is a clever way to upgrade (or rather downgrade) an HTTP connection to its lower-layer communication channel, the TCP socket. Once you escape the document-oriented confines of HTTP, the kind of server you need changes because the concurrency model could be entirely different. If you expect a long-running communication channel with a client, a forking webserver like Unicorn is going to have scalability limits (as you'll need a process per connection), and you're going to have a lot of Rails code in memory that has no use whatsoever.

So I wouldn't expect that Rails would be very useful for a websocket service. And I wouldn't fret about it either :) Different protocols often require different services.

<comment><USER17> You don't need to go as far as websocket to leave the stateless world: Server- Sent Events and all its cousings (Comet, chunked transfer encoding, even long polling ...) all need to keep a connection open for an unknown amount of time and then send data back to the client. Is Rails discouraged for such use cases ?

<comment><USER16> If you could run Rails in an event-driven webserver, it might be usable with persistent connections. Otherwise you'll need a whole lotta memory for all those workers that'll be sitting around doing nothing most of the time.

<comment><USER18> in other words: "unicorns considered harmful"

</comment></comment></comment></comment><comment><USER19> For those wondering what the alternatives to Rails are these days, I highly recommend checking out Elixir and the Phoenix framework.

[http://elixir-lang.org/](http://elixir-lang.org/) [http://www.phoenixframework.org/](http://www.phoenixframework.org/)

<comment><USER20> I used Phoenix for a small project last September, not much more than a toy but anyway...

Pros: websocket support is good, the developers are friendly and answer questions, the app is faster than what I'm used to with Rails.

Neutral: Elixir looks like Ruby but it's very different. Be prepared to learn everything from scratch. You need also to know a little Erlang and the OTP framework to be able to use some useful library functions. OTP is a world on its own.

Cons: the tooling is very immature, probably like the one for Rails at the time of the 1.x releases. Be prepared to write many things by hand instead of requiring gem_x and automagically get functionality for free. This is going to slow down developement, increase costs and possibly get you outbid from competitors. Nevertheless it could be OK for internal projects used to get familiar with the framework.

<comment><USER21> We've come a long way since September, so please check again. I am outlining our 1.0 remaining milestones Friday at ElixirConfEU. We should see 1.0 in a few months

</comment></comment></comment><comment><USER22> No, Rails isn't great for web socket kinds of things, but if it were me, I'd just use something else for that, and Rails for the main site. It's still one of the best things out there for quickly iterating, and yet still maintaining some structure and discipline, from what I've seen.

<comment><AUTHOR> Agreed. I was fine with Railsconf focus last year of being "rock solid". Rails is still the best at what it does thanks to its community.

However, Rails 5 is moving to a direction that goes against the abstractions and platform it runs on. If I don't care about this, now I have even more code and dependencies in my Rails apps. On the other hand, if that is becoming the sanctioned way of building apps, I would rather do it elsewhere. To me it is a lose-lose situation.

<comment><USER18> I'm pretty sure "ActionCable" will be optional, as for example "ActiveResource" were

</comment></comment></comment><comment><USER23> My last startup used Node.js + Angular + Postgres, which was great for supporting multiple single page applications and websockets.

With my current startup (a healthcare marketplace where we have to support older browsers), we chose Rails as the best and most mature way to provide server-rendered pages.

I think it's great to try to extend Rails to provide a credible websockets approach, but it will always be difficult because the biggest strength of Rails is the incredible ecosystem of gems. However, all of that existing code is written as blocking, rather than asynchronously like Node and some newer frameworks.

Nevertheless, the Rails ecosystem remains a hotbed of innovation as well as a very warm and welcoming place for both new and experienced programmers.

Rails has not been the new hotness since at least the time Node rolled around. But that's a long way from an existential crisis.

</comment><comment><USER24> A slight tangent, but as a lover of rails and a user of websockets, I can't recommend Tubesock[0] highly enough. I think regardless of your opinion on event machine, Tubesock is a better engineering match for rails, than websocket-rails. Hopefully, the websocket support will be a standard in the future, as opposed to an afterthought for rails, but until that point, I'll keep recommending Tubesock!

[0] [https://github.com/ngauthier/tubesock](https://github.com/ngauthier/tubesock)

</comment><comment><USER25> In web framework terms, Rails is old. When it was created single-page applications weren't on anyone's radar, APIs were extremely uncommon, and websockets hadn't been invented. It's natural to expect some pain try to adapt new paradigms into the old model. Whether this pain is worth it is up to the individual to decide. My web applications are almost always pure client-side these days, so Rails is not something I often turn to.

<comment><USER26> Re "In web framework terms, Rails is old"

Oh how I love that! I would rather build my business on something old and well testet then something new and shiny.

<comment><USER27> would you move to java? that's older and even less shiny.

<comment><USER26> I would, if the technology solved the problem, the workflow fitted our org, the cost of running it in production fitted our budget etc.

</comment></comment></comment></comment><comment><USER28> I understand that there's not quite the same consistent 'theme' this year, but I'm not sure that's concordant with developers who are using Rails 'abandoning' it or anything like that.

It's true that real-time operations like websockets are a total pain in the arse with Rails. Nobody's yet figured out an optimal solution for that sort of thing, and maybe ActionCable is a good solution.

The thing is that while some demands on the web stack have changed, a lot of it is still pretty similar. We have HTTP requests, and HTML, and assets, and databases. It might turn out that Rails can also perform some other tasks that require realtime operation. Or maybe it won't be able to, and we'll be able to use some other tools.

Ultimately, we're still using Rails for all of our new web apps. We've tried loads of different toolsets, but haven't found an alternative that's compelling enough to bother. So YMMV, but the fact that Rails is maybe a bit less exciting that newer frameworks doesn't mean it's not great to use any more.

</comment><comment><USER29> The Rails team, including DHH, owes us nothing. They aren't required to give us a framework of our choosing, they're the ones building it! Just like we don't owe anything to Rails!

DHH uses Rails for Basecamp, so it makes sense that he'll lead the project towards the goals of BC.

</comment><comment><USER30> After trying Clojure(and Luminus) several times over the past year I don't think it would be my go to for things that Rails is tackling. On a side note writing Clojure gave me a little anxiety so I'm trying to hold back on it for now.

After working in this stuff for a while I just use the right tool for the right job. Most of the time Rails is that tool and it allows you to just get stuff done. Sometimes Node is the right tool, or Python.

I think the new Turbolinks stuff is pretty interesting(and useful) although it doesn't help me with forms, and that's the thing I'm usually using React or Angular for these days. Angular may get crap but it's actually really good at forms.

<comment><USER18> I believe the right balance with turbolinks is a mix of React for interactive animated stuffs, graphs, etc, and turbolinks to render stuff that is better generated server side, or to push json data (and then bind it to your react component)

</comment></comment><comment><USER31> The OP is talking about Elixir/Clojure as alternatives. I really liked Elixir's built in Actor like system, Ruby like syntax and the fact it runs on the Erlang VM is very interesting.

I was always wondering why Ruby developers who looked for an alternative didn't move to Scala / Play ecosystem, Scala always seemed to me more like "typed Ruby" than a "better java" or "mediocre Haskell".

But after skimming elixir's getting started docs, I think I know why. Elixir seems to have much more "Ruby like" syntax, it's not running on the JVM, and it's dynamic.

But still I wonder how much the Ruby / Rails community is aware of Scala / Play framework / Akka / Akka-http (formerly spary) as a possible comfortable alternatives to Ruby / Rails / Elixir's actor system / Ruby API?

Play framework knowingly (and admittedly, giving all due credit) borrows a lot from Rails. and I am amazed how Ruby and Scala have more similarities than Scala and Java, yet people still link Scala with Java much more than with anything else.

I think the Scala ecosystem will benefit a lot if there was even a small stream of Rails contributors that also do Scala on the side. I think what makes Rails and Ruby so great is the amazing community and open source culture behind it. As a Scala fan, I can't be but a little gelous...

</comment><comment><USER32> I somehow got stuck upgrading from Rails 3 to Rails 4. Nightmare...

I've been through 5 Rails upgrades. Rails 2 to Rails 3 was a nightmare...

Rails does not scale well with complexity & is a pain to maintain...

There are a number of reasons for that. Rails started off favoring syntactic sugar over architectural integrity. They are gradually iterating toward a solid architecture. However, that required some significant api changes, which causes upgrade pain.

Also, the prevalence of monkey-patching (largely due to an unsound & overly complicated architecture), exasperated these issues.

Rails architecture is still overly complicated & misses the mark, IMO.

DHH's infamous "golden path" direction put the blame on the developers, when Rails itself had some major architectural flaws.

Rails Routes + Controllers are horrible. Why do we want an extra level of indirection? Sinatra/Express.js are easier to reason about RESTfully.

Asset Pipeline is horrible. The Node.js ecosystem (i.e. browserify) is much better. Client/Server separation of architecture scales in complexity more readily than the Rails monolith monstrosity.

I'm kindof bummed that Rails became so big. The "Rails Way", while being a step forward from what was there before, became too prevalent; sucking up too much mindshare; inhibiting further evolution of the broader ecosystem.

It's time we let Rails slowly die. There are many better libraries & frameworks out there.

</comment><comment><USER33> I never hear any production app with elixir in Berlin, some noise with clojure, but some people move from node.js to Golang. As for rails, people are happy. Sometines I think is super cool to rant rails :)

<comment><USER34> As a ruby/js dev moving to Berlin in September, that's good to hear. I'm interested in talking to folks who might be more familiar with the scene there. If you know anyone who'd be good to reach out to, let me know!

<comment><USER33> enroll here: [http://berlin.onruby.de/](http://berlin.onruby.de/)

</comment></comment></comment><comment><USER35> For those of you who would like to watch the keynote: [https://www.youtube.com/watch?v=oMlX9i9Icno](https://www.youtube.com/watch?v=oMlX9i9Icno)

</comment><comment><USER36> To those unsure about Eventmachine

[https://github.com/eventmachine/eventmachine/blob/master/CHA...](https://github.com/eventmachine/eventmachine/blob/master/CHANGELOG.md)

IT seems to have much more fix and features in recent months then its entire life span.

And as DHH pointed out on twitter

Clearing up misconception re: Action Cable: EventMachine only used for connection handling, threads for channel code. No block restrictions.

</comment><comment><USER37> > as developers flock to new technologies like Clojure and Elixir

Is that really the case? Clojure and Elixir?

<comment><USER38> I know people who move from Ruby/Rails to Golang. No people I know move from Ruby/Rails to Clojure and Elixir

<comment><AUTHOR> This is interesting. I hear most about Elixir, with Clojure coming second. As I said above though, those are just examples, if I knew for a certain what is next, I would be learning it already.

<comment><USER33> In Berlin, Munchen people chat about elixir when they compare some pharma, alcohol industry. As for clojure, only small projects. as for the hype, let's say go. But, majority choose, php :)

</comment></comment></comment></comment><comment><USER12> The almost complete dominance of the Rails in the Ruby ecosystem seems incredibly unhealthy to me.

IMO, Rails should do what Rails is good at and was designed for (simple, monolithic, server-side heavy web applications), and there should be dozens of other successful Ruby frameworks with other philosophies.

Rails was supposed to be the breakthrough for Ruby, but instead the near monopoly of Rails is suffocating it.

<comment><USER39> It's especially jarring when the Ruby world - which originally revolved around "Matz is nice so we are nice", emphasizing developer happiness, being a more readable Perl, etc. - now revolves around the "Rails way" as if all other ways are wrong.

If I wanted a "There's Only One Way To Do It(TM)" world, I'd be programming in Python, not Ruby.

</comment></comment><comment><USER40> I also see Basecamp as having jumped the shark.

Highrise was a palatable "cheap and cheerful" CRM system but they decided to stop investing in it.

The appeal of Basecamp is that it is a simple product and there isn't anything 40 developers can do to make it more simple.

</comment><comment><USER41> Could this be formalized? Have odd releases as "feature" releases and even releases as Snow Leopard-style "consolidation" releases?

</comment><comment><USER42> People use Rails to build websocket hubs?

</comment><comment><USER43> Forget rails. Move to Django ;)

<comment><USER22> Django has basically the same architecture as Rails, so it's really in the same boat from that point of view.

<comment><USER44> Minus the security issues.

<comment><USER45> And equally bad at concurrency.

<comment><USER46> I don't buy this, having written and dealt with a lot of concurrent Django apps - I think people read something about the GIL often, and don't understand what the articles are really meaning.

Basically Django is usually fronted with mod_wsgi and you use celery for backend tasks. The multiple requests part are dealt with because the web server pre-forks, and it's just fine with it.

I think Django's problem is it moves very slowly, and mostly just that. The ORM isn't awesome, but it's workable. You can also choose to not use parts of it, like templates, and that's common in single-page apps.

<comment><USER47> It's speeding up development lately, 1.8 came out rather fast but it seems like the Django team likes to have ~1 year development cycle.

<comment><USER43> Exactly, the development pace has been amazing and it is going in the right direction.</comment></comment></comment></comment></comment></comment></comment>


Legal Support for Substack Writers - <AUTHOR> https://on.substack.com/p/legal-support-for-substack-writers <comment><USER2> Good for Substack! Drawing a line in the sand like this makes me want to support their cause.

I get excited when I read stories about companies or groups standing up against patent trolls. Reading this made me feel a similar sort of excitement. Of course, it will be challenging for Substack to determine which actions are "bad-faith" and which are justified. It's probably too much to expect for them to stand up for all points of view on their platform that meet their terms of use.

[edit: adding a question]

Can anyone recommend good writing on Substack to follow?

<comment><USER3> > Can anyone recommend good writing on Substack to follow?

[https://nathantankus.substack.com/](https://nathantankus.substack.com/)

[https://oversharing.substack.com/](https://oversharing.substack.com/)

[https://mattstoller.substack.com/](https://mattstoller.substack.com/)

[https://sirota.substack.com/](https://sirota.substack.com/)

[https://gwern.substack.com/](https://gwern.substack.com/)

</comment></comment><comment><USER4> That's actually quite impressive, unlike the exploitative dumpster fire that is Medium.

</comment><comment><USER5> This is very interesting. A decentralized media platform company.

<comment><USER6> What's decentralised about it? You can't even use your own domain yet.</comment></comment>


5 great business books to read - <AUTHOR> http://business.rediff.com/special/2009/oct/30/five-great-business-books-to-read.htm <comment><USER2> I think that list misses one very important book: How to Win Friends and Influence People, by Dale Carnegie. The people who are most successful in business understand people, and that's what this book teaches. Understanding people and being good at interacting with people will take you a lot further in business than reading about why our economy failed.</comment>


American Healthcare system micro-aggressions, or death by a thousand cuts - <AUTHOR> https://medium.com/@mrannedev/american-healthcare-system-micro-aggressions-or-death-by-a-thousand-cuts-ea99bba10d02#.gy7bywv34 <comment><USER2> Health "insurance" in general is a ridiculous concept. Insurance is supposed to flatten the cost of undertaking risky endeavors. Maybe there should be injury insurance for athletes, and STD insurance for sex workers. But the average human who jacks into the matrix for 18 hours/day is not taking any undue risk and should not need health insurance to get treatment for their cancer any more than they need murder insurance to pay for the investigation of their own death.

Capitalism is as faulty an ideology as any. Some things should not be for- profit. Healthcare is one of them.

<comment><USER3> Health insurance originally _was_ for managing risk -- it only covered emergency healthcare like being in an accident or having a heart attack. But now we want healtchcare to cover everyday costs, including routine doctor's visits and daily medication like antidepressants or birth control.

 _Of course_ full coverage health insurance is going to be expensive -- if people are using it every month then it no longer distributes the occassional cost of an accident, but rather distributes the daily healthcare costs for routine care.

</comment></comment><comment><USER4> I'm really beginning to think that one potentially good catalyst for change would be if we could get a law prohibiting companies from providing health benefits.

Even if companies responded by increasing monetary compensation accordingly (unlikely!), the impact of every middle and upper class American having to go out and buy crappy health insurance, and actually hand over the cash for it themselves, might change a few minds about how we organize healthcare in this country.

<comment><USER5> Without also reforming healthcare up front, that would move a lot more people into the "y'know what, I'm better off without health insurance" bucket, which would accelerate breakdown of the health insurance market.

But I don't see why that would create the political will for anything to get fixed, given that it isn't being fixed already.

</comment></comment><comment><USER6> I'm a German that used to live in the USA for a while. I worked as an engineer in the US, with what would be considered "decent" insurance, and it was still crappy. You couldn't pay me enough to go back.</comment>


Show HN: Ambient.fyi – instant ambient music powered by Archive.org - <AUTHOR> https://www.ambient.fyi <comment><USER2> Nice collection for meditation!</comment>


Show HN: I've made extension with live soccer scores in new tab - <AUTHOR> https://chrome.google.com/webstore/detail/efpkmgeabjpobmppofgnlfihgkinjlcb <comment><AUTHOR> Hi, HN community, I'm creator of this extension, want hear some feedback, thank you.</comment>


Ask HN: Drupal or from Scratch - <AUTHOR>

I've been using PHP for many years and I consider myself at least competent. I have worked with many framework and understand the learning curve they come with.
However, I have a client that wants me to work on a project. It uses Drupal. It was recommended by his PM and the team that first started building the website for him.
Now he parted from the team and wants me to continue the development. I feel stupid for not understanding Drupal at all. I read documentations, tutorials, watched videos and it still feels strange to use it.
This project is not even a blog or article driven. Making the smallest changes is a hassle. I managed to build a Prototype using an MVC framework in a couple of days, much easier.
I have tried to tell the client that it is best to leave Drupal behind, but Googling comments about Drupal and reviews only yield more reasons to use it.
Am I the only person thinking using Drupal for a non-CMS project is more work that needs to be? <comment><USER2> No blog/cms. No Drupal.

Actually Drupal feels ancient and archaic at this point. I wouldn't recommend it for anything.

If it was strictly a blog I would use Wordpress.

Plus using a framework like Drupal or even Wordpress you're opening yourself up to lots of security issues.

For any type of web application beyond a blog that is PHP based I would recommend going with Laravel.

Not only is it a great framework there are lots of tools to make it easy to use.

Develop locally on Homestead (Vagrant) [http://laravel.com/docs/5.1/homestead](http://laravel.com/docs/5.1/homestead)

Deploy easily to Digital Ocean or AWS ($10/mo but will save your hours and hours of time) [https://forge.laravel.com/](https://forge.laravel.com/)

Critical App?Deploy with no downtime [https://envoyer.io/](https://envoyer.io/)

Laravel Spark (SaaS out of the box, Coming Soon) [https://www.youtube.com/watch?v=uOU_N8PNOD8](https://www.youtube.com/watch?v=uOU_N8PNOD8)

Laracasts [http://laracasts.com](http://laracasts.com) Great place to learn Laravel.

At least checkout Laravel before committing to doing this project in Drupal.

I would charge 3x if he insists on Drupal. = 0

Good luck with your project.

(btw, I'm just a fan of Laravel.)

</comment><comment><USER3> If Drupal can support the requirements of your project with minimal changes, absolutely go for it. Otherwise, stay away. Drupal can in theory be used to build a wide variety of full fledged applications, but my experience says that this is the wrong hammer for most nails.

I faced the same choice a few years back, in Drupal 5 days. Ended up going with Drupal for speed of development, would not have made the same choice if I had to do it all over again. Built a fully featured social network by stitching together a bunch of modules and writing a hell of a lot glue code as well as code to override default module functionalities.

In the end, I did build it faster than I would have from scratch, but ended up with an unmaintainable mess of custom code. Ramp up was brutal (I knew nothing about Drupal when I started) and you really need to understand how the core and module architecture works in order to make any meaningful customizations. The prospect of upgrading to Drupal 6 was so daunting that I never did it and the project ended up languishing and eventually dying.

Perhaps things got better since then, but I have a hard imagining that to be case.

</comment><comment><USER4> Don't focus on criticism, focus on making a very clear value proposition why a change is necessary. For anything. Offering people value is a lot more persuasive than telling why you're right, be it CMS / staffing changes / anything.

That said, I use Drupal quite a lot. For content intensive stuff, it is simply my hammer to seeing a nail.

Re-inventing a CMS seems like a bad idea also. Using a CMS for a non-CMS project also seems like a bad idea. Perhaps enquire with the PM why they suggested Drupal/a CMS? There might be an angle in the project's direction or specification you're missing.

</comment><comment><USER5> I have used a drupal based database, while they were able to do job it is severely limited in functionality by the platform. Its now a drupal version or two behind and would be better to shift platforms than to re-factor for new drupal.

If its something serious with data I suggest use more serious tools.

Second thought, can you demonstrate why it would be better to move away from drupal, such as development could be faster, capability would be improved, or that in some way drupal would be bad in the long term. With an alternative in mind maybe you would have better luck.

</comment><comment><USER6> I am a little biased because I have been using Drupal for a couple of years and recently started building very complex web applications using MVC frameworks. If you are building a website for content purposes, please use a proper CMS like Drupal. It is pretty well written and very properly documented.

<comment><USER7> I've very recently used Drupal for the first time on a project where using Drupal was a requirement from the client. The reason they wanted Drupal was because their internal dev. team was accustomed to it so if they needed to do work on it later, they could.

I have to say that it's a terrible framework to get into. I found it extremely difficult to find proper documentation on how to achieve (simple?) tasks and how to properly link things together. I've now only scratched the surface of it after completing the project in ~six weeks but am kind of dreading having to work with it again.

I think it could improve usability drastically by updating their own website and documentation. The only things I could find when getting stuck were questions of people being stuck on the same thing, or on a similar thing. Actual answers on this were very difficult to find and mostly took me a substantial amount of time of digging through the code.

<comment><USER8> Care to provide some examples of the issues on the simple tasks you are having?</comment></comment></comment>


Let me get this straight, NSA is not smart enough without backdoors in an OS - <AUTHOR>

<comment><USER2> I'd say it isn't about being smart enough, its about making it simple for them and to potentially provide more of a real hook instead of a hack at a later date.

I could be totally wrong, but it seems this is about speed and convenience and a way to try and thwart others who may be equally as smart whom have secured their machines. If you make it vulnerable by placing a hook into the OS etc, makes it potentially harder for someone to get around unless you just stay off net.</comment>


Like someone? Crushify helps you find out if they like you too. - <AUTHOR> http://crushify.org/c

<comment><USER2> Been thinking about building something like this for a while.

<comment><USER3> Either this idea was made years ago or I had the idea years ago, I'm pretty sure the former. (Can't really remember, but it's very familiar to me, think I can vaguely remember visiting a site like this in the past.)

Personally I can't imagine ever using something like this, not sure if that's because the concept is flawed, or because of my personality, or perhaps it's simply a service aimed at school crushes rather than adult life. But would be interested to hear from someone who thinks the opposite.

<comment><USER4> There were dozens of these in Dot Com Bubble #1. They all tank, because they turn into scams, due to the inherent information asymmetry.

</comment></comment></comment><comment><USER5> Take a look at this guys submission history. Flagged.</comment>


Yahoo Is Down - <AUTHOR> https://yahoo.com <comment><USER2> But also Aol, Huffington Post, Engadget, Techcrunch... I'm hearing it's because their DNS is down, and I think all of Oath's online properties.

</comment><comment><USER3> Yahoo.com DNS servers are currently timing out all requests from where I am (for the last 15mins at least).</comment>


Expa Labs? Does anyone know anything about Garrett Camp's accelerator? - <AUTHOR> Was curious if anyone knows anyone who has actually been through this program and whether startups really spend time working with Garrett himself? <comment><USER2> My co-founder and I also went through this program building our company, Chalet. It was a fantastic experience. Everyone at Expa is smart, talented and very interested in helping the Labs companies succeed in whatever they can; similar to how @mikeschmidt describes, it's almost like they are members of your team.

You get a lot of access to and support from the partners. During our first month in the program, at a meeting with Garrett, we actually got some of the best advice and directional support we'd ever received. Without just that meeting, our company would not be the same as it is today.

My co-founder, Michelle Cunningham, also wrote up a short blog post about our experience with the program: [https://blog.withchalet.com/chalet-expa-our- take-on-labs-b32...](https://blog.withchalet.com/chalet-expa-our-take-on- labs-b32e9a4af342#.p37yw6xyo)

</comment><comment><USER3> My co-founder, @navied and I were in the first batch with our startup, Dovetale. In a nutshell I'd say it's less "accelerator" and "incubator" and more studio with partners as part time employees helping you build. It's a very unique experience. I wrote a piece here that might be helpful.

[https://medium.com/@mikeschmidt/my-expa-labs- experience-447f...](https://medium.com/@mikeschmidt/my-expa-labs- experience-447f7389b737#.nkxdqa9rs)

We spent time with Garret + the other partners very often. Each partner has different interests and is valuable in different ways. Since you work out of the same space you see them all the time. Working at Expa HQ definitely has other advantages but this is high on my list :)</comment>


Show HN: A federated social network, built on Ethereum and IPFS - <AUTHOR> https://numaverse.com/ <comment><USER2> Hey, that's amazing! I think that having an AP server that stores data in IPFS is really cool. Where did the idea come from?

</comment><comment><AUTHOR> Hey HN!

I'm really excited to share what I've been working on for the past few months. It's a social network, built on distributed technologies, with support for federation with Mastodon and other compatible networks.

I don't want to throw around too many buzzwords, so let me just get to the point. There is a smart contract on Ethereum that keeps track of references to all the network's data. The only data actuall passed to the contract are IPFS hashes. Those IPFS objects are JSON files that contain the actual information that describes users, messages, follows, favorites, etc. If you view a message page[1], you can scroll down and see the raw details like the IPFS hash, actual IPFS file, and transaction information for that message.

Because all the data is stored in a distributed fasion, that means you're not reliant on any central server. The server is open source[2], so anyone can run their own 'gateway' to the network, or build their own on top of it. You could even run it locally. Either way, you get the same experience, and since you control your private keys, you can take your account wherever you want.

The app batches all of your actions into a single transaction that only costs a few cents. You can sign up, post messages, etc, without having to spend or own any Ethereum. When you want to actually post it on the blockchain, you commit your batch. Until then, your content is cached on the server, and only other folks on that server can view it. Still, I get not wanting to go through the whole hassle of buying Ether, sending it to an account, and testing it out on some new thing. I've setup a staging server[3] that connects to the 'Ropsten' test network, and you can get free ether from a faucet to use.

It's also built it so that the 'gateway' server is ActivityPub compliant, which means you can follow and be followed by other folks in the fediverse. You can have people follow you from other networks, though, by having them search for @firstname.lastname@example.com . To follow people on other networks, search for their 'fediverse handle' in the search bar, i.e. @email@example.com.

It's just a start, but I've loved this project because I've never learned more than while working on this. I'm really excited for what will come from these technologies. One cool feature coming up will be support for Token Curated Registries, which are a form of a reputation network that's tied to a blockchain. Stuff like that will be really interesting in the context of social networks.

[1] - [https://numaverse.com/messages/4](https://numaverse.com/messages/4)

[2] - [https://github.com/numaverse/numaverse- gateway](https://github.com/numaverse/numaverse-gateway)

[3] - [https://ropsten.numaverse.com/](https://ropsten.numaverse.com/)

<comment><USER3> Interesting stuff. Given that it's AP-compliant, does that mean messages from the rest of the fediverse are not stored on the blockchain?

Also, can Numa be used like a regular fediverse client, without spending Ether or storing anything on the Blockchain?</comment></comment>