321–330 of 424 posts
Earlier quoted context omitted.
Can you explain more about strongly typed vs statically typed?
strong typing: 2 + "2" is an error (e.g. Python vs JS) static typing: 2 + "2" does not compile/parse (e.g. Python vs mypy, Typescript vs JS) this is a very simplistic example, but should get you to feel the difference.
Earlier quoted context omitted.
Gleam, much like any language which primarily targets BEAM, is slower by an order of magnitude or two when compared to F#.
The appeal is the runtime model. I can’t readily verify if BEAM languages are meaningfully slower or really slower at all but let’s take the premise for the sake of argument. Even if is slower, the runtime model is incredibly resilient and it’s cheap to scale up and down, easy to hot update, and generally does asynchronous work extremely well across a lot of different processes. F# has really good async ergonomics bu…
[0] https://learn.microsoft.com/en-us/aspnet/core/signalr/hubs?v...
[1] https://azure.microsoft.com/en-us/products/signalr-service
Our shop converted 6 years ago, from C# to exclusively F#. I also author and maintain some packages (falco, donald, validus and others). The language is tough to learn if you're coming from a C-style language. But worth the effort and experience. It's extremely concise a true delight to build programs in that are fast, robust and durable. There are a few drawbacks, depending on your perspective: - compilation is slow…
Hiring devs is perfectly fine if you don't look for F# skills - just hire generally smart people, and allow them 1-2 weeks to get comfortable with F#. Make them just solve problems from project euler or something. For those who have already done functional programming, they wont take more than 2 days to start getting productive. For those who have written a lot of code, it will take them ~2 weeks to pick up functiona…
> Anyone who is still uncomfortable with F# after 1 month - well that's a strong signal that the dev isn't a fast learner.
For myself, I feel that I have "full" command of C# as a programming language, but also how to structure projects, how to isolate modules, how to decouple code, how to set up a build system from scratch for C#, how do deploy and scale applications built with C#, what the strengths and weaknesses are, etc. My definition of "comfort" would entail a broader understanding of not just the syntax, but of the runtime ecosystem in which that code operates.
Our shop converted 6 years ago, from C# to exclusively F#. I also author and maintain some packages (falco, donald, validus and others). The language is tough to learn if you're coming from a C-style language. But worth the effort and experience. It's extremely concise a true delight to build programs in that are fast, robust and durable. There are a few drawbacks, depending on your perspective: - compilation is slow…
Hiring devs is perfectly fine if you don't look for F# skills - just hire generally smart people, and allow them 1-2 weeks to get comfortable with F#. Make them just solve problems from project euler or something. For those who have already done functional programming, they wont take more than 2 days to start getting productive. For those who have written a lot of code, it will take them ~2 weeks to pick up functiona…
I just gave a talk about how we use F# at REN: https://vimeo.com/1070647821
I'm completely convinced that F# (along with Scala, Haskell, and OCaml) adoption has stalled due to having ridiculously bad build systems. More significantly, they are being passed up in favor of Rust, which is a great language but nonetheless a bad fit for a lot of problem domains, simply because Rust has a superior build system. Hell, 80% of the reason I choose Rust over C++ for embedded work is because of the buil…
At the same time, a lot of the cool features (list comprehension, pattern matching, immutable records) have slowly trickled into c#, giving even less incentive to switch
Earlier quoted context omitted.
The funny thing is that you can write very similar code in C#, so maybe you don't need to switch which language you're using as a CLR frontend. using System.Linq; using System; var names = new string[] {"Peter", "Julia", "Xi" }; names.Select(name => $"Hello, {name}").ToList().ForEach(greeting => Console.WriteLine($"{greeting}! Enjoy your C#")); LINQ is such a good library that I miss it in other languages. The Java s…
You're being way too nice. Java stream is nowhere near as easy to use as LINQ. I'd say that LINQ is easily one of the top 10 coding features that Microsoft has ever created.
Earlier quoted context omitted.
Modern C# collection expressions make the definition of names closer to F#: string[] names = ["Peter", "Julia", "Xi"]; I know working on "natural type" of collections is something the C# team is working on, so it feels possible in the future that you'll be able to do this: var names = ["Peter", "Julia", "Xi"]; Which I think would then allow: ["Peter", "Julia", "Xi"].Select(name => $"Hello, {name}").ToList().ForEach(g…
I did try that initially and got (5,1): error CS9176: There is no target type for the collection expression. .. which I took to mean that, because .Select is an extension method on IEnumerable, the engine was unable to infer whether the collection should be a list, array, or some other type of collection. It seems reasonable to have it default to Array if it's ambiguous, maybe there's a downside I'm not aware of.
Earlier quoted context omitted.
The funny thing is that you can write very similar code in C#, so maybe you don't need to switch which language you're using as a CLR frontend. using System.Linq; using System; var names = new string[] {"Peter", "Julia", "Xi" }; names.Select(name => $"Hello, {name}").ToList().ForEach(greeting => Console.WriteLine($"{greeting}! Enjoy your C#")); LINQ is such a good library that I miss it in other languages. The Java s…
This isn’t a great example of what linq is good at. There’s no reason to do ToList there, and the ForEach isn’t particularly idiomatic