Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why F# evangelism isn't working (2015)

ericsink.com

Post reply on HN
Print view View original

91–100 of 333 posts

Re: Why F# evangelism isn't working (2015)

#91

Post by CrimsonCape »

systems wrote: post #84
ericsink wrote: post #68

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

I don't think it matters how good or bad C# is, Object Oriented Programming is a mess Learning, how to use an Object System (a tree of objects/classes) is inherently hard The current problem with F# is that it doesnt do enough to shield you from objects, it does what it can, but still to use F# effectively, you still need to learn some C# and a lot of API that basically Objects inside Objects inside Objects calling O…

I empathize with your characterization of "a tree of object/classes" and I yearn for an example of how else to model a complex, domain-specific system not using the aforementioned tree.

Re: Why F# evangelism isn't working (2015)

#92

Post by Tehdasi »

local_crmdgeon wrote: post #35
muglug wrote: post #32

Progamming language evangelism is basically a zero-sum game. Some languages don't really intrude on one another's territory — e.g. not that many people are rewriting Ruby programs in Rust — but some very directly compete. So if you want to convince someone to use F#, you have to convince them it's significantly better than some other closely-related language. And that's hard! I have a strong suspicion that the next d…

Agreed. Tweaks: I don't think C++ is going to be relevant for much longer, Rust solves the problem space better. Python ... maybe? It's so different than the rest, I can see it going the way of Ruby once AI bindings improve in other languages. I can also see Julia dominating the AI space. The "better than X" languages though? C#, F#, Scala? Done. I don't even hear about Kotlin that much anymore, Java is starting to a…

> Agreed. Tweaks: I don't think C++ is going to be relevant for much longer, Rust solves the problem space better.

