So you think you know C? - <AUTHOR> https://hackernoon.com/so-you-think-you-know-c-8d4e2cd6f6a6 <comment><USER2> If you write a quiz like this, and "Don't Know" is an answer but "Undefined Behavior" and "Implementation-Dependent" are left off, you're doing it wrong.

<comment><USER3> Indeed. The quiz doesn't start with "What does the ANSI C standard guarantee about..." It says "So you think you know C." C is a cross-platform assembly language. I use it when I need to code to the metal. I know exactly how it will behave in most of those scenarios.

I understand, in abstract, I might be on an EBCDIC system, and things will be different. But that's not the reality of C. C isn't just a formal specification.

I spent a while on 1, thinking about how my compiler would handle that. 2 I was 90% confident about. 3 and 4 I was 100% confident about.

<comment><USER4> > C isn't just a formal specification

No, C IS just a formal specification.

What you are talking about is C on your particular compiler on your particular platform. If you are writing C code just to be used for that scenario then you can use all of the implementation understanding you want.

If, however, you want to write C that will have consistent behaviour across multiple compilers and multiple platforms, then you need to limit yourself to the behaviours that the standard guarantees. Otherwise the compiler behaviour may change and your program behaviour will change.

Even between different versions of the same compiler implementation defined behaviour can change (although assumptions about sizes probably won't).

<comment><USER5> A lot of the implementation defined behavior can be ensured with static assertions (either via new-fangled C11 _Static_assert or via the old fashioned negative length array hack), particularly WRT sizes.

<comment><USER4> Absolutely, and that's a big step forward to writing code that will silently do bad things on a different platform. I use that technique on my current project to assert a load of things that I know are true.

It doesn't get you as far as the ideal goal which is to write code that will silently _work_ on another platform. Static asserts mean that you then have to go and write more code when they happen.

</comment></comment></comment></comment></comment><comment><USER6> This is pretty silly. Being fluent in C has not much at all to do with language quirks. Since (I assume) the 1980s, the comp.lang.c crowd has been reminding us that compilers are fundamentally unknowable and that sizeof(char) could very well be a random walk averaging 1.35. Meanwhile, in the real world, network and kernel programmers have been using some variant of u_int32_t since forever to ensure that they can parse network packets and driver data structures by copying or even casting things into structs.

Also, why would anyone write ' ' * 13? For most of these questions, if your first instinct is "that doesn't look like good C code", _your answer is better than the "right" answer_.

<comment><USER7> Actually, since C99, sizeof char is defined to be 1 (byte). The number of bits in a byte is implementation-defined.

However, "it's implementation specific and it's most probably this, or that if you use such and such a compiler flag" is different from "I don't know".

As a rule of thumb, don't assume things about C's abstractions, read the standard instead, or ask friendly humans who do if they check out.

<comment><USER8> > read the standard

Casey Muratori, who's a better C programmer than me, is of the opinion that you should check your compiler's behavior rather than read standards.

(Not that you should take his word as gospel, I don't fully agree myself, but it's worth considering.)

<comment><USER9> > you should check your compiler's behavior

There is one thing I have noticed in gcc and clang which is done against the standards: The sign of bit sized int in a struct.

eg: In a struct with member 'int a:8', The standard says that 'a' can be signed or unsigned (based on the machines default of the sign of char). But In gcc and clang, this is signed always regardless of the machine.

<comment><USER10> > eg: In a struct with member 'int a:8', The standard says that 'a' can be > signed or unsigned (based on the machines default of the sign of char). But > In gcc and clang, this is signed always regardless of the machine.

Wait, are you saying gcc/clang's behaviour is permitted by the standard, or not?

<comment><USER9> > Wait, are you saying gcc/clang's behaviour is permitted by the standard, or > not?

It's permitted. The same way as a char can be signed or unsigned: Implementation defined. But in this case, it's always signed regardless of the architecture (against how a char is handled).

From c99 draft (n1570), J.3.9 (Implementation-defined behavior): Whether a ''plain'' int bit-field is treated as a signed int bit-field or as an unsigned int bit-field (6.7.2, 220.127.116.11).

But say, another compiler (ARM compiler) treats this differently [0]: Untill version 5 of the compiler, such an int was unsigned by default. Later versions defaulted to signed (as do gcc/clang).

[0] [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15377.html)

</comment></comment></comment></comment></comment></comment><comment><USER11> I did this test as a break from sitting in front of Keil C51. These questions highlight a very important issue: there are platforms and compilers out there that will bite you in the ass if you try to unconsciously apply what you learned while using gcc.

Under Keil C51, alignment is always 1. This is legal C.

Under Keil C51, int is 16-bit. This is legal C.

Under Keil C51, sizeof(pointer) is anything from 1 to 3. This is an extension, but a very popular one.

Don't assume that just because you can write crash-free code on x86, you "know" C.

<comment><USER12> > Under Keil C51, sizeof(pointer) is anything from 1 to 3. This is an > extension, but a very popular one

I think this is the funniest thing in this all. You might cross all your t's and dot your i's, and you still may trip in a pitfall when your compiler/platform vendor happens to actually diverge from the standard. Such is life with decades old language with at least as many implementations.

<comment><USER11> Such is the price of using C on Harvard machines. It's even more pronounced on '51 as even the smallest $.5 chip has four (!) different address spaces (direct/register ram, indirect ram, xram and code) - and bigger chips have even more as they support memory banking. The real question is: why doesn't C support Harvard architecture natively, without ugly hacks?

</comment></comment></comment><comment><USER13> I'm reminded of an old story about a man trying to fill a job for driving a stage coach. He asks each applicant how close they can drive to the edge of a cliff without going over. The first few applicants brag about being able to right up to the edge. The job goes to the first to respond "I don't know, I try to stay as far away as possible".

</comment><comment><USER14> I sort of understand the point of this post, but I basically disagree with it. From a pedantic perspective, you aren't writing "good C" if your code isn't 100% standards-compliant, but if we applied this same rigor to dynamic languages, no one would get anything done in them. How do you know your Ruby code works? The community has settled on the following solution: because it passes thousands of tests on every aspect of every function. Extending that to C code, your code works if it passes your tests.

Test on every platform and every compiler you support, or it's not going to work. Avoid undefined behavior, sure, that's probably good practice. But there is no need to bend over backwards for compilers from the 90s targeting the AS/400 if you are writing a linux application that only needs to support Ubuntu 16.04. If your only means of avoiding broken behavior is "we're going to try really hard not to do anything undefined or implementation-defined" you will fail. But if you pass your functional tests, your user doesn't care whether you are invoking undefined behavior with every function call.

<comment><USER15> Well I would agree that undefined behaviors are unavoidable. Indeed, if you insert checks into your code to completely rule out UB, that will have a huge impact on performance.

On the other hand, I don't agree passing tests is enough. No matter how many tests you run, you can't guarantee there's no bug in your code. This is important especially when security is a critical requirement.

</comment></comment><comment><USER16> The right answer to all this questions is:

"Nobody in their right mind should use code like this in production".

You should avoid code like this at all cost. If you want to use this code because you feel smarter, you will be creating enormous amount of problems in the future and you are actually dumb.

The way to win the game is not playing it. Specially if you are programming nuclear plants.

If you see this code what you have to do is replace it, not understand it. It works today but when you change the compiler or the architecture 10 years from now, it will be such a huge pain in the ass to find all the bugs and undefined behavior it creates.

<comment><USER17> And the key to not playing this undefined behaviour game is using integers of known size. C has them since C99, so using int, short, char etc. like in the article is reckless and inexcusable.

</comment></comment><comment><USER18> In 2008, I've started to learn C language by solving these amazing puzzles:

[http://www.gowrikumar.com/c/index.php](http://www.gowrikumar.com/c/index.php)

I think this page contains high quality C puzzles.

If you know something similar, let me know, I would love to solve.

<comment><USER9> A note: 'int main()' and 'int main(void)' are different in C (but the same in C++).

Most online puzzles uses the former (I have also seen this in hacker rank), but the standard says that the main function should be defined as void if no argument is accepted (or some implementation defined manner)

<comment><USER19> Yep, we write C++ at work and the technical director loves writing (void) in parameters due to years of habit after writing C. To me it looks redundant (I went straight to C++, skipped C).

</comment></comment></comment><comment><USER20> I don't even know C and I got 100%.

<comment><USER21> See? C is so intuitive : )

</comment></comment><comment><USER22> I know the correct answers to these questions on Linux with an ARM or x86 and on 8-bit AVRs and that's good enough for me.

<comment><USER9> Do you know the value of 'i' after executing the following statements (assume it's written inside the main function):

int i = 0; int j = sizeof (i++);

// Thanks. :-)

<comment><USER23> Zero with great amount of indeedity.

</comment></comment></comment><comment><USER24> Another C quizz, (which I find a little bit more interesting):

 _Will it optimize:_ [http://ridiculousfish.com/blog/posts/will-it- optimize.html](http://ridiculousfish.com/blog/posts/will-it-optimize.html)

edit: it's actually about gcc rather than the standard itself, still pretty interesting though.

</comment><comment><USER25> I don't understand this critique of an outdated version of the language. Let's see questions written in C99 using stdint types. Dealing with integer widths is a non-issue.

Yes, inc/dec operators take extra care. Structure packing requires platform awareness, similar to how endianness can matter for data manipulation.

<comment><USER11> Unfortunately licenses for outdated versions of outdated compilers for outdated versions of an ancient language still sell for 3995€ a seat - I know because I'm using one right now. Nothing beats good old 8051 in terms of price. :)

</comment></comment><comment><USER26> It seems the padding one is wrong for an even simpler reason. You don't know what sizeof(int) is.

</comment><comment><USER27> Real world things in C that may bite you:

(a) char may be signed or unsigned so

      char a, b;
      ...
      short c = (short (a) << 8 | b);

will not work to construct a 16-bit value from two 8-bit values.

(b) NULL is not a useful macro. For example,

      printf ("%p", NULL);

can have unexpected results.

Those things mentioned in the article? Outside of DSPs and GPUs, you can ignore them.

<comment><USER28> Yup, I deal with the unsigned char issue at work all the time, I've got a pile of code with casts to unsigned all over the place due to decoding some legacy data formats. I'm not sure what the cleanest way to fix it is, but I find myself writing nasty stuff like:

        (((short)((unsigned char)a)) << 8)

Which works but goddamn is it ever hard to read. Bracket highlighting makes it just bearable. Fortunately I've abstracted this kind of stuff out as much as possible so I only have it in a few places, but it still bites me in the ass sometimes. Curious if anyone has a cleaner way of expressing this?

<comment><USER27> Definitely use the new stdint.h types[1]. That will make your intent a lot clearer. Also consider creating some macros for all common operations (like creating a uint32_t out of four uint8_t).

[1] [http://en.cppreference.com/w/c/types/integer](http://en.cppreference.com/w/c/types/integer)

</comment></comment></comment><comment><USER29> There is an interesting paper that recently explored the de-facto C standard: Into the Depths of C: Elaborating the De Facto Standards, by Memarian et al. [http://www.cl.cam.ac.uk/~km569/into_the_depths_of_C.pdf](http://www.cl.cam.ac.uk/~km569/into_the_depths_of_C.pdf)

</comment><comment><USER30> We teach people to write proper code, then they get interviewed on the most dumb half-assed code that nobody writes in the real world because we like mental gymnastics

</comment><comment><USER31> IMO, this is actually a fairly good test of thorough C knowledge. All of these issues are regularly described in articles, blogs, forums, HN posts, etc. Anyone who has programmed C for a few years and put in effort to master the language should know this stuff.

</comment><comment><USER32> IMO the real answer is to validate any assumptions by using UBSan wherever possible. Many compilers and many targets are supported.

Even if by some chance half of your C team knows all of the ins and outs, subtle things like this can slip by even when under review.

</comment><comment><USER33> This reminds me of a presentation called "Deep C (and C++)" (2011): [http://www.slideshare.net/olvemaudal/deep-c/](http://www.slideshare.net/olvemaudal/deep-c/)

<comment><USER34> I was about to post something similar, CTLR+F and found this post. :)

"Deep C" illustrates the difference well between people who know C and people who _know C_. A bit of it is language lawyering, but some of it can be practical - although perhaps specific to certain projects or environments.

IMO this sort of knowledge is most practical if you're maintaining legacy software or in specific environments that you would otherwise be making a mistake in. People writing evergreen software or in specific targeted environments don't really need to worry about all these types of "Gotch'ya!".

</comment></comment><comment><USER35> The lack of specified type sizes is something that bit me recently. On pretty much every x86-64 C/C++ compiler, sizeof(long) is 8, except on MSVC where it's 4. Thank goodness for explicitly sized, now-standard types like int64_t.

<comment><USER36> sizeof(long) >= 4

sizeof(int) >= 2

sizeof(long) >= sizeof(int)

That's all you can expect.

<comment><USER37> You literally cannot expect the first two. On word-addressable hardware, you could easily get sizeof(long) = sizeof(int) = 1. This happens on DSPs.

<comment><USER36> Yes. Didn't think about machines where the memory isn't composed of bytes.

The best approach is still to not expect anything.

</comment></comment></comment></comment><comment><USER38> Don't know C. I got all the answers write...do I know C?

<comment><USER39> Yep. You're now a C programmer. Congrats! Linus Torvalds is happily awaiting your first patch to Linux.

</comment></comment><comment><USER40> Sharing data structures in RAM between 64 bit and 32 bit and 16 bit architectures brings this home painfully. Data communications is equivalently plainful, possibly moreso becaude one has no knowledge of the receiver's architecture. Sending multi-byte values between big- and little-endian machines, for example.

The test could also have included questions on things like packing bools and enums into structures. Again critical to get righht when sharing or transmitting structs, or anything bigger than a char.

<comment><USER41> Yep, unfortunately a universal 'Network-Byte_order'[1] stil doesn't exist.

Things like this were especially a pain with industrial network protocols that we used in our applications during the transition from PowerPC to Intel on OS X. All the CFSwapInt16HostToBig() and CFSwapInt16BigToHost() stuff...

And earlier before I learned about '#pragma packed' it took me a while to find out where all these extra zeroes suddenly came from :-D

[1] [https://en.wikipedia.org/wiki/Endianness#Networking](https://en.wikipedia.org/wiki/Endianness#Networking)

</comment></comment><comment><USER42> To all those kvetching about weird C (and by extension, C++) behaviors... what is your alternative for an unmanaged, system level language with broad compiler/library support?

<comment><USER43> We're still fighting to get people to acknowledge that C is a problem. Way too many software engineers are still in denial about that.

D, Rust, and Swift are the only languages I know of that have "systems programming" as a focus.

</comment></comment><comment><USER44> THIS is why C is bad. It's not because there are no classes, and you have to manage your own memory, or because it has unsafe pointers. It's this. And it's the same reason why C++ is awful even before you get to the "++" part. I wish that by now we had a proper ASM abstraction language that allows the programmer to work with the architecture they're programming for, instead of all the "undefined behaviour" we have to deal with since the 70s.

</comment><comment><USER45> How to recognize a terrible quizz in any programming languages?

Simple. It keeps asking code questions about undefined behaviors that MUST NEVER be used in real world programming.

#StandUpAndLeaveTheInterview

</comment><comment><USER21> I knew it was Undefined Behaviour, but I played along and tried to guess what it would return on GCC/Windows/x86/no optimisation, in the assumption that the author is clueless about UB and just ran some tests and did a quiz about it.

</comment><comment><USER46> Would question 4 have a different answer if it was:

      unsigned int i = 16;
      return (((((i >= i) << i) >> i) <= i));

? (I changed `int` to `unsigned int`.)

<comment><USER47> Nope, on 16-bit platforms a 16-bit left shift has a very different result from a 16-bit left shift on a 32 bit platform.

It's basically a question about knowing when you'll get burned by the size of int varying.

<comment><USER46> So?

      (i >= i)                           // 1
      ((i >= i) << i)                    // 0x10000 or 0
      (((i >= i) << i) >> i)             // 1 or 0
      (((((i >= i) << i) >> i) <= i))    // ((0 or 1) <= 16) == 1

Where did I go wrong?

<comment><USER48> > ((i >= i) << i)

UB.

<comment><USER46> Ah, you're right.

      > If the value of the right operand is negative
      > or is greater than or equal to the width of
      > the promoted left operand, the behavior is
      > undefined"

([http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf](http://www.open- std.org/jtc1/sc22/WG14/www/docs/n1570.pdf) \- ISO/IEC 9899:201x (C11 Working Draft N1570): 6.5.7 Bitwise shift operators)

<comment><USER48> Yeah. It seems like something easy to define to me, at least in the case the compiler can recognize the shift is a constant. But that's the standard for you.

</comment></comment></comment></comment></comment></comment><comment><USER49> > And I had to learn it the hard way too.

I'm worried. What blew up?

<comment><USER50> Well, the author is a Ukrainian nuclear engineer. ~

</comment></comment><comment><USER51> Correctly answered all the questions.

I'm not C expert, by far; I only have an instinct that if it's about C and memory layout, I shouldn't rely on my understanding and check it instead. On every architecture I'm targeting.

</comment><comment><USER52> I enjoyed this post. I am curious do any of you have any C-specific blogs that you read regularly? Maybe not exclusively C but predominantly C or mostly C-related?

</comment><comment><USER53> I realized these were trick questions at #5. My answers till then were "well, on gcc on i686, probably ____". The trick questions are in poor taste imo.

<comment><USER54> I would've thought the first question was a big red flag but I guess in Windows and x86 linux int is 32 bit even with 64-bit processors. Not the case in MIPS64 (under IRIX) or on DEC Alpha.

I had my formative C experience in the DOS era with 16-bit compilers and then SGIs with 64-bit compilers (and I had the "fun" of porting grad student written code from SGI to Linux) so you get burned with expectations about int length. Packing makes it even worse as many RISC machines (like MIPS) are word addressed and non-aligned loads require a bunch of bit fiddling or you get a Bus Error (SIGBUS).

</comment></comment><comment><USER55> While I get the overall message I'm not sure last question is that unpredictable: I++ + ++I If postfix is executed first it returns 0 but prefix returns 2 and the result is 2. If prefix is executed first it returns 1 and then postfix also returns 1, result of the addition is again 2. What else is ambiguous about this snippet? I can't think of a parse tree that'd evaluate addition before any of the increments - that'd be a syntax error. If the code were (++i + i++) there could be alternative interpretations, but again ++ requires lvalue...

<comment> loup-vaillant The order of evaluation in such an expression is entirely unspecified. There are points in C programs that separate a "before" and an "after". The semicolon is a typical such point. There are others. Now between two adjacent points anything goes.

In this particular example the evaluations and effects are allowed to be interleaved:

        pre    = I + 1;      // evaluating the pre-increment
        post   = I;          // evaluating the post-increment
        I++;                 // effect of pre-increment
        I++;                 // effect of post-increment
        return pre + post;   // evaluating the sum

Simply put, pre and post-increment are allowed to occur "simultaneously".

<comment><USER56> what you are saying may be correct, but you are "overloading" the term "order of evaluation" to encompass atomicity (atomicity of operations like i++); is that kosher?

<comment> loup-vaillant Indeed I am. What I want to convey is, between 2 sequence points, C is actually non-strict. Any effect is like unsafeInterleaveIO from Haskell. Which is why I rarely mix up effects together or with a computation in a single instruction.

</comment></comment></comment></comment><comment><USER57> This is a good reminder that once you deal with different compilers and operating systems a lot of assumptions don't work anymore.

</comment><comment><USER58> > That's right, Mozart also wrote in C.

 _applause_

</comment><comment><USER59> You confuse knowing with expertise.

</comment><comment><USER60> In my case, I'd normally say that Betteridge's law applies. But I did surprisingly well on the quiz.

Though I'd agree with the comments on how this is kind of silly. The answer is not always "I don't know" but rather, in some of those cases, "I didn't define my data types well enough to know for sure, depending on CPU architecture and the compiler".

<comment> mark-r I think the point was that if you're writing portable code to the standard, you _can 't_ know the CPU architecture and the compiler!

</comment></comment><comment><USER61> > Yes, the right answer for every question in "I don't know".

Do you think you know the English language?

</comment><comment><USER62> Even when you know the standard, you will still get undefined behaviour.

</comment><comment><USER63> So the author thinks undefined behavior is the esoteric knowledge of C?

</comment><comment><USER64> C is beautiful.</comment>


Trunk-Based Development vs. Git Flow - <AUTHOR> https://hackernoon.com/trunk-based-development-vs-git-flow-b1b23044dfb <comment><USER2> One major advantage of the gitflow/hubflow git workflows is that there is a standard way of merging across branches. For example, a 'hotfix' branch is merged into the stable master branch and also develop with one standard command; there's no need to re-explain and train new devs on how the branches were supposed to work here. I even copied the diagram(s) into my notes: [https://westurner.github.io/tools/#hubflow](https://westurner.github.io/tools/#hubflow)

IMHO, `git log` on the stable master branch containing each and every tagged release is preferable to having multiple open release branches.

Requiring tests to pass before a PR gets merged is a good policy that's independent of the trunk or gitflow workflow decision.</comment>


Show HN: developing a techmeme alternative. - <AUTHOR> http://gta2go.com/

<comment><USER2> I'll be grateful for decent Techmeme alternative :) However I'm already worried if it'll live long enough (read business model). Good luck then!

</comment><comment><USER3> That's great! What are you powering the site with?

<comment><AUTHOR> I wrote my own clustering algorithm in php and I use <http://www.simplepie.org/> to parse the feeds. I will eventually open source it if there is enough interest. But the code needs cleaning up before I do that.</comment></comment>


Don't Worry, Ben, It's a Long Way to San Quentin - T-A http://go.bloomberg.com/market-now/2014/02/12/dont-worry-ben-its-a-long-way-to-san-quenti/

<comment><AUTHOR> The original HN thread on Ben's "Why I did not go to jail" post had comments saying more or less the same things, though not to this level of detail.

Talking about jail was much more attention-grabbing, though, and that worked out well. The downside of that though is that now some readers are hung up on whether Ben really was going to jail and might miss the more important example about having expert help but digging in to the details of that expert advice.</comment>


Unstealable bike - <AUTHOR> http://yerkaproject.com

<comment><USER2> In quick summary, it looks like a large, built-in U-lock with the frame itself forming part of the U. Not un-stealable exactly, but rather a deterrent in the sense that using traditional U-lock-breaking methods like a carjack could damage the frame making the bike worth less(or nothing).

You'd still need to secure the tires, though, too. I can't tell if there is a built-in part of the U-lock that allows for threading a cable through or anything like that. Typically what I see is something like U-lock around the rack, front tire, and frame with a cable threaded through the U-lock and through the back tire. Not invincible either, of course, but much more work and therefore more of a deterrent.

</comment><comment><USER3> That bike seems more stealable than the folding bikes I used for commuting before I started working from home. Interestingly, during all the years that I used folding bikes, I was never prevented from carrying my bike into a building or onto a bus, etc. (Though, I did need to cover it with a bag before placing it in shopping carts at grocery stores.) It worked out amazingly well.

</comment><comment><USER4> "We decided to take a key structural element and saw it in half!"

<comment><USER3> You haven't heard of folding bikes?

</comment></comment><comment><USER5> The premise is that thefts involving frame breakage would be lower: this is not necessarily true. If the components are nice enough then it is worth the thief's time to break the frame.

</comment><comment><USER6> Completely ridiculous. What about the wheels?</comment>


Why not allow people to buy iphone apps and run them via simulator under Mac/Win? - <AUTHOR>

It's not clear to me that this would result in fewer ipod touch/iphone sales.  In fact, it might result in more as the simulator would act as advertising.<p>Even if the simulator only runs under Mac, it would still be a significant improvement over the current situation. <comment><USER2> Not everything works (or works the same) in the iPhone simulator on the Mac as the device. You can't make/answer calls, no accelerometer, vibration, certain effects are missing, performance is different, multi-touch is hardly usable, since you use the mouse+keyboard to simulate it, etc.

And there is no simulator for Windows at the moment.

It's going to be a lot of work to package it so that it is secure (DRM), works, and is polished enough for consumers. Probably not worth the cost considering how the App store is selling apps like hot cakes.

</comment><comment><USER3> I think "quality of user experience" might be a reason.

Operating the simulator feels like doing watch repair with mittens on. You are denied your fabulous desktop input and output devices and can't easily access the fabulous iPhone specific interface devices. The result is a shabby experience.

<comment><AUTHOR> It would depend on the app.

</comment></comment><comment><USER4> At least with web-based iPhone apps you can use something like Fluid to create a site-specific browser to view the iPhone version of websites on your desktop.</comment>


TensorFlow Model Analysis – A library for evaluating TensorFlow models - <AUTHOR> https://github.com/tensorflow/model-analysis <comment><USER2> What's the advantage over just using tensorboard and writing summeries of whatever you want?

</comment><comment><USER3> I've read the README and I still have no clue what exactly this library is supposed to "evaluate".

<comment><USER4> It's meant to help evaluate the performance of a TensorFlow model after training. In particular, you can define a series of metrics to measure, and different subsets of the data to evaluate on. And it can scale up to evaluate on large datasets since it uses Apache Beam for distributed data processing.

This notebook here shows some helpful cases: [https://github.com/tensorflow/model- analysis/blob/master/exa...](https://github.com/tensorflow/model- analysis/blob/master/examples/chicago_taxi/chicago_taxi_tfma_local_playground.ipynb)

<comment><USER3> Thanks.

I still don't see the point, but maybe someone needs this. To me, it would be a lot more useful to evaluate things like memory consumption and CPU/GPU bottlenecks (for each node in the graph).

<comment><USER5> They do show resource usage (GPU utilization/memory) - but only for TPUs (i.e., only if you use managed tensorboard on GCE).

This library is about bringing Apache Beam into play. Tensorflow is not really distributed (distributed tensorflow requires you to start all the servers and manage all the endpoints yourself). Right now, we use Spark for pre-processing pipelines and for launching both parallel experiments in TensorFlow and distributed training. Spark is a key part of TensorFlow for us (www.hops.io). Google want an open-source alternative (not just managed TF, which is distributed) that enables ML pipelines. This is it. Spark is fighting back, with Image pre-processing now part of Spark 2.3. We recommend Spark for pre- processing, spitting out .tfrecords, which then are used as training/test data.

<comment><USER3> What kind of models are you training? Why do you need distributed TF? I was under impression that it's pretty rare to need it for training (e.g. large scale evolutionary hyperparam search on 256 GPUs, or things like that).

<comment><USER5> Anything that's not MNIST. Even Fashion-MNIST benefits from hyperparam search. Distributed TF is the standard in Google, will be the standard amongst everybody else within a couple of years. They actually just run Estimators, and distribution is somewhat transparent to them.

When hyperparam search is this easy with PySpark, why wouldn't you do it?

def model_fn(learning_rate, dropout):

[TensorFlow Code here]

args_dict = {'learning_rate': [0.001, 0.005, 0.01], 'dropout': [0.5, 0.6]} experiment.launch(spark, model_fn, args_dict)

For distributed training, we favor Horovod. It requires minimal changes to code, and scales linearly on our DeepLearning11 servers: [https://www.oreilly.com/ideas/distributed- tensorflow](https://www.oreilly.com/ideas/distributed-tensorflow)

<comment><USER3> _why wouldn 't you do it?_

Perhaps because I don't have hundreds of GPUs laying around? I'm a DL researcher fortunate enough to have a 4 Titan X workstation for my experiments. Most of my peers at other labs only have shared access to such workstations, and with the current trends in GPU pricing, that's not likely to change in the nearest future.

More importantly, the lack of compute power is rarely a bottleneck in my research. Reading papers, brainstorming new ideas, and writing/debugging code are the most time consuming parts, it's not like I'm sitting idle while waiting for my models to train.

 _Distributed TF is the standard in Google, will be the standard amongst everybody else within a couple of years._

By "everyone else" you mean a few dozen corporations, which can justify spending millions of dollars on hardware to speed up their mission critical ML research?

<comment><USER5> Things can change quickly. When Ethereum goes to proof-of-stake the market will be flooded with cheap 1080Tis. A moderately well-funded lab should (by the end of 2018) be able to buy 100 1080Tis in DeepLearning11 servers for 100K Euro and do cool work in distributed learning and model architecture search.

SoTA in Cifar-10 and ImageNet is now model-architecture search. This paper/blog was an eye-opener for me: [https://blog.acolyer.org/2018/03/28/deep-learning-scaling- is...](https://blog.acolyer.org/2018/03/28/deep-learning-scaling-is- predictable-empirically/)

<comment><USER6> What's the ETA on that? I'd love me some cheap 1080Ti!

<comment><USER5> Prices are already down. Keep an eye out here: [https://www.reddit.com/r/nvidia/](https://www.reddit.com/r/nvidia/)

Current estimates are that 75% of ethereum mining is done on 1080Tis. So, if that stops overnight - will they sell them or switch to some other bitcoin? My guess is that they will flood the market. Mostly they are under-volted when mining, so they won't burn out within a few weeks if you buy used.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


GitHub repo file update notification - <AUTHOR> https://github.com/DevScoreInc/samples/tree/master/github-file-monitor <comment><AUTHOR> Just for some Friday fun! This function notifies you when someone changes specific files you're interested in on GitHub. Single click deployment to [https://devscore.com](https://devscore.com)</comment>


Programs/Games/Websites for a 7 year old to start learning how to code - <AUTHOR> I have a 7 yr old boy that has a real interest in technology. He's keen to learn how to program. Have you seen a great learning program/game/platform that I can use to get him introduced to the core concepts? Thank you! <comment><USER2> For a seven-year-old? MIT's Scratch: [https://scratch.mit.edu/](https://scratch.mit.edu/)

Once they are comfortable with scratch you can get them a Raspberry Pi and develop hardware-software projects depending on their interest.

Knowing Scratch also helps to get them into game development.

Lastly, after getting Scratch you can get the kid a Lego Mindstorms kit and build robots, musical intruments, etc.

<comment><AUTHOR> Awesome. Was just told that Lego Mindstorms is the way to go as well. I'll start with scratch and we'll go from there. Thank you!

</comment></comment><comment><USER3> I second Scratch. My daughter and I have been using it since 5.

I taught a quick intro course to it at her school in December. Here are the intro lessons I taught

[http://nextlesson.com/homeschooling-ideas-learn- programming/](http://nextlesson.com/homeschooling-ideas-learn-programming/)</comment>


Ask HN: How do you decide for a backend language? - <AUTHOR> I'm "only" 6 years into my career but already worked with a dozen languages. While there are some obvious distinctions (like elixir being a better fit for concurrent systems or some being statically typed while some are not), most of them are very similar.
For corporate projects I usually comply to whatever language the system is already written in and adapt to that, but if I were to start a new project now, I wouldn't be sure which language is the right choice.
Here are some of the languages I used for projects in the past:
- Go
- Clojure
- Elixir
- Ruby
- Python
- Java
- NodeJS
- PHP / Hack
How are you deciding which language to pick when starting from scratch?
(On a similar note, the same thing could be asked for client side code: JS, TypeScript, ClojureScript, PureScript, ES6 / Babel, Coffee, etc) <comment><USER3> I have a personal rule, which I've shared on here before and people seem to think has some merit:

If a project is innovative in a business sense, then choose a boring technology. If it is boring in a business sense, then choose an interesting technology.

<comment><USER4> And if it's innovative in a technical sense, then choose innovative technology. If it's merely innovative in a business sense, then it doesn't matter what you choose.

<comment><USER5> > If it's merely innovative in a business sense, then it doesn't matter what > you choose.

The point is focus. Pick one and innovate it extremely well.

</comment></comment></comment><comment><USER6> In my freelancing career I usually choose the language with the following Q&A to my colleagues ( myself, if it's a side project ).

1\. Are there business requirements for the language ( already written project, specs, etc. ) ?

2\. What kind of budget does the company has for hiring devs ( killing point for Clojure, Elixir, TypeScript, etc. ) ?

3\. What's the most difficult problem that needs to be solved by the product ( you probably don't want to create a 3D Game with NodeJS, right? Or a highly dynamic charting with PHP ) ?

4\. Is there going to be a front-end / back-end division in the team ( Having a division makes you more comfortable in choosing the back-end language, since most full-stack devs are using NodeJS/PHP/Ruby ) ?

5\. Finally if you are working on your own task and previous questions didn't give you the right answer, you could ask yourself : Do I need to learn something new or I want to build something fast?

At this point you will have eliminated most of the obvious choices. Recently I'm using Isomorphic TypeScript with NodeJS for most of my side-projects, but first thing I will do if something goes above a certain amount of users is to start thinking business-wise and answer those questions on my own.

<comment><USER7> The other factor I'd consider: is working on this project someone's full-time primary job, part-time or shared by multiple people, or a one-time contract gig?

A rapidly-evolving language / library ecosystem can be great if you work on it full-time and have a lot of supporting infrastructure but miserable if you're the person who was just told to patch a security hole flagged in the last audit and you end up needing to upgrade dependencies with a dozen breaking API changes just to install the version of something which the maintainers officially support.

</comment></comment><comment><USER8> Now we're talking optimizing for a hugely multidimensional system here.

Expressiveness: If you've aiming for a large team, try to work with a language that enables large scale services and large teams - also in the long run, strongly typed languages will work out better for this case, Java / Scala being the obvious candidates. But if you go down a microservices route, other choices might work too.

Niche stars: Some languages have obvious strengths in certain niches, depending on what you want to build. Machine learning - Python, Microservices - Go, isomorphic JS web servers - Node.

Performance: Very many requests -> closer to the machine. Note that JITs have skewed this equation somehow towards being able to use scripting language, but it still generally stands, because if for some reason you can't track, code is falling out of the optimizer after a one line change, you're still screwed. Closer to the machine is more predictable.

Maturity / Current traction / Traction curve: Brand new is shiny and attracting bleeding-edge devs (making hiring easier), but be prepared to be the first one with a problem or having lots of devs around who love tech more than results and are gone for the next shiny thing in half a year. Lots of current traction is good, rather don't choose languages that are great but on the path down (Ruby). Be extra careful in choosing too exotic languages, you won't be the first company dying from not finding any devs for your ageing Groovy on Grails stack.

Availability: PHP and Java are safe bets, but it's much harder to separate the wheat from the chaff developerwise. Languages like Go or Clojure will find you more driven devs usually because they're not usually taught at university. Caveats: see above.

Lots and lots of other variables here, just some of the larger thinks to think about.

<comment><USER9> Curious why you think Ruby is on the way down?

(Just picked up 4 months of RoR experience after years of php and Java with some dabbling in Python.)

<comment><USER10> Some say it is slow, others like a more strongly typed language.

It might still have the most active web dev ecosystem of all languages; but it has clearly shown its limits.

</comment></comment></comment><comment><USER11> Personally I feel most comfortable in Python / Go / Java - while I have no problem kicking off a project in another language, those three just happen to hit the sweet spot for me for different use cases while not getting too much in my way.

I assume we are talking about some side / hobby project, not starting new projects for a client?

One thing I usually take into consideration is if there are libraries or frameworks that will drastically reduce the amount of boilerplate I have to write.

Starting a web application in golang for example is surely possible, but while deciding on a router, template engine and datastore I can already start writing code in Django / Play / RoR.

If it is not an experiment to get to know a language or language specific features I usually prefer to go with some battle proven libs I can rely on and try to not reinvent the wheel.

Another thing to take into account is what kind of app you are actually going to build. Small CMS for a non profit? Crunching lots of numbers? CLI tool? Will you have to maintain it? Does it have to scale? How much time can you put into maintaining and scaling?

Those questions alone should already reduce the number of choices. For a simple CLI tool you could package a VM or require the user to rely on package manager and language which is installed on the system or you simply use a language that compiles to an executable.

So I guess my checklist in order I ask myself the questions: 1\. Does one of my goto languages fit the project? 2\. Are there libraries that would help me build it? 3\. Which language of the remaining ones annoys me the least?

<comment><USER12> I also maintain a three pronged approach like this, where I keep one dynamically typed scripting language, one compile-to-native speedy one and one general purpose on a VM style language like Java.

Currently my picks are:

Rust -> to native + speedy Ruby -> nice relaxed scripting language Scala -> on a VM general purpose language

Though the difference is more blurred from original intent these days - <USER2> used to look like:

C Perl (5) Java / C#

which is considerably more pronounced.

The only addition I can make to this is I'd pick based on how I'm going to deploy too - Java is fairly difficult to deploy to desktops compared to Golang for example (for reasons like ensuring the correct JVM version is installed etc). Ruby is even higher on the difficulty to deploy scale, to the point where I probably wouldn't ship it to a customer non-dockerized (but if hosted internally, that's fine).

</comment></comment><comment><USER13> If you're starting a one man project, just take the one you're being the most productive in. If the project is a team effort, then it comes down to the team preferences or team members' willingness to change. From my experience, team adopting a completely new language isn't the big deal per se, more difficult is team dynamics, requirements/people changes, hiring new team members especially if your area can't provide many people with desired skillset. Take a look around what's the trend locally, for the vast majority of projects it's more important to deliver a quality project on time, than to code in a, now matter how, exotic (and other super attributes) language.

<comment><USER14> "Go with what you know." It even rhymes.

I'm all for learning stuff, and if I'm working on a project that has no particular deadline (or a deadline that's far enough out that I can deal with frustrations of learning), by all means use new and shiny. But if I have a real goal and a deadline, I'm going to use something I already know in and out so I can spend my time making, not learning. If I get something to production and find that it's performance is horrendous, I can always come back and optimize (or rewrite) later, but it's better to get something out and see if it even works than to be fighting a new syntax or picking middleware.

<comment><USER13> We're on the same page here. :thumbs-up:

</comment></comment></comment><comment><USER15> Start based on the project itself.

If it's a personal project and there are no risks involved, it's a change to pick a new, innovative or trendy language, like Go, Elixir, Clojure, Rust, etc.

If it's a personal project, but you want to complete it fast, probably pick whatever you are more comfortable with. Don't try a new environment if you have to deliver in time.

If it's a corporate project and chances you are not alone in that project, pick whatever is more comfortable for the team. Don't try to innovate that much or you have a chance of have a world of not predicted problems with that language/environment.

But if it's a corporate project and you are mostly alone, then you could pick a different language from that world. Some language that you have deeper knowledge that others and maybe you wanted the team to try/adopt. And that's a quite nice opportunity to both showcase you abilities, initiative and the language itself - because companies generally have a hard time adopting new things.

</comment><comment><USER16> 1\. Which language you know the best.

2\. How well this language is suitable for a given task.

3\. If language you know the best is not suitable, pick second language you know best and repeat 1. and 2.

For example, you wouldn't really use Go to write big, but traditional web application. You'd use something like Ruby, Python or PHP (maybe Java too). So pick among these.

</comment><comment><USER17> Depends on a number of factors for me. If it's a small, well-defined project, just go with whatever you're happiest in. If it's a large project or a large company, then go with who you can hire (eg. Java, C#, etc.)

Actual language/subject matter practicality is a relatively minor consideration in comparison. You're usually talking about some sort of performance/dev-time/cost tradeoff and short developer time almost always wins. So small projects go with a quick happy language, big projects go with a "enterprise" language designed for large teams. Ultimately they're both about reducing the total devtime.

It's very rare for any particular task to be tightly coupled to a language. I can only really think of a couple, Erlang and SQL. Maybe C/C++ for high perf jobs. Otherwise, since all Turing-complete languages can technically do anything any other can, you're probably going to waste more time fiddling about in a new language that _might_ be more appropriate, than if you just got cracking in your everyday general purpose language.

Most considerations beyond the above are probably just going to be people's personal opinions about their favourite language. It's like arguing emacs/vim or tabs/spaces, not going to help much ;)

</comment><comment><USER18> Well it depends the nature of the project you're starting from scratch. If it's a new project at your employer, there could be factors like "how easy would be to hire / train people to work on this project in the future?" or "how mature this technology is / how likely is it that unknown problems will bite us in the ass in a few months or years". But if it's for personal use, I guess it's a matter of what your main motivations are for it. Personally, if I'm building an MVP or in other words, my main reason for building it is to get it in front of customers ASAP, I probably go with the stack I'm most familiar with. But other times I start a project just to play around, learn or get more familiar with a new stack, so then I do just that.

</comment><comment><USER10> For server and client side I'd go with a strongly typed language. This to help me maintaining the code base, mainly by making refactoring cheap.

Server side they are: Haskell, OCaml (or Facebook's Reason), F#, Rust.

Client side: PureScript and Elm; and to a lesser extend: TypeScript and Flow.

Now what counts is maturity of the "web" ecosystem. For server side I think Haskell and OCaml are more mature then F# and Rust in this regard. Client side non of the contenders are _very_ mature, where TypeScript and Flow are more of an extension on vanilla JS, so they will have good interop with existing libs.

For me Rust is a little too low-level for web dev, but it depends on the performance characteristics you are looking for.

</comment><comment><USER19> My business is working with non-technical startup founders and helping them get the technical side of the business off the ground. Your question is one I (and my clients) ask myself all the time (I'll leave out my preferred stack since it's not relevant to the question). Here are some questions you need to ask yourself:

* Are you planning to grow the business if the app succeeds? If so, how hard will it be to find developers familiar with the stack you've chosen? Or how difficult will it be to train someone to learn it?

* What is the ecosystem like? Is it already large and active? Or is it large and languishing? Is it easy to find help on StackOverflow / Google if you run into an issue? How easy is it to configure it to run on a bare VPS / EC2 instance?

* How familiar are you with the stack personally, and what's your planned completion date? If you want to get something up and running fast, unfamiliarity will lengthen your timeline. If you don't care so much about spending extra time learning a new skill, then use whatever stack you are most excited about learning.

Ultimately--and I know this probably sounds unhelpful--this is really a "feel" thing. Use whatever you feel the most comfortable with, whether that comfort is existing knowledge of the language, or the comfort is knowing that you'll be able to find help when you need it. Different things matter to different people, so I can't quite tell you what to decide, but this has always worked out for my technical decisions. Passion for your project can always overcome a sloppy or bad technical decision.

</comment><comment><USER20> If you have not already done so, I would recommend choosing a language to invest in, with the goal of becoming proficient in it. The purpose here is to select a language to be your "default" language. Write out a list of the things you value the most in a language and the things you wish to avoid. Examine the languages/paradigms you have already learned. Do any of these meet the criteria you listed (pros/cons)? If so, pick one of these to learn at a deeper level. If none of these are satisfactory, spend some time researching other languages or paradigms. Do other languages/paradigms match your criteria more closely? If so, it may be worth investing the time to learn something new.

I have yet to come across the "perfect" language or paradigm, but I have come across ones that have stretched me to learn new concepts I likely would not have learned otherwise.

One criteria I would _not_ leave off the list is this: "I want to enjoy working with the language/paradigm."

</comment><comment><USER21> I imagine many people will say what you said, including me: _For corporate projects I usually comply to whatever language the system is already written in and adapt to that_

Assuming you're talking bout about a personal project, or a one-man startup...I'm interested in why you ask? That is, why do you doubt yourself? You've covered an impressive variety of languages; what keeps you from picking

a) What you are excited most about.

b) What you're most comfortable with, all things considered (years of experience, interaction with the community).

c) What the conventional wisdom says is good for the project that you have in mind, e.g. Rails for a full-featured web app, Elixir for something more minimalist with higher scalability, etc.

I don't have an ambition to deploy something into production, so I use Ruby for any quickie static sites, Python for data analysis (sans web-facing product), and am now redoing Past projects in Node because I've discovered that I enjoy ES6

</comment><comment><USER22> I look at whether I need a quick prototype or a long term solution. I find it is much quicker to hack a web based prototype in NodeJS as compared to Java. Also, what kind of UI do we need, most of the times it's a web/javascript based UI then the choice is NodeJS because of seamless data transfer using JSON, other times the backend doesn't necessarily have to talk a lot with UI like Batch jobs and I prefer Java. If I am going to need a lot of CPU intensive jobs where manually spawning multiple threads can be beneficial I would go for Java, NodeJS will not be very beneficial in that case. Other than that it comes to features each language provides, like rich and robust concurrent and collections library of Java. Similarly if a lot of data analysis is required python is a clear choice of many, again because of the rich data analysis libraries.

</comment><comment><USER23> If you just want to dabble with a bunch of languages pick whichever language is at the top of HN that week.

If you want to create good software then pick a language and stick with it for a decade so you really get to master it.

If you want to become a better programmer then work on interesting and difficult problems regardless of the language.

<comment><USER24> @gizmo is right, but u might prefer to learn from horrible experiences instead

</comment></comment><comment><USER25> This is like asking a group of artisans what is the best kind of timber to make furniture out of, I'm afraid.

<comment><USER26> > This is like asking a group of artisans what is the best kind of timber to > make furniture out of, I'm afraid.

I agree. I thought I had left this sort of topic behind at Quora.

</comment></comment><comment><USER27> * Golang for something CPU-bound, small apis that should be really really performant

* Elixir/Phoenix for mostly everything else, including REST APIs, regular web-apps, various chats, backends for games, mobile apps.

How? It should be easy and fast to write some functionality, easy to add functionality on late phases of development, it should be "secure by default" (e.g. autoescaping untrusted input, cross-site-scripting protection on by default), fast enough for your task (usually all the langs fast enough but 10x is 10x :) (rails vs phoenix)). You'd also want to check for specific requirements of your target architecture (e.g. processing video, websockets)

<comment><USER28> Go is reasonably performant (compared to slowpokes like eg Python or Ruby), but not actually all that fast.

But that's probably fast enough for most projects, and seems to be fast enough for you.

<comment><USER27> Basically on par with Java -JIT optimizations +less memory bloat, startup speed. For even more performance something from C, C++, Rust league is necessary

</comment></comment></comment><comment><USER29> I can propose another one: ActionScript 3 see: [https://github.com/Corsaair/redtamarin](https://github.com/Corsaair/redtamarin)

So yeah I'm the author of this project and while when I started it, it was mainly for fun "let's run AS3 on the command-line", couple of years ago I started to force myself to use it more and more server-side in the spirit of "eat your own dog food", and quite happy with it for my own side projects.

Now, as any other dev I also work with many others programming language server-side, and on a project where I'm the one to make the choice about which language to use I would say it does not matter much.

Seriously, most backend languages are more or less equivalent, except few details or "religious faith", it's not like the features of one particular language can make or break a project.

To chose one I pick the tech based on: who gonna maintain the project in the long run ?, what other dev (team) or owner (company, vendor, etc.) expect ?, what type of project or architecture is needed ? etc.

To be honest, being able to chose the language feels like a luxury, if you put "religion" aside, some people must trust you will make the right choice, even if you can chose whatever you want small comments like "we would like it to work on a LAMP stack", "we are a Microsoft shop", etc. can influence the choice.

But I do believe there is no wrong choice there.

<comment><USER30> RedTamarin does look like a great project, and I'm impressed by how much effort you've clearly put into it.

I was just curious, what are your thoughts about Haxe? It's not quite the same as AS3, but it is meant to be fairly similar.

[https://en.wikipedia.org/wiki/Haxe](https://en.wikipedia.org/wiki/Haxe)

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

<comment><USER29> thank you :)

you got almost the answer here "It's not quite the same as AS3"

Haxe focus on transpilation/cross-compilation with its own language 'Haxe' and its own compiler, libraries, VM, etc.

The closest to Redtamarin would be the NekoVM [http://nekovm.org](http://nekovm.org)

I would say it is a different approach, Redtamarin focus on AS3 the language but also on the AVM2 and by extension the reuse of the Flex SDK (for the compiler) and other tooling that already exists (like Flash Builder IDE).

And so when you compare Haxe/NekoVM to AS3/AVM2 the difference mainly shine in how you write programs and libraries.

Redtamarin approach is to provide a "C API" for low-level function and other syscall, so dev can write "as fast as if they were writing AS3 as usual", they only need to learn a new API and the subtleties of system programming.

You could find the same kind of differences with CrossBdrige [https://github.com/adobe-flash/crossbridge](https://github.com/adobe- flash/crossbridge)

Both NekoVM and CrossBridge focus (in their own way) on the reuse of C/C++ libraries, e.g. if you need zlib you can reuse it, but then it forces you to compile native stuff.

Redtamarin almost opposite approach is to provide a kind of C standard library (POSIX like even) in the context of AS3/AVM2, which allow you to port or write the AS3 code to do native stuff in a cross-platform way, but you can not reuse external native libs like zlib.

See for example this getaddrinfo sample code ported from C to AS3 [https://twitter.com/zwetan/status/752202410521726976](https://twitter.com/zwetan/status/752202410521726976)

The logic for that is let's say you need popen2.popen2() from Python, you can implement it in AS3 reusing C functions like popen(), pipe(), fork(), dup2(), close(), etc.

Except for fork(), the AS3 code will work under Linux / Mac OS X.

You could say that Redtamarin is a lot of hard work to add small native C functions call, so dev can easily write AS3 programs for command-line and server-side.

Another example, you can take JS (ECMAScript, ECMA-262) code, compile it and run it with the redshell, I did it with the TypeScript compiler, I just needed to implement ChakraHost, the detail is here [https://discuss.as3lang.org/t/the-case-when-you-dont-want- no...](https://discuss.as3lang.org/t/the-case-when-you-dont-want-node-js/307)

So to come back to Haxe/NekoVM, I'm not so sure you could either implement popen2.popen2() with just the system libraries available or if you could just compile/run TSC sources with Haxe/NekoVM unless making a big rewrite of the whole thing.

Many people probably think that AS3 is dead because "flash is dead", but AS3 is also ES4 and so fully compatible with ECMA-262, being able to reuse IDE with just a little swap of playerglobal.swc with redtamarin.swc and instantly have syntax completion to write server-side program, publishing documentation with tools like asdoc, etc.

All those things are the reason why Redtamarin focus on AS3 the language, and why it is very different than Haxe and/or NekoVM.

<comment><USER30> Thank you for taking the time to write a detailed answer!

</comment></comment></comment></comment><comment><USER31> I always start with Python, because I can't find any other language to be just as easy for others, including the "me of the future" to understand.

Then I go through Python's ups and downs for that specific project.

Is Python too slow for this? Then let's take a look at the most python-like techs on the "fast as hell" list.

Does it need to be small/embedded? So let's look at the Pythonics of the the crudest languages.

In recent years, this means almost anything I write is either Python or Go.

</comment><comment><USER32> Of the ones you listed, for backend I'd narrow to Python, Ruby, Java, or PHP. Reason, they are mature and have a ton of libraries, frameworks, and projects to build upon. They are not going anywhere.

For front end, it doesn't matter. It's a continually moving target. Your front-end will be an endless work-in-progress, as the pace of browser change, UI conventions/fads, and tech stacks shows no signs of slowing or converging on a common solution.

</comment><comment> yc-kraln The thing is, most projects can be solved by most languages and frameworks. Apart from some special cases, there isn't usually that high of an impedance mismatch. This means that you have to look to other factors to decide... things like: * Tooling support * Talent pool / ability to hire * Available resources * Support / stability

FWIW, the last time I had to make this decision, I went with Python--a language I had never used before. No regrets.

</comment><comment><USER33> There are several things I might consider, but this is by no means an exhaustive list:

* Tech fit -- how does this technology solve the business problem? Have you considered how the overall architecture will look like? You might end up splitting them up to several different components each potentially valid to be written in different languages, depending on their nature. Given that, what do you need to achieve? Perhaps a Rails app is fit for purpose if you're writing a proof of concept. Or you might opt for a language that has established libraries for exposing a RESTful interface and write an SPA on top of that. My point is that it really depends on the business problem and how that is tackled.

* Ecosystem -- are there libraries out there that help you do what you need it to do? Will you have to roll your own?

* How will it be maintained? If you're not working for yourself, then you can assume your code will be maintained by someone else. Is the technology chosen accessible for your intended audience? Like you said, if it is a xyz shop, then it might make sense to write it in xyz. If it's a polyglot shop, then perhaps this is less of a consideration.

* What are the development tooling like? IMO this is quite important for my sanity because I dislike using clunky tools.

* How will the code be pushed out to production. Are there established best practices for pushing the code you're written in xys language into production?

* How easy is it to write tests for the language?

Something to also consider is whether it is good for the future. There is an element of YAGNI here, but it's worth considering the longevity of your technical choices and how easy it will be to upgrade.

</comment><comment><USER34> I started by learning what the company used; Java, PHP, Ruby, Bash, C. From there I picked up Javascript, Go, etc.

Personally, I pick the thing I'm most proficient in and enjoy building with. In a certain context certain languages make sense. Dynamic scripting can be useful for rapid development. Javascript is usually a must for frontend or simplifies code sharing longer term. Backend you usually need something more performant so after much searching I finally found Go to be a perfect fit but again thats a personal preference.

If working with a team I think it complicates things slightly. Now you must take everyone's skills and opinions into account. If working within a company you need to think about hiring and longevity of the code base. That's where normally you agree on 2-3 languages, again based on context and what's fit for purpose.

If you're just building something for yourself, go with what you're proficient in. If you want to learn a new language, pick one and build something to learn the language. If you're working with a team, democracy usually wins.

Hope that helps a little. Just my opinions and what I'm used to. Not gospel.

</comment><comment><USER35> I choose base on what type of project I'm working on.

If there is a legacy project/library that I need to work with, I just go with whatever exists.

just a normal web application? \- ruby or php.

building for enterprise? \- whatever i feel like for jvm or .Net, but java or c# for the SDK

heavy on rules? \- prolog

performance, small memory footprint \- go/c++/c

prototype, machine learning \- python

concurrency required \- erlang/elixir, java/clojure

</comment><comment><USER36> I usually decide based on some combination of a) do I know the language/platform well b) is this for a client or for fun c) is this for learning, and d) is this a mainstream platform, then (e) if not, then does it have an advantage solving an important problem at hand?

If (b) for a client, then (a)/(d)/(e) are important. I know the .NET platform best and it's a mainstream platform, so I tend toward that one. If your strongest platform is X, then I think usually you should use X in general, unless something else has a distinct advantage (i.e., write device drivers in C or C++, not C#; use Y because it has libraries available that would save you tons of work, etc).

If (b) for fun, then I pick whatever I feel like piddling around with. Sometimes Node, Go, F#, C++, whatever.

If (c) for learning, then I pick something useful to me or something I need to get better at. Right now this is F# and C++ for me, but will sometimes be something esoteric.

</comment><comment><USER37> Just use C++. C++11 is a nice, modern language. Lots of OO and functional constructs. It compiles and runs just about anywhere. Lots of people know enough to get stuff done with it. You don't have to worry about a VM and performance issues, and with RAII and smart pointers you don't have to worry overmuch about memory management.

</comment><comment><USER38> It depends on the requirements of the project, but generally speaking I'll write in whatever I feel I'll be most productive with (previously that was PHP, these days it's Node). This is because the code I write doesn't need to scale up - I write pretty niche things that will never have more than a few tens of thousands of users. The language choice won't ever lead to a performance problem because it'll never get so busy that the implementation is the bottleneck. If there's a problem it's most likely to be down to my code/logic.

If I had to write a scalable system where the code would make a difference for whatever reason, then I'd do a lot more research in to that specific area.

</comment><comment><USER39> If the problem is programmer bound, I use Ruby / Rails. For CPU and memory bound problems, Go. For very JSON and HTML centric APIs (Elasticsearch, documents), or for those the involve executing JavaScript from untrusted sites (scraping), I use NodeJs.

</comment><comment><USER40> I'd actually like to see more mixed shops. I proposed this once, but the idea got shot down. This was at a time when we were having a very hard time recruiting good developers for the technologies we were using.

IMO there's not enough difference between well-written Ruby / Python / PHP / JavaScript etc. to make a big fuss about it.

It's pretty well documented / understood how one would decouple the backend by simply interfacing your front end with a RESTful API backend.

That and the fact that it's become relatively clear to me that the present and the future of the web is in rich client architecture.

</comment><comment><USER41> tooling available and libraries / frameworks are as important as language imho, often the domain of the application drives the choice of these. From these the language is determined.

Other factors are familiarity and what tech the people who have to support it are familiar with. Language is in some ways a less important choice and is seldom a matter of choosing the 'best' one.

if you're talking about a side project though, knock yourself out. Personally I'd recommend looking at Typescript (web), C# (windows), Swift (apple) or Delphi (cross platform).

</comment><comment><USER42> I use the best tool for the job. If it is a quick scripting kind of thing, python. An API, i'll probably use Ruby which has a gem for everything. If there's a lot of complicated rules where I might refactor a bit, i'll use a strongly typed language like C#. If its a data thing, keep it in sql. If its a stats thing maybe R. If it's a hardware kind of thing, C++.

I don't really care about what's hot or trendy, I just want to accomplish the goal, and i'll use the tool that gets me there fastest.

</comment><comment><USER43> For a server-side language:

First, I decided to use Windows for my operating system. Why? Because when I made the decision, my computing experience had been on IBM mainframes, super- mini computers, PCs, and OS/2 with no Unix or Linux experience.

Second, on Windows I wanted a language that was a main Microsoft language with their best integration with .NET, ADO.NET for access to SQL Server, ASP.NET for access to the Microsoft IIS (their Web server software, _Internet Information Server_ ), etc. I wanted Microsoft's best documentation.

For performance, I wanted a compiled language.

And I wanted a language with syntax and semantics that were _traditional_ and easy to read, write, teach, and learn. I did want to avoid the deliberately _idiosyncratic_ syntax of C also borrowed by C++ and C#.

I have no interest in _functional programming_.

So, I settled on the .NET version of Visual Basic .NET.

For the language, I'm just thrilled with it. For my startup, for the on-line production code, I've typed in 80,000 lines of text with about 20,000 statements in Visual Basic .NET.

I find the language syntax and semantics easy to work with. The compiler is nicely fast. I am not sure I have yet found a bug. How the language works with IIS for developing Web sites is just terrific and, apparently, not commonly, clearly explained.

Oh, and I use no IDE ( _integrated development environment_ , e.g., Visual Studio) and, instead, just type into my favorite text editor and use some command line scripts.

My main _beefs_ with Microsoft are (1) I wish the quality of the technical writing in their documentation was much better and (2) I wish Windows was much less vulnerable to computer _malware_.

But, for the question here, for a language, for me and my startup, it's Visual Basic .NET. I'm thrilled with it.

For client side code:

I use just some simple, old version of HTML with a little, simple CSS. For my Web pages, so far I have yet to write even a single line of JavaScript although Microsoft's ASP.NET writes a little for me. From what I've seen of more in client side programming in Web pages, I want as little as possible.

<comment><USER44> >idiosyncratic syntax

How is something like `Dim x as Integer` not idiosyncratic?

>syntax and semantics that were traditional

What's more traditional than C's syntax?

I'm not going to tell you that you shouldn't use VB, but those reasons are BS.

<comment><USER45> > What's more traditional than C's syntax?

Not OP, but I see where he's coming from... He said his background is in IBM mainframes/minicomputers. VB's syntax is closer to the languages those systems commonly used, such as COBOL and RPG.

</comment></comment></comment><comment><USER46> If it's a purely learning project for myself I would usually pick a new language which I would like to learn.

If it's not, you owe it to your client to have an open discussion about which backend (and frontend) language to select. If you are working with a contract, remember that you are only selling your services as a software engineer and that the client will eventually own the code (unless there is some other agreement).

</comment><comment><USER47> It's more about frameworks than languages.

You're already learning 2 languages a year. That's not so hard. The surrounding tech is the bigger investment.

</comment><comment><USER48> For companies with existing technology stacks try to reuse existing knowledge (JNode, Java, .Net, ...).

For companies "starting from scratch": analyse possibilities and make a strategic decision about your technology then try to stay with it and build up the knowledge along the way...

In 1996 I made a decision to use Java everywhere where it is possible and I sticked to that decision up until today, so I prefer Java...

</comment><comment><USER49> For a personal project I usually prefer to get done with development as quick as possible so I choose the one which I am most comfortable with.

</comment><comment><USER50> As some others have stated, if the problem domain is well understood, choose a new language you have an interest in learning. If it is not, it is better to stick with a language you already know. If you add a new technology to a problem domain you do not understand, there is a higher probability that you will create errors and headaches for yourself.

</comment><comment><USER51> Personally I've agonised about whether X language has the best support, community, performance and whether it's the cool thing right now.

But if you're starting a project and you're strong in a language/framework already, just use that. Otherwise you'll spend months learning a whole new ecosystem instead of building the damn thing!

</comment><comment><USER52> If pretty much the same things can be achieved with all these languages, then the difference is not in the language itself but on other things like community, learning curve, availability and price of devs. With that in mind I would prefer Python or NodeJS.

</comment><comment><USER53> We are looking at Goa ([http://goa.design](http://goa.design)) because it's Go and it generates a suite of extra tools and goodies. (API server, swagger spec, JS client, Go client, CLI tool, tests, docs)

</comment><comment><USER54> Choose a language that has robust exception handling and that enforces a reasonable level of correctness at compile-time. Also, realize that checked exceptions are your best friends, although you might not always be able to handle them.

</comment><comment><USER55> I say you're all wrong, the best language he/she should use is this: [https://en.m.wikipedia.org/wiki/Brainfuck](https://en.m.wikipedia.org/wiki/Brainfuck)

</comment><comment><USER28> I am surprised I haven't seen HN's typical love for Haskell in this discussion, yet.

(I do like it well enough, that I might even decide on my project on what I can write in Haskell. People usually go the other way round.)

</comment><comment><USER56> I usually pick Java for projects I know I'm going work with other since most programmers know Java. If it's a solo project, I'll pick a language I want to learn, so I can get some stick time with it.

</comment><comment><USER57> On the dynamic side of things I'm getting curious about Gemstone/S. Using Smalltalk as backend would have a huge productivity impact.

On the static side, Swift in the backend might be interesting.

</comment><comment><USER58> First I look "which technology stack will suite the project best"

Then I remember that I'm bad at looking into the future and stick to "the technology stack I know the best"

</comment><comment><USER59> Scala is missing from your list, it has a wider adoption than Clojure and battle tested stack of frameworks/libraries such as Play, Akka, Slick, Spark just to name a few.

</comment><comment><USER60> Inertia. Unless they're looking to extend a VB4 app without contemplating .NET I generally go with what the client already has. Boring answer sorry.

</comment><comment><USER61> I use a language that I enjoy hacking. These happen to correspond to languages I understand very well in case I need extra features.

</comment><comment><USER62> For a growing number of applications, the correct answer is WordPress and whatever plugins needed to turn it into what you need.

</comment><comment><USER63> SPA that needs client side rendering -> node Need WS, soft realtime, HA -> Elixir

</comment><comment><USER64> Maybe you don't need a language at all for the backend (PostgREST)

</comment><comment><USER65> I'm surprised you don't have a default language.

I just always pick Python.

</comment><comment><USER66> 1- Based on past experience

2- Scope of the project

3- Cost

4- Duration

</comment><comment><USER67> First revel in the fact that you actually get to choose :-) most programmers just get to play with a choice someone else made.

First of all, are you going to be the product owner, or is this a consulting gig you're gonna walk away from? If the latter, chose what allow you do get the job done for the least amount of hours. As your reputation grows for getting the job done in few hours (cheap) you can increase your hourly rates. You don't need to read on. Also, if you're sure that no bottle neck is going happen. Meaning that the user will always get a response in less then 0.3 second, some thing. use whatever will get the job done fastest. In which case you should be looking at what components (like Databases, search engines, etc) are out there that allow you to get the job done fastest. Then choose you poison according to those sub systems. There is an argument for easy maintainability, in which case it comes down to how you tend to debug. I tend to use debuggers a lot, and that leaves be with Java from the languages I know from your list.

You need to identify the bottle neck your application is going to have. You're rarely going to be wrong. I tend to operate with 5 bottle necks: CPU Memory Disk Network IPC

CPU: Easy, won't happen. It requires that you've avoided a memory bottleneck, meaning that you've figured out how to feed the CPU with data. There are only three languages where this is really possible, C, C++, and Fortran.

Memory: Unusual for a backend project, but possible. Solving it requires that you lay out your data the right way in memory, and you're again basically back to C, C++, and (to a lesser degree) Fortran. Anything with a new operator and garbage collector tend to be bad. If possible try finding an existing piece of software to do the job for you, but it's rare.

For disk and network bottle necks, programming languages don't matter.

If disk bound you need to try picking a sub system that do proper caching for you, like a SQL, NoSQL, or other system. Your design choice here will be on what you base your language decision.

Since you say backend, I'm assuming that you're on a web or mobile app frontend. In all likely hood, this is the bottle neck you're going to face. You should be concerning yourself with the frontend to backend interactions, not programing languages. Web frameworks and proper use of AJAX are more important. Worrying about languages is like worrying about getting a Ford model T, a Pinto, or a F-150 for a indy 500 or formula 1 race. You've asked the wrong question.

IPC! Strictly not a bottle neck, but a problem that occur a lot. Remember that a IPC call take about 1 000 000 times longer than a method or function call within a program. You have to assume 40ms latency from the frontend to backend. Calling web services, database requests within you backend if you spread it over multiple servers have a 1-10ms latency. You can assume 5-10ms in practice. Trying to keep a response time for a user interaction below 0.3s, i.e 300ms you should realize that you have a tight budget for IPC calls. A backend operation that involves 1000 DB requests is just not going to get done in 300ms. If you know that your DB operations will be the bottle neck, avoid ORM's like hibernate. You're going to be spending your time making DB procedure and optimizing SQL. If you're going to have a lot of business logic, chosing a language that don't lend itself to writing large programs may run you into trouble. It's tend you to keep programs short and use IPC to call the business logic. As a result I tend to stick to Java. Well, have been doing a lot of C and C++ stuff earlier in my career, so I tend to be a little biased. On the otherhand, have been wringing a lot of frontend logic in Javascript as well, and detest the language.

Hope this helps.

</comment><comment><USER68> I choose languages based on what is best suited for the project. That is determined by the architecture of the project (is it a SPA or a more Ye Olde Fashioned web site? Is it just an API? Does it need web sockets? etc.)

The architecture is dependent on the requirements. Who will maintain this once I'm done writing it counts as a requirement. If I'm making it for someone else and I won't be maintaining it, and they don't have someone on hand to maintain it, I might not want to write it in Clojure or Node because it might be harder for them to find someone who can work on it affordably than if I write it in PHP or Ruby.

Sometimes multiple languages will be equally suited to the same type of project, in that case I go with personal preference. But that's very rare. Usually there's some good objective criteria like those listed above which will help you nail it down.</comment>


How far professional photography equipment has come in 10 years - <AUTHOR> http://fstoppers.com/pics-iso-performance-of-cameras-at-the-2001-super-bowl-vs-today

<comment><USER2> (ads + 70 words) tldr; 2.7MP vs 12MP</comment>


Maxthon browser vulnerable to Chinese cyberespionage and MitM attacks - <AUTHOR> http://www.scmagazine.com/maxthon-browser-sends-personal-data-to-china-and-vulnerable-to-mitm-attacks/article/509634/ <comment><AUTHOR> This was submitted earlier before any reports in English were available here: [https://news.ycombinator.com/item?id=12094930](https://news.ycombinator.com/item?id=12094930)

From ksdev's earlier comment:

TL;DR: It doesn't matter if you agree to join "User Experience Improvement Program" in Maxthon or not - the browser regularly sends this data to Beijing servers:

      - Windows service pack version,
      - screen resolution,
      - Maxthon version,
      - CPU freq,
      - Maxthon path,
      - adblock info,
      - startup site address,

and the most important:

      - ADDRESS OF EVERY VISITED SITE - full history, with every query entered in google,
      - every ~5 reports - FULL LIST OF INSTALLED SOFTWARE (with exact versions).

English report: [https://exatel.pl/advisory/maxthonreporten.pdf](https://exatel.pl/advisory/maxthonreporten.pdf)</comment>