Hacker News Reader

Comment by iamelgringo | Hacker News Reader

I know this is heresy around here, but have you looked at F#? It's functional, has type inferencing, even in the dev environment, straight forward parallel versions of functions (pmap vs map), async IO, amazing dev tools, a REPL inside of Visual Studio, access to all of the .NET libraries. And, chances are, it's going to be around for a while.

You're absolutely on the right track. As startups struggle to hire, new startups should be looking to off loading more and more of their work to more productive programming languages.

View on HN

Is it counter productive in an environment where hiring is difficult to go too niche though?

Our entire server codebase, baring a few external libraries, is Scala (working with Lift) which has been an awesome experience but there is a nagging doubt in my mind that if/when we need to start looking to add in developers we will either need to invest in cross-training a java dev or end up paying out probably more than we could/should afford to get a seasoned java dev who trained themselves in Scala already. If over a short period of time your choice gets some major traction then it will work in your favour, but if not then you could be out in the cold or risking employing someone with no real provable history.

You might not want someone who can't learn a new language.

If a developer is so much more productive, why shouldn't you pay a premium for their skills?

Remember in business there is no "cheap" or "expensive". There's only "worth the money" and "not".

How do you know if they are productive before hiring them?

Someone who is "a seasoned java dev who trained themselves in Scala already" will have a track record of Getting Stuff Done of course. Also see http://www.paulgraham.com/pypar.html

far easier said than done. Have you hired a lot of people? What form does their track record come in? A list of projects on their resume?

Yes, actually :-) Most people's CVs (we call them) are pretty poor indicators of their abilities (because, no fault of their own, they take other people's bad advice on CVs) but all I talk about in interviews is, what have you done and what difference did it make. I'm not perfect at it by any means, but my hires usually work out pretty well...

I wasn't trying to give you a hard time. I've been hiring for years and it's really hard.

That's only sometimes true. There are plenty of intelligent developers learning the newest and coolest languages who'd I'd never hire.

Why? Because learning cool tech and Getting Stuff Done are two very different things.

While it is true that most developers suck at writing code, knowing Scala doesn't tell me whether you:

1. Have enough discipline to do the boring, tedious parts of your job 2. Know how to prioritize tasks 3. Can write easily maintainable code 4. Can work well with others.

Technical ability is only one part of an employee.

I quoted the word "seasoned" too for a reason!

Well, Jane Street Capital uses OCaml. According to "Caml trading"[1], hiring got easier when using OCaml:

"Personnel is one area in which OCaml has been an unmitigated success for us. Most importantly, using OCaml helps us ﬁnd, hire, and retain great programmers."

1: http://www.janestreet.com/minsky_weeks-jfp_18.pdf

To be fair, Jane Street probably is helped in this regard by being able to pay great 6 figure salaries and 6 figure bonuses to their developers.

I think we need to compare apples to apples here: other competing hedge funds may have to pay a lot more to have those hackers code in C++, Java, or (gasp) VBA.

Fair point.

... to a workforce that can jump ship to a competing firm for a similar package at any time. Retention is a strategic advantage in any industry where the "means of production" are between your employees ears.

Chances are that basing your startup on Scala/Lift is probably going to be a net plus for you when recruiting new staff. It says a lot about the technology culture at your company that you are using a functional language. It's also something of a weeder. If an engineer can't wrap his head around Scala in short order, you probably don't want to hire him. My guess is you'll probably have to hire a lot less frequently than a typical Java shop.

But isnt there also experience to consider? I'm sure a smart person can pick up any language but it always takes time to learn the idioms, gotchas, apis and supporting tools, i believe

I'm willing to keep my mind open.

How long it takes to set up a dev environment and push to cloud service?

With appengine, 1) I sign up in 5 minutes, 2) clone an app in python or Java, 3) use my favorite free ide to edit the code 4) appcfg.py update

Also, if I don't have any of the tools like git I just type: sudo apt-get git-core

Heroku on AWS is just as easy.

Can you provide a link showing how easy it is to get started with F#?

Hang on, I thought the author deliberately ruled out GAE because its performance is too ropey.

Also step 2 sounds like magic and a recipe for disaster. Clone an app? What, with all its settings? Random library includes you weren't expecting?

Don't confuse well trod paths with new roads, closure and F# are both new roads, you'll need to do a bit of work yourself.

Also visual studio has a free edition these days.

Anyway, my point is don't compare apples to oranges when the author said he can't use apples.

Yes Github is magic ;)

Last weekend, with no prior knowledge of JavaScript on the server, I created a full NodeJS, Express, Coffeescript, Jade, NPM stack and had it deployed to my linux VPS in less than a morning.