I would say that in the domain of game development C++ (which is where I'm guessing that most new C++ development is done) has such a moat that Rust in it's current form will not be able to displace it.

Re: Why F# evangelism isn't working (2015)

#93

Post by CrimsonCape »

ericsink wrote: post #68

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

If you had to chose right now and abandon the other, would you pick LINQ or discriminated unions?

Re: Why F# evangelism isn't working (2015)

#94

Post by topkai22 »

Hasnep wrote: post #77
throwaway2037 wrote: post #67

Earlier quoted context omitted.

There is much naïveté among the strongly typed herd. Is exactly the reverse also true? Let me try: "There is much naïveté among the weakly typed herd." For every person who thinks Python or Ruby can be used for everything, there is another person who thinks the same for C++ or Rust. Also, the example that you gave is incredibly specific: When tasked to create glue code translating between two opposing type systems, w…

I'm a data engineer, it's a fairly new role so it's not well defined yet, but most data engineers write data pipelines to ingest data into a data warehouse and then transform it for the business to use. I'm not sure why using a static language would make translating data types difficult, but I add as many typehints as possible to my Python so I rarely do anything with dynamic types. I guess they're saying for small t…

A major problem with doing data transformation in statically typed languages is that its easy to introduce issues during serialization and deserialization. If you have an object

  [{
    name:”ex obj”
    value:”a sample value”
    extraProperty:”I’m important”
  }]
And the code

  class myDTO{
    string name;
    string value;
  }

  var myObjs= DerserializeFromFile(filepath)
  SerializeToFile(myObjs, filePath2)
filepath2 would end up with without the extraProperty field.

You can also write code like

  function PrintFullname(person) {
    WriteLine(person.FirstName + “ “ + person.LastName)
  }
And it will just work so long as the object has those properties. In a statically typed language, you’d have to have a version for each object type or be sure to have a thoughtful common interface between them, which is hard.

All that bring said, I generally prefer type safe static languages because that type system has saved my bacon on numerous occasions (it’s great at telling me I just changed something I use elsewhere).

Re: Why F# evangelism isn't working (2015)

#95

Post by jasdfwef »

xupybd wrote: post #53
slfjw____ wrote: post #14

Likely will never use again * two async models present: task (C#) & async (f#) * horrible async performance: perhaps fixed by native task & FSM transformation * two error handling models: Result (monadic but without do notation) & C# style Exceptions * not rich in community libraries, like a desert & abandonware

> not rich in community libraries, like a desert & abandonware You have access to the entire .net ecosystem?

They may have meant F# packages

Re: Why F# evangelism isn't working (2015)

#96

Post by lambdaxymox »

ericsink wrote: post #68

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

F# always struck me as one of the most terribly underrated languages. I'm a lover of MLs in general, but F# lands on one of the sweet spots in PL space with ample expressive power without being prone to floating off into abstraction orbit ("pragmatic functional" is the term I believe). It is basically feature complete to boot.

Re: Why F# evangelism isn't working (2015)

#97

Post by chowells »

waffletower wrote: post #85
Hasnep wrote: post #77

Earlier quoted context omitted.

I'm a data engineer, it's a fairly new role so it's not well defined yet, but most data engineers write data pipelines to ingest data into a data warehouse and then transform it for the business to use. I'm not sure why using a static language would make translating data types difficult, but I add as many typehints as possible to my Python so I rarely do anything with dynamic types. I guess they're saying for small t…

Using a static language to manipulate complex types, particularly those sourced from a different type system (say complex nested Avro, SQL, or even complex JSON) is much more awkward when the types cannot be normalized into the language automatically as can be done with dynamic languages. Static languages require more a priori knowledge of data types, and are very awkward at handling collections with diverse type mem…

You realize every single thing that dynamically-typed languages can do with data types, statically-typed languages can do too? Except when it matters, they can also choose to do things dynamically-typed languages can't.

Lots of people assume static typing means creating domain types for the semantics of every single thing, and then complain that those types contain far more information than they need. Well, stop doing that. Create types that actually contain the information you need. Or use the existing ones. If you're deserializing JSON data, it turns out that the deserialization library already has a type for arbitrary JSON. Just use it, if all you're doing is translating that data to another format. Saying "this data is JSON I didn't bother to understand the internal content of" is a perfectly fine level to work at.

Stop inventing work for yourself.

Re: Why F# evangelism isn't working (2015)

#98

Post by girvo »

lmm wrote: post #46
NegativeLatency wrote: post #40

Earlier quoted context omitted.

Rails has generators you’re talking about not ruby, and I’ve seen and worked on some very maintainable rails apps.

> Rails has generators you’re talking about not ruby They may not be built into Ruby-the-language but they're very much part of Ruby-the-development-community. > I’ve seen and worked on some very maintainable rails apps I've seen far more upgrade breakages in apps built on rails than any other stack.

> I've seen far more upgrade breakages in apps built on rails than any other stack.

React Native would like to argue with you on that point

Re: Why F# evangelism isn't working (2015)

#99

Post by faitswulff »

phamilton wrote: post #57
muglug wrote: post #32

Progamming language evangelism is basically a zero-sum game. Some languages don't really intrude on one another's territory — e.g. not that many people are rewriting Ruby programs in Rust — but some very directly compete. So if you want to convince someone to use F#, you have to convince them it's significantly better than some other closely-related language. And that's hard! I have a strong suspicion that the next d…

> not that many people are rewriting Ruby programs in Rust Just an anecdote (and definitely not "many") but one thing we've found is that ruby and rust actually fit fairly well together. The way I express something in Ruby (often FP stuff like `map` and `filter`) translates very well in Rust. Much better than it translates into (as an example) golang. Beyond expression, the tooling in rust (cargo) feels very familiar…

You might find it interesting to know that Yehuda Katz, author of bundler, was hired to write cargo. There has been a lot of cross pollination between the Ruby and Rust communities.

Re: Why F# evangelism isn't working (2015)

#100

Post by girvo »

local_crmdgeon wrote: post #35
muglug wrote: post #32

Progamming language evangelism is basically a zero-sum game. Some languages don't really intrude on one another's territory — e.g. not that many people are rewriting Ruby programs in Rust — but some very directly compete. So if you want to convince someone to use F#, you have to convince them it's significantly better than some other closely-related language. And that's hard! I have a strong suspicion that the next d…

Agreed. Tweaks: I don't think C++ is going to be relevant for much longer, Rust solves the problem space better. Python ... maybe? It's so different than the rest, I can see it going the way of Ruby once AI bindings improve in other languages. I can also see Julia dominating the AI space. The "better than X" languages though? C#, F#, Scala? Done. I don't even hear about Kotlin that much anymore, Java is starting to a…

I would love for Rust to take over C/C++, but in embedded it's still got a while to go, and it's not even really Rust's fault per se. It's the tooling and third party driver problem that's the real issue. It's getting there, sure, but it's getting there by rebuilding the world, which is... like I said, it's a while away, IMO.
Post reply on HN