Turning a Furby into an Amazon Echo - <AUTHOR> https://howchoo.com/g/otewzwmwnzb/amazon-echo-furby-using-raspberry-pi-furlexa <comment><USER2> _" Furby is comprised of a few primary components -- a microprocessor covered in black resin (to protect Tiger Electronics' intellectual property)"_

Wishful thinking. It's chip-on-board technology, which lowers the cost of the final product. In the toy business, every penny counts.

Anyone can decap a chip package these days, the COB resin is not any more secure.

[https://learn.sparkfun.com/tutorials/how-chip-on-boards- are-...](https://learn.sparkfun.com/tutorials/how-chip-on-boards-are-made)

[http://www.ue.com.hk/index.php/Saving_Cost_- _Bare_Die_Assemb...](http://www.ue.com.hk/index.php/Saving_Cost_- _Bare_Die_Assembly)

</comment><comment><USER3> During the video he says, "Furlexa, tell me about furbies". My echo dot heard this and proceeded to tell me about _Herpes_.

<comment><USER4> That's because the results are personalized.. ;p

</comment></comment><comment><USER5> Disappointed that it doesn't lip-sync (like [https://www.youtube.com/watch?v=bRxhgxH6FUI](https://www.youtube.com/watch?v=bRxhgxH6FUI))

<comment><USER6> I think this is primarily the fault of the mechanism that handles the... beak(?) movement. I believe opening and closing is a continuous loop on reduced gear motor. Getting that to synchronize is difficult, especially as the echo just hands you back an mp3.

</comment></comment><comment><USER7> It would be really cool if it modulated the Alexa voice to sound like a Furby too!

<comment><USER8> And if the mouth would be more aligned with the talking, but the engine is probably not strong enough.

But it seems that the echo-light is somehow coupled to the eyes, which is nice.

</comment></comment><comment><USER9> This would be awesome to do with one of Hasbro's "Furbacca".

</comment><comment><USER10> It's crazy to me that these things have only one motor that controls their eyelids, ears, mouth and their base.

</comment><comment><USER11> Is there a product like this just for kids: a furry, friendly, interactive, mobile, voice-based connection to the internet? It could be an early learning tool (and source of great annoyance and surprise hilarity). Kids could learn to make apps for their wrapped Alexa, apps that help them help themselves and their friends, parents, etc...

[I am now imagining the _Star Trek_ episode "The Trouble with Tribbles" where all tribbles are Alexa wrappers... X_x save me!]

<comment><USER12> It would be a security _nightmare_ and you'd be targeting kids.

<comment><USER11> Hm, yeah, maybe a DIY or Kit is better than full-fledged product. But is it just as bad as giving your child an iPad with Siri?

<comment><USER12> In the case of the iPad they get to say they're not targeting kids specifically and the rest is on the parent, but oh god yes I agree with the point you're making.

</comment></comment></comment></comment><comment><USER13> Cute. Playing the video constantly had my own Amazon Echo answering the same questions.

It's not clear how much the Alexa Voice Service would cost in a commercial product?

<comment><USER14> The device SDK appears to be Apache2-licensed: [https://github.com/alexa/avs- device-sdk/blob/master/LICENSE....](https://github.com/alexa/avs-device- sdk/blob/master/LICENSE.txt)

... so I guess at no cost?

<comment><USER13> I can understand the SDK being free, it would seem strange to me that a commercial product could actually plug in to the service for free, and without limits.

<comment><USER15> Ultimately, the service enables people to order from Amazon and gathers training data for their algorithms, so regardless of whether you're using it through an Echo or a Furby or whatever else, they win.

To put it bluntly, why would they stop others from making their profitable data collection easier and doing it for them?

[https://en.wikipedia.org/wiki/Amazon_Echo#Privacy_concerns](https://en.wikipedia.org/wiki/Amazon_Echo#Privacy_concerns)

</comment></comment></comment></comment><comment><USER16> Want one. Now. My daughter would freak on christmas.

</comment><comment><USER17> I wonder if the finished product is smart enough to distinguish between Alexa "speaking" and playing audio. It would be really annoying to constantly hear those gears moving while listening to music.

On the other hand, I'd love to code the pi to randomly make the eyes blink and move on occasion.

</comment><comment><USER18> I'm interested in how the author got the sound working. I would have thought that external usb dacs would work just fine, as they seem to be plug and play compatible with just about everything, but apparently that isn't the case. Could somebody elaborate?

</comment><comment><USER19> Science has gone too far

</comment><comment><USER20> Sounds like a great way to train children to interact with and trust corporate mass surveillance because it's "cute" and "fun".</comment>


Ubuntu and open source help the City of Munich save millions - <AUTHOR> https://insights.ubuntu.com/2014/07/07/ubuntu-and-open-source-help-the-city-of-munich-save-millions/

<comment><USER2> The costs seem to mention training and support, but not comparing productivity makes it useless. It's like arguing that you can use the Gimp rather than photoshop, which is only true until you try.

The whole point of software is that it increases productivity (word processor rather than typewriter). While it may be the case that Linux and open source alternatives saves a bunch on licenses, I don't buy the argument that it is an amount "saved" until thurough research is made in the productivity of the users.

<comment><USER3> One might as well expect productivity to _increase_ switching away from proprietary software. I would, at least.

Taking your example of Gimp, I expect institutional adoption of free software would result in some people having it who didn't have Photoshop at all before. They can now become more productive and take less of other people's time.

<comment><USER2> Well, it could work either way I suppose, but in my experience, usability/productivity of desktop software is severely lacking in OSS software (unlike e.g server software). Perhaps due to problems attracting non- developers to work on them. Polish is expensive, but polish is productivity.

The potential upside like you mention would be more licenses at lower cost. Whether that was a bottleneck depends on the organization in question. Either way I don't think it's possible to make any conclusions without research.

<comment><USER4> I'd expect a loss of productivity from using OpenOffice that far exceeds the cost of Microsoft Office, plus ongoing losses in productivity as staff try to cope with its incompatibilities with complex Office documents that probably arrive on a daily basis.

However, staff productivity is not generally a major concern in local government offices, as far as I can tell. Maybe Munich is different, but I doubt it...

</comment></comment></comment></comment><comment><USER5> I am not at all surprised that this worked. The biggest problem for mainstream linux is poor advertising. People with limited computer knowledge are just scared of change, and honestly, if no one knows how to pronounce Ubuntu then they are probably not going to pick a computer based on it.

I mostly use Windows 7 and OS X, but I have worked with Debian/Ubuntu as a casual user. Linux was much easier to work with than Windows 8.1, but 90% of the population doesn't know that. Most people would be as happy, or happier with Linux if there was just one big advertising campaign.

<comment><USER6> Well, Linux is now the most commonly used general purpose OS/kernel in the world. Every Android device, every Chromebook device (plus all the regular desktops and servers).

I can't help but feel that part of Android and Chromebook's success is in part due to the users not understanding/having-to-know they're running Linux. Android and Chromebook don't even mention Linux anywhere, and users are content. I think regular Joe's have a stigma about Linux, and just abstracting that aspect away has helped adoption.

<comment><USER5> Android may _technically_ be Linux, but I am not sure I would count it as a step towards changing the desktop computer people get for their home. Chromebook is similar- as far as I can tell it just runs one browser window. This makes it more like a video game system than a PC.

<comment><USER6> In industrializing parts of the world, mobile devices are often the only access to the internet and software (and sometimes the first experience with a computing device).

Chromebook/ChromeOS is much more capable now than it used to be, with multi- tasking and multiple "apps" can be on-screen at the same time.

</comment></comment></comment></comment><comment><USER7> What about long-term compatibility of Microsoft (or Apple) products? How can proprietary, maybe even binary file-formats be accessed in 100 years from now? Cities usually keep their books forever. I have so many files from the nineties that are already very difficult to restore. I could imagine that open source formats have a huge advantage here?! #LongtermCosts

<comment><USER8> When a document stops being a document and becomes a record, it should be saved in a format such as PDF/A for longevity, and not a binary format. That would be regardless of if it was created in libreOffice or Microsoft Office.

</comment></comment><comment><USER9> It reminds me [http://xkcd.com/934/](http://xkcd.com/934/) for most simple users. What a government officer do at his/her workstation? They probably have every service through web pages, almost nobody builds native programs anymore. And for the most cases LibreOffice is not perfect, but adequate to do simple jobs. So it is very logical to use something free for these tasks, to replace Windows+Office and save money.

<comment><USER10> I really wonder if LibreOffice is not totally adequate for the users in the city of Munich.

I know that it has its problems if you want to use it with Word generated documents, and it obviously has problems with add-ons developed for Word.

But I could really think that it works quite nice, if all your documents are generated for LibreOffice.

I am using Open / LibreOffice since nearly 10 years exclusively at home and I don't have any problems using it - but my needs are VERY modest. Basically I am using it as an WYSIWYG typewriter.

<comment><USER11> I think this is really sad. As someone who went through university when the last wave of centralized unix died off, then the move to decentralized windows, and to decentralized linux (because they couldn't really figure it out mostly).

I found that move to decentralization and the availability of compilers and tools and dev. environments and easy ways to get admin privileges, well I credit that with my learning how to code/admin/... and to my succes later in life. These computers, I've heard from a friend, are LOCKED down. As in, try to compile anything against a GUI library is a complete non-starter. Compiling anything under linux without root is almost impossible.

Add to that that even the development environments that do exist on linux are ... well sorry to say but let's be honest here ... far inferior for learning to code and to writing simple games than the ones available on windows.

Nobody's going to learn how to use computers, how to program and how to improve their situation on these linux machines. And that sucks.

But hey, easier on the admins !

(not that it's anywhere near as bad as SAAS though)

<comment><USER12> _Compiling anything under linux without root is almost impossible_

This is bizarre, and very much not true. If you have a C compiler and sufficient disk space you can build whatever you want in your home directory. It might take a while, but most things that use autoconf will accept `--prefix=/home/user/stuff/` and target that location.

Not having a C compiler is rare as it tends to be deep in the requirements chain of other packages. For other languages, I believe Python is mandatory on Redhat and Perl on Debian, if you don't mind old versions.

</comment></comment></comment></comment><comment><USER13> Is 2014 the year of Linux on desktop?

Joke aside, it makes me happy to see the transition from Microsoft to Linux has been a success. I remember reading the news headline when they first announced it. I wonder how many of the 22,000 government officers that use Ubuntu at work are now also using Ubuntu at home?

<comment><USER14> Honestly, it is going to take a while.

The display drivers needs a lot of work (intel seems solid). Also, desktop itself needs to be super stable.

Also, the software (from companies) is treated like a second-class citizen. Chrome is horrible on linux, --disable-gpu --audio-buffer-size what user is going to bother with that?

I have to do all these tweaks and workarounds to get things to work. Regular users will not have the patience do this.

The year of LOD will only happen when everything is stable and works. Imagine if CentOS, Debian, or Ubuntu on a server were this flaky? Would you use it? This is why people jump ship to Mac.

<comment><USER15> > Chrome is horrible on linux, --disable-gpu --audio-buffer-size what user is > going to bother with that?

Really? Chrome is a first class citizen on ChromeOS, so I'd expected other linuxes to be well served, too.

<comment><USER16> My biggest gripe with Chrome on Linux is you can't change the default behavior of clicking in the address bar. In Firefox I can make it so clicking once selects everything. In Chrome, it drops a cursor and I have to click two or three times to get it to select everything. I understand some people want that behavior, but I don't. The Chrome team's response is that this is the Linux default and Chrome is a native Linux application, so that's how it behaves and it can't be changed.

No thanks.

<comment><USER17> I'm currently running Chrome 35.0.1916.153 on Ubuntu 14.04 with XFCE and clicking once in the address bar highlights everything all. Don't know why mine is acting different than yours, maybe they changed that since you last tried it.

<comment><USER16> I last tried it years ago, so it's possible they changed it since then. When I read that response on their forum, I completely gave up on Chrome and haven't touched it since then. I don't care if "it's not the Linux way" [1], it's _my_ way and who is Google to tell me otherwise?

Sorry, I'll end my rant now.

[1] [https://code.google.com/p/chromium/issues/detail?id=26140#c1...](https://code.google.com/p/chromium/issues/detail?id=26140#c14)

</comment></comment></comment></comment></comment></comment><comment><USER18> The numbers don't make sense to me. €34 million across 14,000 computers is about €2500 per computer. That seems a bit on the high side for the sort of computers a municipality requires. Particularly when an older computer provides suitable performance (otherwise the Linux boxes would need comparable upgrading).

I'll add that a better comparison might be to the cost of Windows machines running open source productivity software since the comparison is closer in terms of specification.

<comment><USER19> Except it isn't - you need to consider the costs of not just Windows, but all the software surrounding it. Photoshop licenses, Visual Studio licenses, Office licenses, etc. Even at business rates. Per workstation, $3000 can be an underestimate.

Meanwhile, using Gimp / Krita / LibreOffice / kdev etc and, at the scale of a city like Munich, just having a dev team to fix the localized problems the city has in the software, or having a fund to bounty bugs and features the city wants, would be cheaper in the long run, and leave the city in control of its own software infrastructure.

<comment><USER20> Not to mention the big kahunas, Exchange, Sharepoint, AD, SQL Server licenses.

<comment><USER14> Is there an opensource alternative for Sharepoint?

<comment><USER21> SharePoint is a Jack of all trades, master of none so based on you requirements you have to choose the right tool most of which are OSS or at the very least non depended on Windows

<comment><USER14> Could you name few? Anything would be helpful.

<comment><USER21> It really depends on your requirements. What is it that you need? Like any software SP is a tool, just like home improvement you don't go out buy a tool and than try to use it for what ever task is in front of you (you might end up with a screw driver while you really needed a hammer). So I could make a list of Document Management, Content Management, Intranet, etc software but the correct answer depends on your needs since there are lots of choose and all (some) have there own strong and weak points.

SP is a mesh up of several software suits slowly coming to getter, it is getting better every release. SP could also be the right choice depending in your needs. Mainly work group portals but those tend to fail (as in not being used) since most of the time there is no proper business case nor business processes in place to support the grand idea

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> I'm very impressed with the scale of the project. I can definitely see both the short term and long term ramifications and huge huge huge potential savings.

I'm a bit curious to know what the shelf life on the OS choice is and how well it works. I believe redhat ran into this issue and adopted the "extended support" versions in order to address the concerns (the linux space tends to move _very_ quickly in directions and you can definitely be left out in the cold if you don't stay relatively current).

All in all I doubt it's worse than the microsoft "you need to upgrade _now_" philosphy and the lack of "we don't break compatability" that used to be enjoyed in the heyday of the "Full M$ Stack".

<comment><USER22> Back with windows 95 Microsoft actually took backwards compatability very very seriously:

An emphasis has been made by Microsoft on maintaining software backwards compatibility. To achieve this, when developing a new version of Windows, Microsoft sometimes had to implement workarounds to allow compatibility with third-party software that used the previous version's API in an undocumented or even (programmatically) illegal way. Raymond Chen, a Microsoft developer who works on the Windows API, has said: "I could probably write for months solely about bad things apps do and what we had to do to get them to work again (often in spite of themselves). Which is why I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure."[19]

</comment></comment><comment><USER23> I hope Munich somehow paid Canonical for its professional support or whatever to sustain a nice product in the long run.

<comment><USER24> IIRC lots of stuff was done by IBM.

</comment></comment><comment><USER18> Discussion two months ago:

[https://news.ycombinator.com/item?id=7720219#up_7720418](https://news.ycombinator.com/item?id=7720219#up_7720418)

</comment><comment><USER25> I'd love to see some detailed architecture docs for this or similar high-level Linux based rollout.

</comment><comment><USER26> I want to know a bit more about how they solved the MS-specific problems like VB macros that are often quite vital to a company's infrastructure.

</comment><comment><USER27> This uses Kubuntu rather than Ubuntu Unity

</comment><comment><USER28> They should totally have called it Munix.

</comment><comment><USER29> A+ would read again!!</comment>


Ask HN: Why isn't F# more popular? - <AUTHOR> I'm coming from Python world and I just started learning F# for fun (and profit ;)). So far, my experience with the language was quite positive, so I was bit surprised to see that F# is not more popular. I guess I wasn't able to see its downsides just yet.
My question for more experienced F# programmers: What are the F#'s downsides which prevent its more widespread usage?
For other people who have tried F# and didn't continue to use it: Why did you stop? Do you use other functional languages instead?
General questions: Is it because of its ties to Microsoft and/or Windows? Is F# not as good as other functional languages (which ones are better, and why?)? Not enough learning resources, examples, etc.? <comment><USER2> Most of the programmers do programming for a living. They are not passionate programmers who like to learn new languages. They care about getting things done. Since Java, C#, Python, JavaScript, Ruby and Rails, PHP are all popular and have huge library ecosystem around them, for most of the 9 to 5 programmers, there is little incentive learn any functional language.

Also since all popular and dominant languages are either Object Oriented and/or Imperative, functional programming concepts seem too alien.

Even though I consider myself a fairly passionate programmer, I haven't found enough incentive to invest proper time to learn a purely functional language. The infatuation with Clojure and Haskell only lasted for a weekend for me. I always think, that next month I am going to invest in learning a functional language, but always something else more shiny comes along from other domain like, Dynamo DB, Firebase, RabbitMQ, etc. Which I find more practical to learn rather than learning yet another programming language.

<comment><USER3> Agreed. I have tried using F# in my company but gave up after a while. Reasons:

\- it's hard to hire people

\- most libraries are written for OO style so most code will be written OO style

\- most sample code is written in C#

\- C# is a pretty nice language. Does F# really provide an advantage?

\- will MS abandon F#?

I really would like to see a clear case for F#. When you consider factors like hiring and existing ecosystem the case for F# is not clear to me.

<comment><USER4> Data wrangling is a really clear case. I do a tonne of this and it's so much easier in FP.

<comment><USER5> Why is data wrangling easier in FP? Is it because of functional composition being like using Unix pipelines (inside the same program)? But one can do that in a procedural language that has functions too.

<comment><USER6> Yes, functional composition in part. And while pretty-much-everyone has first- class functions now, they're usually not _quite_ as easy to declare and use as they are in F# (e.g., if you have to specify `Func<string, Func<string, int>> Foo` rather than `let Foo s1 s2 = ... `

Another data-wrangling thing easier in F# (not FP in general) is type- providers.

<comment><USER5> Thanks.

</comment></comment></comment></comment></comment></comment><comment><USER7> In corporate, especially in MS shops, to modify an old adage, "Nobody ever got fired for choosing C#". For side projects, I'd imagine most people working on those would rather do something not Microsoft-specific.

For me, I've done plenty of freelance projects in F# over the past few years and enjoy it. I've done about two years worth of projects in Clojure, and about a half year in Scala, and F# was the nicest of the three for me.

It takes a while to figure out your style however. Since it's a FP-OO hybrid, there are often many approaches to doing the same thing ([https://fsharpforfunandprofit.com/posts/13-ways-of- looking-a...](https://fsharpforfunandprofit.com/posts/13-ways-of-looking-at-a- turtle/)) and lots of different "styles" of _how_ FP you want to go. Some people end up with "C# in F#" and some go almost to "Haskell in F#". (I personally end up somewhere in the middle). And until you figure that out, it's hard to be as productive as in a language you already know. But once you do, I think F# provides the ability to be more productive than C#. (Granted I think immutable records and `with` syntax would get C# half way there).

However I will admit that when it comes time to transition the code back to the owner, I kind of regret using an edgy language. Fact is most workaday developers don't have a ton of interest in new languages and would rather work with something they already know.

Most of the pain points are due to running on a runtime designed for OOP. So even though idiomatic F# code shouldn't need null checks or much exception handling, you still need them if you're using C# libraries. There's also an annoying mix of camelCase and PascalCase everywhere (the former for logical consistency: a function is a value, and the latter for consistency with C# conventions).

<comment><AUTHOR> > I've done plenty of freelance projects in F# over the past few years and > enjoy it

Could you give some examples of what did you do in F#? Did you choose F# just because you wanted to see if you can do it in it, or did F# have some advantages over other (functional) languages?

> It takes a while to figure out your style however. (...) Some people end up > with "C# in F#" (...) And until you figure that out, it's hard to be as > productive as in a language you already know.

My plan is to avoid as much as possible "writing Python in F#", because I choose F# as an opportunity to learn something new/different (which might transfer to writing better Python later). Any tips for this?

<comment><USER7> My main project over the last few years has been a photobooth, so I've done server-side in suave (I LOVE suave compared to any other .net framework), client-side in WPF (F# experience in WPF is meh), and a bundle of other mini projects. I did it in F# because it was interesting, not because it was more productive at the time.

My personal landing point is about #6 in the turtles article. I still like classes and interfaces and think they fit perfectly well. However, inheritance is something I avoid completely now. The effect can be done much more flexibly and transparently by several other means. But one great thing about classes is that you get nice autocomplete when you type `myservice.`. And note I only use OO for "services"; data is data is data. So if you're doing DB stuff, prefer an anemic data model and a platform that supports it (so Dapper rather than EF or NHibernate). Basically do `db.Save(myData)` rather than `myData.Save()`.

Another big change I've noticed is I don't use "private" functions much anymore. In OO I spent a lot more energy making sure that people using my classes couldn't use them wrongly. They could only do exactly what the requirements allowed. I think OO mindset (at least in C#/Java, maybe Python is different) makes you paranoid and guides you to putting "app code" into what should be "libraries". This sometimes made e.g. unit testing more of a pain; you can't test your "validate" functions directly because they're private. Now I tend to open most everything up and let developers do what they want with my code, but I add a few helper functions to cover the common cases to guide them in the right direction. In general I consider everything a library now; the only "app-specific" code I write goes in `main` function that glues everything together. Of course I still don't open functions that expose contained services, or that leave things in an inconsistent state, but that's about all.

And of course embrace immutability and recursion (or the library functions that do it for you).

Probably the most annoying thing for you, especially coming from Python, will be "similar records". So you'd need a `User` that just has raw data, `UserDb` that maybe has that plus an ID/DateAdded/DateModified, a `UserOut` that maybe has that minus PasswordHash, a `UserIn` that maybe has RawPassword/RawPasswordAgain, etc, and conversions between them all. Not to mention if you want different schemes for jsonNaming, db_naming, RecordNaming, etc. I've yet to come up with a happy typesafe way of doing this.

<comment><USER5> > So you'd need a `User` that just has raw data, `UserDb` that maybe has that > plus an ID/DateAdded/DateModified, a `UserOut` that maybe has that minus > PasswordHash, a `UserIn` that maybe has RawPassword/RawPasswordAgain, etc, > and conversions between them all.

Why is this needed in F#? Something to do with immutability?

<comment><USER7> This assumes you want to use records for your data: records don't have inheritance. So whereas in C# you could create a UserDb that extends User with the Id/DateAdded fields, in F# that's not idiomatic.

I am sure there could be a good way to automate this using type providers, but I haven't tried it yet.

</comment></comment></comment></comment></comment><comment><USER8> As a long-time advocate of functional programming, I was once asked after a talk what is the "best" FP language to learn. Since I'm known as a Haskell/Scala/ML person, I surprised much of the audience by answering that I thought F# was the best entry point. What I did not say, however, was that I think that Windows is a challenging environment for anyone who is used to Linux/Mac -- and this includes the "open source" world in general. I think that Microsoft is a leader in language design, but their platform relevance was slipping for many years. I believe it may be on the upswing (with Xamarin etc). I would encourage you to stick with F# as you will be further along in not only understanding FP, but other modern programming languages, including ones that haven't been invented yet.

<comment><USER9> Interesting.

To me, Windows has eclipsed both MacOS and Linux as the best dev environment. It's caught up in shell and the whole ecosystem of tools completely blows away what exists on MacOS and Linux.

Windows is also a lot better than the other two in keyboard shortcut support.

<comment><USER10> Interesting. To me windows is a country mile behind linux as a dev environment.

I don't really understand what you mean about keyboard shortcuts though. I thought the windows ones are hard coded into the OS and can't be changed?

<comment><USER9> Everything in Windows has keyboard shortcuts, not so on Linux and MacOS (e.g. you can't open a random menu item with the keyboard).

<comment><USER10> Um yes you can? I mean i do this all the time like many times a day all the time... Alt key is your friend here

<comment><USER9> Not on MacOS.

<comment><USER10> MacOS is as unusable as Windows to me.

I think it depends on what you are used to though.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Because Microsoft could've promoted it more but it didn't.

>What are the F#'s downsides which prevent its more widespread usage?

The two biggest downsides I've encountered are not related to the language itself. One is lagging support in Visual Studio (didn't support folders for long time, poor cross-language C#/F# navigation, no support in .NET Core projects etc.) and the other is the lack of examples/frameworks for WPF applications when I needed them.

Other than that it's my favorite language for all kinds of tasks -- from production apps to scripts.

<comment><AUTHOR> > One is lagging support in Visual Studio

I use VS Code, both for Python and now for F#, and so far my experience has been positive. But that might be because I've used F# only for very basic stuff, and I don't know how better it could be in some other language and/or IDE.

> scripts

I think I'll stick with Python for that :) But I'm thinking about maybe transferring some machine learning stuff from Python to F# in (some distant) future.

<comment><USER12> If you are used to python, and think that VS Code is very nice, you'll be blown away by the tools and functionality that proper VS offers.

<comment><AUTHOR> > you'll be blown away by the tools and functionality that proper VS offers

I've used PyCharm before, but currently VS Code seems like the right balance for my needs.

</comment></comment></comment></comment><comment><USER13> F# is very popular, for a functional programming language. In 2014 it was the most popular functional programming language on the Tiobe index, excluding SQL (in the latest index it has dropped below Scala, Scheme and Prolog).

However, functional programming languages are not highly popular. Most programmers never learn any functional programming languages, choosing instead to learn one of C#, Java, C++, Javascript and stick with it indefinitely. For that reason, F# is stuck in a position of being the number 3 .NET language under C# and VB.NET.

That final point is a different topic again: F# is under VB.NET. Few consider Visual Basic to be a great language; it survives on momentum alone. F# is comparatively new; momentum takes _decades_.

<comment><USER14> This is mostly because you can do decent functional programming in any language. Including C (though not as nicely). It is a different approach which does not really require much beyond having functions be first class object. It is even easier in OOP ones.

Now if you're talking generic functions and higher order functions, maybe. But those are rarely needed, as you rather want a tuned specific version instead - or a template.

</comment></comment><comment><USER15> I love F#. Switched over from the other .NET languages as soon as it came out and I haven't looked back. F# helps me to become a better programmer.

What's wrong with ti? I wish F# had more OCAML to it. Functors would be cool.

Why isn't it more popular? Sad to say, most programmers don't really care about being a better programmer. They care about getting a job, keeping a job, and getting promoted -- none of which might involve learning a functional language.

To be fair, there's also a different paradigm programming functionally with larger development teams, a skill that many shops haven't mastered. Three guys in a startup would be fine. Three hundred guys in a mid-sized firm could have a lot of problems switching over. I grok that.

I'm kind of surprised F# is as popular as it is. Microsoft deliberately downplayed it when it came out, calling it a "scientific" language. I think that coders realize the open source power the language brings to *nix boxes, the more popular it'll get.

Let's put it this way: there are a ton of other languages I've wanted to try, but so many of them just aren't "done" yet -- there's still a crap ton of things missing. F# isn't like that. You pick F# up, you can code just about anything, and the community is there for support. I don't see that advantage changing any time soon.

</comment><comment><USER16> I "like F#" but there are a few layers between my having some fun a few times a month and a business adopting it.

F# makes sense when a) functional programming has a history of being advantageous in the domain, b) there is a mandate or clear advantage to develop in the .net ecosystem, c) a founder or engineering team has serious expertise with F#. Even then you have to ask if a functional-ish C# codebase you can easily add 50 developers to if needed is good enough.

</comment><comment><USER17> Functional languages are less popular. They are harder to learn and to use.

Proprietary platform are less popular. And .net is was very closed at the begining.

Non cross platform languages are less popular. And mono is not really that great on linux.

Plus the usual communication, timing and hype factors.

<comment><USER18> I disagree. Functional programming languages are not harder than for example OO-languages. The thing is that people usually learn procedural or OO -paradigm first when they start programming and moving on to FP requires a mindset change.

<comment><USER17> Recursion is harder than iteration. Immutability is harder than mutability. Callbacks, dependancy injection, and implicit loops are hard to wrap your head around.

Oop is just a strut with functions and a fancy dress. It's not really a new way to think.

I trained many, many, many people in small groups in programming. The functional concepts are always the hard ones to explain.

And as a dev, even when i deeply understand the benefits of immutability, i find it often being a huge constraint for the most mundane tasks.

Most programmers make simple programs. They don't need complex tools.

<comment><USER19> I think you're forgetting what it was like to learn your first programming language. A lot of concepts in procedural programming and OOP are hard to wrap your head around at first (static, by ref or by val, the difference between base classes and interfaces).

<comment><USER17> You don't have to learn any of this in python, ruby or php. Oop or functional doesn't need to mean low level.

Lower level is harder no matter the paradigm.

The features I mentioned are functional no matter the level.

<comment><USER20> Neither callbacks nor dependency injection are functional concepts, and implicit loops are pervasive in Ruby (and non-linear control flow in general). OO in Ruby is quite a long way from structs + function pointers.

</comment></comment></comment></comment></comment></comment><comment><USER21> "Why Isn't F# the King of .NET?" (Aug 21, 2016 )

* [https://hackernoon.com/why-isnt-f-the-king-of-net-2a9a1963e0...](https://hackernoon.com/why-isnt-f-the-king-of-net-2a9a1963e087)

* HN: [https://news.ycombinator.com/item?id=12530265](https://news.ycombinator.com/item?id=12530265)

<comment><AUTHOR> Thanks for both links! It'll be interesting to see if something has changed in public opinion in last 9 months.

</comment></comment><comment><USER22> I think the main problem is that F# never went beyond .Net platform (e.g. they never released a native compiler). .Net is nice and gets the work done, but the fact that existing .Net libraries are OOP style means 1) they don't fit as nicely into the F# paradigms (see other people's answers) and 2) adoption is easy for people already familiar with .net and not as easy for people coming from other languages/platforms.

In addition, inside the .Net world, F# got a role of just "And you can even do functional programming in .Net if you like", rather than "this is a proper way of how people should write safe high-level code". I think Ximian is the only one giving F# proper handling.

<comment><USER22> It might be worth also looking into ReasonML, which is a very similar language, but gets some of F# issues right, like:

      - Targeting native compilation and javascript transpilation out of the box
      - Proper functionally architected libraries
      - (including React and React-native for GUIs)
      - Ocaml style functors
      - Easy syntax for people who are familiar with javascript
      - Prime-time promotion by a large company (Facebook)
      - Targeting unikernels (i.e. MirageOS) makes it geek/buzzword compliant

The only downside for ReasonML right now I guess is that the tooling and developer experience (especially on Windows) is nowhere near to what F# / .Net core / VS Code+Ionide already offers on all platforms (Win/OSX/Linux).

</comment></comment><comment><USER23> I spent a bunch of time using F#, and it is good, but C# is a seriously good language and the advantages of F# kind of turned out to be minimal, and most annoyingly, not well supported by the tooling.

On the F# slack channel I asked what was the compelling reason for F#, why isn't it more popular, and basically there wasn't one. There's some stand out language syntax like computation expressions. The community is really good, but F# specific libraries are very quiet, web libraries like suave are ok, but kind of lifeless.

More interestingly, when I shifted a bunch of F# projects to C#, it was relatively straight forward. C# has enough syntax to do a lot of things functionally (though not as concise)

<comment><USER7> I think this nails it. C# is a really good language. F# has some advantages, some disadvantages, but there's not much clamor for something better in the dotnet world.

Java and Objective-C are far behind as languages, so the motivations for Scala, Clojure, Kotlin, Swift were far greater.

<comment><USER24> That's part of it, but I think the fact that "the .NET world" is largely enterprise, with is both less sensitive to language quality and more averse to change (whatever quality it brings) than much of the rest of the dev world is also a factor.

<comment><USER23> do you have an evidence for that? It seems a weird thing to say when C# is such a high quality language, and C# (and .net) keeps adapting and changing.

There are some advantages with stronger functional languages. Though C# seems to be slowly but surely working out how to incorporate more functional ideas. Though never will be a "functional language" but will support a functional approach.

</comment></comment></comment></comment><comment><USER25> javascript is insanely popular and its obviously shitty. popularity correlates very lightly with quality.

<comment><USER26> What's so shitty of javascript? From what I've heard is that people's opinion has changed about that. Javascript is evolving, and so is the ecosystem.

<comment><USER27> At its core Javascript is a good language. Some of the problems come from the fact that at its core it is a functional language, but for years it was marketed as object oriented. And when you look at the language and expect something object oriented or procedural then you will see a very bad language.

Another aspect is the fact that many of the Javascript's problems were actually not problems of the language itself but of the environment around it, like DOM and AJAX implementations in different browsers.

Besides those major problems, the language itself has some minor problems. But as you pointed out the language has a very active ecosystem around it, which creates at least 5 solutions to every problem. But many solutions involve new languages which compile to javascript. So practically the problems are solved but the theoretical use case of writing plain Javascript is still a little problematic.

<comment><USER14> At the core JS combines dynamic and weak typing.

It is not even object oriented, so instead it is commonly used with the prototype approach.

It is not a functional language either as functions can define global variables, therefore they aren't actually functions. And defining global state is the default behaviour.

</comment></comment></comment></comment><comment><USER28> While I was doing .Net (up until a couple years ago) I really wanted to use F#. But:

\- Microsoft had no real support for using it in web projects.

\- Functional programming would be great for data transforms in SSIS but that wasn't possible either. You'd think with a common VM you could use any .Net language, but no.

Microsoft has always treated it as a non-mainstream language, saying "do the regular stuff in C# and use F# for the hard stuff." The problem is that C# isn't terrible for hard stuff, and if you spend most of your time using C#, then for you it's probably better.

</comment><comment><USER29> Because it's a really hard chord to play on Guitar.

<comment><USER30> "If you want to rock out, rely on F#" -Tom Morello

[https://youtu.be/aJXzY9vhqZg?t=339](https://youtu.be/aJXzY9vhqZg?t=339)

</comment></comment><comment><USER31> Partially because there is Ocamal. Not that it is (or is not) a better language. But because it is older and was historically available on more systems and covers some of the same ground as a descendant of ML. Partially because of Scala which also covers some of the same ground...though not claiming as strong a tie to ML it has strong ties to the JVM.

Finally, there are many very good languages. Few are as a popular as Python...one might say even Python isn't as popular as Python, if you know what I mean...anyway, I'm not a big fan of the concept of "functional programming languages" because functional programming is a way of programming and most languages can be used imperatively or functionally and though some make it a bit easier than others most programming languages readily facilitate both. Once it was all the rage to talk about Python as a functional programming language (but making map/reduce/filter second class citizens in the past few years has hurt that story) and there are plenty of resources for functional PHP.

</comment><comment><USER6> Since you're "coming from the Python world" you have a good case-study in how a bunch of things outside of language design are crucial. Python has essentially won the race to be the next major language among scientists and that's tied up with a virtuous circle of libraries for, e.g., numerics, statistics, data viz, machine learning, and even within many scientific disciplines (e.g., astronomy). The virtuous circle also includes learning resources (books, Websites, conferences) and the ability to have someone check / talk over your code.

For what it's worth, F# is trying to get that same virtuous circle rolling, but there are a few areas (cross-platform dataviz, interactive notebooks) where F# just doesn't have quite as good a story as Python.

</comment><comment><USER32> I do mostly server-side stuff. Practically speaking, for the most part it means Linux programming. Unfortunately, .NET is still a second-class citizen under Linux. Yes, several people report they are using F# without problems under Linux, but I encountered several glitches in the past and don't feel like experimenting until things become more mature. I'm lucky enough to make the choice of the language myself, and I'd give F# a try, but after huge memory leaks and other problems with .NET on Linux a few years ago I got burned and would need a good argument to switch now. There are far better alternatives under Linux (both functional and non-functional)

<comment><USER23> F# seems quite popular in linux/mac using mono .NET, I was quite surprised in the F# forums how many didn't even use windows. I actually used my Mac for a lot of F# coding. But the new approach from MS for cross platform is .NET Core which (maybe next year as it seems a bit messy at the moment) will be a great cross platform choice.

</comment></comment><comment><USER33> This is a good question IMO. As functional languages go, it seems like it should be pretty appealing, especially now that .NET is starting to open up a bit. Good runtime, vendor support, can leverage .NET libraries.

</comment><comment><USER34> IMO the biggest thing with F# is that all the improvements over C# are incremental.

Almost every cool feature about F# you show to a C# developer he'll go "OK I can sort of do that in C# it's just a bit more tedious".

When you add up those incremental improvements you get drastically shorter code but that is not immediately obvious and that's why you'll have a hard time convincing C# developers switching to F# is worth it.

Also F# has it's own warts, like compilation order based resolution :(

</comment><comment><USER35> I'm a professional C# developer and while I have dabbled in F# it isn't where I ended up when using functional programming languages. I ended up with Elixir and the main reason why is moving off of the .NET framework. There is nothing wrong with .NET but after doing it for a living for 5 years I wanted a change. I really enjoy Elixir and can't see myself going "back" (I was never fully there) into F#.

</comment><comment><USER36> I like the idea of F#, but do not like programming in the windows ecosystem. I spent years learning/writing haskell (though I write mostly JS these days).

</comment><comment><USER37> For the same reason most functional languages never took off, they look succinct, but come back to your code in 6 months and its like a war zone. Also not to mention the fact that if you start writing your code base in a niche language that few people want to write in, then it will be very difficult to recruit and you're stuck with a codebase no one wants to write in, you might as well write in Cobol.

</comment><comment><USER38> I used F# for a time and ended up disliking it. The syntax is poor IMO and some bits are quite quirky. I love using Clojure though for functional programming. Most of F#s ideas come from the Lisp world anyway, but they also tried to shoehorn on a type system. It doesn't work that nicely in the end, and I don't think you get the full power of functional programming because of it.

<comment> UK-AL F# is basically .NET Ocaml which relies heavily on its type system. I wouldn't compare it to LISP, except for that its functional.

it seems to me you're just not a fan of static type checking.

</comment></comment><comment><USER39> (I'm an experienced functional (Haskell) programmer)

I have no interest in F# because I don't want to work in Windows (and the dotNet platform in general).

Yes I could probably make F#/dotNet work in Linux, but at that point I have Haskell, (and SML and OCaml and Erlang). Net, net, in my dev/deploy environment, F# confers no benefit (as compared to the alternatives)

<comment><USER22> Funny. I'm also love Linux, but for me, the combination of .Net Core/Standard, Visual Studio Code and Ionide provide by far the best programming toolset/experience of anything I have ever seen in my 30 year programming career.

And all of it works on Linux just as well as it does on Windows.

</comment></comment><comment><USER40> functional languages in general aren't very popular in the enterprise yet. this means that finding talent for more obscure languages like F# is really challenging. You would need some really large org that's willing to make the switch to build a hiring pool around it.

which brings me to my next point. the cost of switching languages is really high for most companies and often times the need to do so is driven by a direct business need (like Jet.com and their order processing engine, which ran on F# from the start).

Also, C# and to some extent Java are getting some functional-like features (type inference, anonymous functions, pattern matching), so the need to take on a new language entirely to get those features is even lower

</comment><comment> fsharp-fan-18 Combination of many reasons. See also OCaml. Not the main language of its platform. No killer app. Most use cases better served by other languages.

It's sad because F# is a fine language. Just not a popular one.

</comment><comment><USER41> Is there a practical use case (deep learning, cloning Uber, trading, bitcoin mining, healthtech etc.) where F# or a F# framework is significantly better than what's out there?

<comment><USER6> I prefer F# as my day-to-day, but I can understand why, for day-to-day challenges, a lot of devs might look at some language features and say "C# has something that's pretty similar." However, use-cases that can be solved elegantly by pattern-matching, type providers, and/or computation expressions are areas where the "C# is good enough" argument is harder to make.

One set of use-cases where pattern-matching are particularly valuable is parsing and other times when you're deconstructing / transforming a complex structure.

One use-case for a type provider would be, say, taking an XML schema and exposing its structure as a compile-time constraint.

One set of use-cases where computation expressions are valuable relate to (oh god I don't want to use the "M"-word) the creation of a small DSL that isolates some type of specialized computation on a parameterized type. For instance, the (built-in) `async` computation expression.

Those might sound like fairly esoteric use-cases, but they're really not that uncommon if you do DSL / library development.

</comment></comment><comment><USER30> I worked with it and while its technically a probably a good language it's nowhere near as easy to get shit done with it as C#.

<comment><USER7> I disagree with this. As someone with over a decade of C# experience and a few years F# experience, I'm more productive in the latter. However it did take about two years to get to that point, and the productivity difference is only marginal. So if you account for the ramp-up time, this is probably true.

<comment><USER6> I'm no believer in silver bullets, but I wonder about "the productivity difference is only marginal." For one thing, I think being an F# dev is likely to improve one's OOP code (immutability by default, smaller methods), so while I agree that it might feel like one is similarly productive, I think one changes one's baseline.

For another, I think it really boils down to maintainability. Elsewhere in this thread, there is a comment that "return to your code in 6 months and it's incomprehensible." As a guy who worked with a large Scala codebase, I totally "get" that, but the thing with "functional code you haven't seen in 6 months" is: It's either incomprehensible or it's MUCH easier to reason about than stateful OOP code. And the "incomprehensible" stuff tends to fall into a couple different categories (lifting and conversion, complex function composition, etc.) that gets at least a _little_ better once you've hit your head against them a few times.

</comment></comment></comment><comment><USER42> I think it's two things.

If you write a lot of F# then if anyone leaves you need to replace them and it's harder than finding a C# developer.

Secondly most of the libraries you interop with are C# and so you have to go through interop which is more annoying.

<comment><USER43> What's surprising is that Scala/Java basically has the same issues, but Scala seems to be more popular due to early adoption by several industry actors (Twitter IIRC).

<comment><USER7> Scala is also far closer to Java than F# is to C#. You can write Scala code that looks almost exactly like Java code.</comment></comment></comment>