It's my understanding it's not so easy to do that kind of learning and experimentation on Windows.

I'll have you know that Windows is every bit as easy to experiment and learn on. Microsoft go out of their way to make developer and sysadmin's jobs as easy as possible. New versions of the .net framework can be installed without restarting any services, all previous versions will keep running in parallel, etc. etc. Don't dis it till you've tried it.

I don't know why you think that, it's just as simple.

Go to http://www.asp.net/get-started.

Although I would recommend going down the MVC route as asp.net forms are sucky. http://www.asp.net/mvc

I know there's an anti-MS tendency round here, but fast experimentation is just as easy with MS these days as it is with everyone else.

The only gripe I've got with MS these days is that they seemed obsessed with videos, which are irritating as you can't go at your own pace (i.e. faster) and it's a nightmare when you just want to find that way of doing x that you remember seeing in the video but not at which point.

And AppHarbor is making it even easier to deploy .NET projects (YC funded) http://appharbor.com/

> GAE because its performance is too ropey.

It's much worse with Java. Instance startup times are a lot higher.

> Clone an app? What, with all its settings? Random library includes you weren't expecting?

In Python, at least, you just edit app.yaml and change app name and version. If there is a settings file, you also edit it. And libraries that are not provided by GAE should be included in the app, so, you are bundling dependencies Java-style.

> Also visual studio has a free edition these days.

Unfortunately running Windows takes away many nice things for developers.

>> Also visual studio has a free edition these days.

>Unfortunately running Windows takes away many nice things for developers.

This. Having essentially one choice in monolithic IDE which doesn't really provide anything novel you can't get elsewhere, without a nicely integrated POSIX shell and all the useful stuff that comes with it is a net lose IMO.

Since F# is a .net language any ASP.net web host will be able to serve an app written in it.

Definitely check out appharbor.com, I think their goal is to be a "git push" away from deploying any .NET (F#/C#/VB.NET) app. I've not used them though.

To be honest I've never given F# much of a chance. Mainly because I do most of my development on Mac OS X or Linux. But I've seen some cool introductions on F# and the integration with Visual Studio (mainly from CUFP http://cufp.org/videos/keyword/59). I'll be keeping my I on it. Thanks.

The latest version of Mono apparently ships with F# support:

http://www.mono-project.com/Release_Notes_Mono_2.10#Language...

Now I just need to find the time to try it out...

Not everyone wants to use the .NET ecosystem for any number of reasons. When doing purely windows development, it is my first choice, but if I want to do cross platform or web development even with Mono out there the appeal just lacks to me.

I will agree though that F# is a beautiful language, and am hoping on getting everyone else at work on board so we can start using it more for our development.

You'll have to restrict your servers to run Windows. That's something not everyone wants to do.

F# runs on mono, which runs pretty well everywhere Clojure will run.

The F# mono implementation is somewhat slower than the .Net implementation though, so there is that caveat.

F# on Mono seems to be a lot slower than Java 6, at least in the Shootout (2x to 12x). I don't know how that stacks up to Clojure, though I understand that Clojure can be much more performant with tricks like type hinting.

On the other hand, F# does use less memory.

http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

I really dislike the shootout, but F# on mono and Clojure (which is slower than plain Java) look pretty similar:

http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

For whatever it's worth, if you like Clojure, use Clojure. If you like F# use that. If you like Perl, Java, PHP, use those. But, if you're going to consider other options hopefully the FUD doesn't get in the way ;).

If you really dislike the benchmarks game, don't look at the benchmarks game and don't show it to other people :-)

OK, igouy, somebody has to defend the Benchmarks game (!?)

Most FP communities (incl clojure) have devote non-negligible blocks of time to code review and benchmarking to make sure that at the very least poorly written code isnt' submitted (and the right hotspot knobs are on).

http://groups.google.com/group/clojure/browse_frm/thread/d27...

I did not "defend the Benchmarks game".

I pointed out how comical it is for someone to declare they dislike (who knows why?) the benchmarks game, and then present the benchmarks game to others as a reliable source of information.

I didn't present it as a reliable anything. I pointed out that the parent had linked to the wrong comparison, and linked to the correct one.

I'm happy to be corrected about what you intended us to understand by your comment.

(However, although you provided a different URL you did not point out that you thought the parent had linked to the wrong comparison.)

I thought placing emphasis on the correct one was enough; evidently I was mistaken.

The parent was correct about what their link showed - "F# on Mono seems to be a lot slower than Java 6".

You didn't just "correct" the link to show F# and Clojure.

You changed the link from quad-core to single core and that reduced the difference shown between F# on Mono and Clojure.

