_ivvf

I measured startup of the runtimes a long time ago, and back in the days of node.js 010.x at least, Python 2's startup time was twice as fast as Node.js's, and Java's wasn't much worse than Node.js. I don't know how .NET fares compared to Java, but I imagine it's about the same.

Furthermore, eople like to compare runtime startup times, but this tells a very small portion of the story. For most applications, the dominant startup cost isn't the startup of the runtime itself, but the cost of loading code the app code into the runtime. Your node.js runtime has to load, parse, compile, and execute every single line of code used in your app, for instance, including all third-party dependencies.

Compare, for instance, the startup cost of a "hello world" node.js function with one that includes the AWS SDK. At least, six years ago, the Node.js AWS SDK wasn't optimized at all for startup and it caused a huge (10x?) spike in startup time because it loaded the entire library.

I would argue that the only languages that are a really good fit for Lambda are ones that compile to native code, like GoLang, Rust, and C/C++. The cost to load code for these applications is a single mmap() call by the OS per binary and shared library, followed by the time to actually load the bytes from disk. It doesn't get much faster than that.

Once you've switched to native code, your next problem is that Lambda has to download your code zip file as part of startup. I don't know how good Lambda has gotten at speeding that part up.

I definitely agree with this stance, and would say that languages like C# and golang have a weaker runtime but try to make up for it in other ways, often surpassing Java in certain areas. For instance, both languages have stack-allocated types to help stress the GC less. C# also has a much better native interop story than Java, as well as the unsafe keyword.

At the end of the day, if you want amazing performance in Java, you have to write C-like code in Java, and that often involves things like managing your own offheap memory, sticking with arrays of numbers, etc. Java's biggest areas for improvement in the performance arena are going to come allowing for stack-allocated types, fully-continugous arrays, less overhead when calling native code, and providing official APIs for the other things you can currently do with sun.misc.Unsafe.

I developed at a Windows-centric shop for several years using C# and Visual Studio, and I can personally attest, at least in 2013, that stock Visual Studio is pretty far behind Java IDEs in its capabilities. At the time everyone I talked to recommended I get my manager to get me a copy of ReSharper, but it wasn't in our team's budget. At least in 2013, here's where I remember C# IDE support was lacking:

* No automatic incremental compilation. It turns out, this feature is specific to Eclipse alone. In my current job I'm forced to use Intellij and cannot figure out for the life of me why people think Intellij is better. Automatic incremental compilation is a game changer and only Eclipse has it.

* Limited Code analysis and search. For instance checkout this SO: http://stackoverflow.com/questions/282377/visual-studio-how-.... This kind of symbolic analysis and code search feels essential to me in an IDE, and stock Visual studio just didn't seem to have it beyond the basics.

* Weak refactoring and code generation support. ReSharper might bridge the gap a little here, but stock Visual Studio felt way behind.

* Weak ecosystem for plugins and tool integration. With Java IDEs I have excellent integration with unit test frameworks, code coverage tools, checkstyle, my command-line build tool, etc. I remember it taking a fair bit of effort just to be able to run NUnit tests in Visual Studio. Why NUnit? Well, our software needed to build on Linux with Mono so we needed to use a cross-platform unit testing framework instead of the one built into visual studio.

As a side note, I think the plugins ecosystem is another area where Eclipse has an edge over Intellij. For instance, when I tried Intellij's code coverage tool I eventually gave up on it because it had a critical bug I couldn't diagnose that resulted in incorrect code coverage being displayed.

I think the candidate made a simple mistake: the interviewer is always right. Your job in an interview isn't to be right or to teach the interviewer. Your job is to make the interviewer like you foremost, and second make the interview think that you're qualified. And of course no one likes being corrected or told they are wrong. In my opinion, it is better to do well on an interview and decide after the fact that you're not interested, than to do a poor job on the interview because you couldn't help yourself correcting the other person.

For instance during one interview I was being asked questions about a particular topic, and I started to guess that the interviewer didn't understand 100% the topic he was asking about. Rather than correcting him, I simply tailored my answers to what I thought he was looking for, not what was right. I passed the interview and got a job offer, whereas if I had corrected the interviewer the results may have differed.

As someone who has recently learned C# and known Scala for a while, I am very impressed with what C# has to offer as a language. However, it is not nearly as well-designed as Scala. Microsoft has piled on feature after feature to the point where many C# are features either mostly deprecated and replaced by newer features or else do not mix well with new language features. Some examples include:

-generic vs non-generic types. For instance, when using the Process class, you have to use StringDictionary.

- Actions and delegates vs lambdas. This is made more painful by the fact that C# handles the void return type specially, so that there is no way to create a Func<void>. Also, it means that if you want to support higher order functions that support both a void and a generic return type you have to write two different functions.

- ref and out parameters with lambdas. They just... don't mix!

- out parameters vs 4.0 tuples. Really C# needed syntactic sugar for multiple return types long ago, but the idiomatic way to do this in C# is with a feature that simply does not play well with functional programming.

There are other things that make Scala nicer as well.

-In Scala every statement is also an expression and Scala has the bottom type, which again makes writing functional code much simpler.

-Scala's collection's library is superior. It has functional collections and it's design enables overriding methods to have much more sensible static return types.

-Scala's way of extending class functionality with implicits is more powerful and object-oriented than C#'s extension methods. In fact, Scala in general feels much more OO than C#.

-Scala has a form of controlled multiple implementation inheritance (traits) that I really miss in C#.

These are just the practical things I can think of on top of my head that I miss in C# versus Scala. On the other hand, I get the impression that C# was originally designed to be a more performant Java by hybridizing it with C++. It's richer value type system, the fact that class methods are non-virtual by deafult, and the ease by which one can drop into unsafe code mean that one can port a lot more performant C-style code to C# than on any JVM-originating language, which I think is C#'s greatest strength compared to Scala.

Still, I think if people gave Scala a chance they would find it to be a very clean, productive, and well-designed language compared to C#. That alone may not be enough to convince people to switch to Scala in droves, but enough so that people who want to target both platforms will be willing to consider Scala as a solution rather than to use something like Mono.