Come on dude, is it that hard to change the dropdown yourself??? The parent was talking about CLOJURE and linked to JAVA's RESULTS

Look, the results aren't usefully different: http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

You can easily get from the quad-core Java:F# to quad-core Clojure:F# by changing a drop-down but that isn't what you did.

You do seem to be using the what you dislike and what you are not presenting as reliable to suggest "F# on mono and Clojure (which is slower than plain Java) look pretty similar".

If you really dislike the benchmarks game, don't look at the benchmarks game and don't show it to other people :-)

Let's ignore your guesses about "most FP communities" and look at your example -

iirc Andy Fingerhut started benchmarking Clojure programs more than a year before Clojure was even included in the benchmarks game.

https://github.com/jafingerhut/clojure-benchmarks

Here's another thread "Comparing clojure speed to java speed" which has nothing what-so-ever to do with the benchmarks game -

http://groups.google.com/group/clojure/browse_thread/thread/...

(Incidentally, those "hotspot knobs" made the Clojure programs slightly slower but forced collection of the temporary objects that were showing up as much greater memory use than the Java programs.)

Clojure can utilize all libraries available for Java, and all invocations of those libraries will have the exact same speed any java application would have (Clojure itself isn't slow either, but that's a different topic).

I never attemped to actually use Mono, so please correct me if I'm wrong, but if I understood correctly, Mono has to duplicate all .NET frameworks, libraries and tools, which means Mono

a) is not complete (e.g. Silverlight, VisualStudio)

b) will hardly ever keep the pace of development of Microsofts implementation (simply due to resources).

Mono may be viable if you are happy with a subset of the .NET ecosystem, but I'd really feel more comfortable if I have access to all of Java with Clojure. Chances are you do need that library...

Mono can utilize all the libraries available for .Net, with a few exceptions (which are well known and documented on Mono's site here: http://www.mono-project.com/Compatibility).

Mono is a complete implementation of the C# specification, additionally, the Mono project has ported many .Net libraries.

Moonlight is the Mono version of Silverlight. Visual Studio is an IDE, and doesn't have anything to do with Mono vs .Net (in the same way IntelliJ IDEA has nothing to do with Java portability). You can write code in Visual Studio and compile it with Mono with no problems. You can also use MonoDevelop on OSX and Linux.

The time between Microsoft releasing new versions of .Net / C# and the Mono implementation is very small, usually weeks but sometimes only days. Unless you need to work on the bleeding edge right now, I don't think that it really makes much of a difference.

Yes, you can write C# in a way that isn't portable, especially if you use libraries that are OS specific. You can do that in Java as well (or any other language). Just look at all the libraries that require epoll or kqueue - those won't run on Windows no matter what language they were written in.

It's unfair to say that Mono requires you use a subset of the .Net ecosystem. If you want to write cross-platform code, you will always be constrained to a subset of the libraries.

C# is a nice language, especially with Linq (which is in Mono). You should spend a weekend with it sometime to form an opinion :D. MonoDevelop works fine on the mac and is free.

Also, some recent MS libraries for .net are released as open source (e.g. MVC) and consequently work just fine on Mono when released.

May I ask why F# is considered heresy?

Because it means you're (probably) going to be running Windows on your servers, which isn't cheap.

The cost for windows isn't really a pressing concern for business--even startup business.

But the thing is if you go with windows, you're eventually going to have to support linux too just to get a the wealth of open-source codebases like say Redis. I mean its certainly possible to run Redis on windows via cygwin but you're 32-bit limited, and its a pain to actually install and get everything working.

On Fedora it's "yum install redis", and you're done.

Can't Redis run on Windows proper? I thought I've seen actual Windows builds of Redis?

The last I heard Redis on windows native as a wontfix: http://code.google.com/p/redis/issues/detail?id=34

That's simply not true, BizSpark makes the cost of Windows into a rounding error.

That may be so, but how readily can you automate server setup? I am getting pretty handy with ubuntu VMs plus apt to get from a fresh install to "entire stack installed and configured" in an afternoon. The fact that nearly all of the software is available freely online speeds things up for me.

Simply because it's Microsoft. That was partly tongue in cheek. :)

I think the biggest impediments to F# adoption:

to somebody not already a C#'er is the cost of Visual Studio: You really want that concurrency profiler, which I think is only in the Ultimate SKU (for which MS is giving away licenses in Bizspark, dreamSpark).

And a fair number of Csharpers I've met recently (admittedly a small sample) will tell you FP and the parallel/concurrent libs in C# are good enough: TPL, the .NET 5 Async lib (Basically they'll tell you about all the C# stuff in Petricek's book, without looking into what F# can do for them.

Reply on news.ycombinator.com