24 ms·

Dark’s new backend will be in F#

347 points by nikivi 6y ago

fulafel 6y ago
I'm rooting for Dark, it's such a breath of fresh air, really hope this works out! I hope HN can forgive Pul for choosing F# over Rust :) Does anyone have experience porting code from OCaml or other MLs to F#, how does it work out?
__s 6y ago
> It actually has a much better type system, in my opinion. I don't know how anyone can say that with a straight face about a type system that has both Option & null (granted Rust technically runs into this, but they go out of their way so that you should never be using pointers unless you want to. Whereas in F# you'll run into this using references, & you'd expect interfacing to C# APIs wouldn't take the care that interfacing with C APIs does) That said, F# does sound like a good fit for them, so one funny reasoning aside, dive in. I enjoyed F# when I was able to use it
- gameswithgo 6y ago
  There are like a thousand little details a type system has, and you focus on one thing, the existence of null for .NET interop, and decide this means the type system can't be overall better?
  - McWobbleston 6y ago
    The null thing is a bad example, particularly because it's from the .NET side and C# is focusing on removing that now through nullable reference types, but I'm honestly surprised they claimed F# has a better type system. F# lacks functors, first class modules, row polymorphism, GADTs, PPX extensions, and likely some others I'm not aware of. GADTs, row polymorphism, and PPX extensions I've wished for in particular because they solve some problems I frequently run into with MVU/Elmish architecture on the front end. F# instead has inline functions with static constraints (similar to C++ templates), type providers, computation expressions, and units of measure.
- zzbzq 6y ago
  I worked on some Scala codebases, which has this problem. It even lets you end up with Some(null). I call it the two billion dollar mistake.
  - yawaramin 6y ago
    Was this because the devs didn't know about Option.apply?
- ojnabieoot 6y ago
  I have been using F# for 5 years and have never once needed to use “null” anywhere in my code - if I were to interact with a C# library I think null-handling is an acceptable price to pay for the interop (similar to weirdness with OCaml/Haskell and C FFI). F# makes that particular separation of concerns very clean and easy to handle. Idiomatic F# is safe against null reference exceptions. I think you’re needling a small wart in F# due to the .NET requirement, it’s hardly enough to say that F#’s type system is overall bad.
  - StreamBright 6y ago
    >> I think null-handling is an acceptable price to pay for the interop Especially given how easy it is to deal with it. Option.ofObj what we use most of the time.
- phillipcarter 6y ago
  > Whereas in F# you'll run into this using references It depends :) F#-defined reference types cannot be assigned a null value by default. If your reference is an F# library (or one with F# bindings, of which there are several) then this isn't something you run into. Technically this can be bypassed by giving the type an attribute called AllowNullLiteral, but it is extremely rare to see that in practice because it's so unsatisfactory to use null from a cultural perspective in F#. Once a C# programmer uses F#, something switches on in their brain and they tend to eliminate all possible ways null can creep in as thoroughly as possible. It's neat. Another aspect where you don't see null is in initialization soundness. In F#, all values must be initialized before use. This is in sharp contrast to C# or Java where you can accidentally access something that hasn't been initialized before. While you can also technically bypass this to inject a null somewhere, it is also exceedingly rare because it's not a default behavior. F# data types also cannot be assigned a null value, so that's also a place where null doesn't come in. So it really leaves interop with .NET assemblies, some serialization scenarios, and .NET reflection. The first is really the only time people can still get "surprised" by a _null_ value. The rest are all technically possible, but just tend not to come up. The reason why this all matters is it's not a binary thing about having null/non-null. Just like it's not a binary thing about having exceptions/vs. not. It's about how frequently they can come about in normal programming scenarios. I can write a simple Haskell program that throws an exception at runtime, does that mean that Haskell is not safe? Of course not, because it's not usually what normal Haskell code does. The same thinking applies here. The ways that null can creep into an F# program are simply smaller than C# or Java and do create this mindset that nullis something that F# programmers tend not to think about that much.
melling 6y ago
From yesterday’s story about leaving OCaml: https://news.ycombinator.com/item?id=24974907 https://news.ycombinator.com/item?id=24974907
bachmeier 6y ago
The title is not a surprise, based on the previous post. The one surprise is that he seriously considered Rust. > "you'll never believe just how much a Garbage Collector does for you!" Of course, that's why it's hard to see someone moving from OCaml to Rust for any reason other than wanting to use Rust.
- pjmlp 6y ago
  As mentioned elsewhere, I believe that automatic memory management + affine types will win in what concerns masses adoption. Rust has been the catalyst to force language designers to look more seriously into affine types, but its use can only be justified in "no way GC/RC" scenarios like MISRA.
  - mpweiher 6y ago
    To me, it looks like the sweet spot might be RC + weak references, which in terms of ease of use is close enough to a tracing GC as to not matter, + the ability to tune away the RC ops in specific circumstances, for example using affine types.
  - darksaints 6y ago
    Its use can be justified elsewhere, but it should always be understood that manual memory management is always going to be more difficult. The problem I see, and the reason I sometimes reach for rust when I don't really require manual memory management, is that nothing else is really better for strongly-typed statically-compiled self-contained executables. Go: it's got the convenience and packaging and ecosystem, but an absolute shit type system. F#: carries around the baggage of the CLR, and the best tooling is Windows-exclusive. Type system is good but not as good as others. Scala: absolutely amazing type system, but lots of unneeded stuff too. JVM packaging is a huge pain, and pretty heavy weight. Native compilation options are few and have slow executables in comparison. OCaml: tiny ecosystem, multicore is always one year away, some weird ergonomic choices. Haskell: lazy, IO has terrible ergonomics, and the community consists of pie-in-the-sky type theorists. I would kill for a Dotty-like (Scala 3) native programming language that could omit all of the bullshit that was required to fit into the JVM and work with java libraries.
Jhsto 6y ago
Anyone here used dark? Any anecdotal experience report you could share?
- andymoe 6y ago
  It has great potential. I think the unique integrated web ide, tracing, function level versioning and deployment model are game changing. Anyone not going in this direction with their FaaS products should stop what they are doing and reevaluate. That said, his motivation for rewriting it is the right call. Dark does not have enough of a standard library for third party integrations (among other issues) or a way to easily contribute them which makes it tough to build in the large. I’m really rooting for Dark - even with the rough edges it feels like the future and how I want to eventually build software.
  - mpweiher 6y ago
    Yes. The initial PR was a bit misguided IMHO, and left a big "huh?". The futureofcoding interviews were much better, what they are doing is really interesting, though I am unconvinced that all the stuff they're doing is actually required to achieve their goals. For example, they claim that a structured editor is required, but if per-method granularity is good enough, then a normal method browser would work just as well. As far as I can tell. https://futureofcoding.org/episodes/043 https://futureofcoding.org/episodes/043
- tnolet 6y ago
  Did not use it, but looked at it quite a bit. Felt like Force.com and the Apex language for the modern age.
bartleby_ 6y ago
I got a chance to start using F# for the first time for some cryptography course assignments and supremely enjoyed it. Having a language that's easy to script with, has access to .Net libraries for everything and is easy to run on any major OS is kinda great.
toolslive 6y ago
the advantage of F# over OCaml is that your ecosystem is way larger... you can always 'snarf' c# libraries.
- randompwd 6y ago
  sure, but c# ecosystem is nothing compared to jvm, rails, go, js etc..
  - eatonphil 6y ago
    Sure, but there's no equivalently mature OCaml-like language for the JVM (Scala doesn't count)
    - Ivoah 6y ago
      Asking as someone with no OCaml experience but who quite enjoys Scala, why does it not count?
      - dkarl 6y ago
        I don't know OCaml, so I can't give you a great answer, but I know that OCaml has a different type system that has some features that Scala 2 lacks, such as union types.
        yawaramin 6y ago
        OCaml doesn't have union types. It has what it calls variants, and what is generally known as Algebraic Data Types. So does Scala 2.
      - eatonphil 6y ago
        They are radically different languages, even if they're from the same family. Scala is about as similar to OCaml as Rust is to OCaml. Rust and Scala are a world apart from OCaml and Standard ML in terms of language complexity. And then F# literally has an OCaml compat mode because they are so similar (F# has a bunch of convenient syntax extensions if you don't mind not using the compat mode).
blunte 6y ago
I read good things about F#, including that it is a first class citizen of Microsoft... but I have worries that it could become second class if some financial decision deems it not worth the effort to support for them. From a functional perspective, I would think the two primary candidates would have been F# with its .NET ecosystem or Clojure with its Java ecosystem. Both are similar in more ways than other languages, especially considering the rich set of libraries available... But to me the deciding factor would be ClojureScript for the front end. They stuck with ReasonML, if I read correctly, because they already had so much code (50k lines?). But at the same time, the previous post complained about the build tools. Plus it's still Ocaml...
- eterm 6y ago
  F# is 15 years old and there has been a "F# foundation" for past 5 of those. If your concern about Microsoft abandoning F# is genuine then perhaps that can re-assure you.
- airstrike 6y ago
  I keep reading good things about F# but at the same time it seems to fly under the radar, with not enough learning material out there I did love this one article http://tomasp.net/blog/2018/write-your-own-excel/ http://tomasp.net/blog/2018/write-your-own-excel/ EDIT: Submitted the link here https://news.ycombinator.com/item?id=24980325 https://news.ycombinator.com/item?id=24980325
  - dangets 6y ago
    I agree in the difficulty of finding abundant, good examples for F#. I'll throw out some plugs for ones that I liked. * https://pragprog.com/titles/swdddf/domain-modeling-made-functional/ https://pragprog.com/titles/swdddf/domain-modeling-made-func... Uses F# as implementation language, though I cannot recommend this book enough for general type-safe design modeling regardless of the language. * https://fsharpforfunandprofit.com/ https://fsharpforfunandprofit.com/ Website of the author of the book mentioned above. He also has some good Youtube videos on the topic. * https://www.demystifyfp.com/FsApplied/ https://www.demystifyfp.com/FsApplied/ A book that will walk you though developing a webserver, and also introduces you to Paket for dependency management. I don't develop F# (or .NET) professionally, but I had fun when I played around with it. I found the interop with C# very seamless as well.
jrumbut 6y ago
This is a great article but I really wish that somewhere on the page it said what a Dark is and why I would want one. I tried clicking homepage it wasn't there, I tried clicking demo and it tried to open YouTube which was not what I wanted to happen, then finally I found it in the documentation section. The first sentence or two from there, maybe as a subtitle or in the intro paragraph would help I think.
- Cthulhu_ 6y ago
  idk, I clicked Homepage and the blurb was right there. Looks like a language / environment to build serverless apps.
  - kev009 6y ago
    One thing that makes it hard to grok is how large the scope seems to be and the cognitive bias many devs have developed against new platforms due to being burned in the past. It reminds me of a throwback to 90s era RADs that wanted to encompass everything for everyone without really having clear intent or at least a platform company backing them to snare enough users to become a new platform. Sometimes there are gems in the rough in things like that like Delphi, and I don't mean to dismiss any of the ideas or dreams, but IMO platform companies are going to continue to monopolize the language space (for instance, I see great irony in they are using .NET because Microsoft basically does what they are trying to do). So that's why I bring up Delphi above, it seems this could be an opinionated framework on top of a .NET language instead of yet another language?
    - seibelj 6y ago
      It looks like Dark is trying to be a new language, a backend server, a CI solution, and an IDE! Then there is a blog post that everyone churns: > Currently, we get 10 user signups a day, and on average, 0 of them stick. We do have developers who love Dark, but not enough. https://roadmap.darklang.com/goals-of-dark-v2 https://roadmap.darklang.com/goals-of-dark-v2 I think the company should focus on just one of those things and it would still be an enormous lift given their size. > The problems and fixes are across the product. One problem is that undo is slow, another is that you can't put a minus sign in front of an integer, another is that we need to define how namespaces will work in the package manager. The fixes range from adding tooltips in the UI, to adding a type-checker, to making the package manager public. https://blog.darklang.com/dark-v2-roadmap/ https://blog.darklang.com/dark-v2-roadmap/ Ayeeeee... this is like trying to carve Mount Rushmore using a spoon.
amelius 6y ago
How is the dotnet virtual machine compared to the java virtual machine? (memory use, performance, startup time)
- mythz 6y ago
  ASP.NET Core (Linux/Kestrel/C#) has the fastest plain-text performance on Tech Empower benchmarks (7.3M /rps): https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r19&hw=... It's also one of the more full-featured web frameworks benchmarked.
- bob1029 6y ago
  I haven't used the JVM in a long time, but .NET Core starts up pretty damn quick from cold IL. I believe the tiered compilation approach has something to do with the fast startup + insane web benchmarks.
  - amelius 6y ago
    Did Microsoft Research publish papers on how the dotnet virtual machine pulls this off?
  - whizzter 6y ago
    The reason for benchmark performance isn't related to the JIT only but rather of .NET being more "pragmatic" with memory slices(usable with stack allocs,mmap), value types and in/out/ref passing. These little things together makes the .NET code run with far less GC pressure and more cache locality like C++ code without making the code non-idiomatic (Yes, A JVM system can be written like QuestDB to achieve similar perf but it won't be idiomatic Java code). Then the Kestrel server + new ASP.NET Core runtimes takes advantage of it (for example the new JSON parsing API's are built to directly consume byte memory w/o sacrificing too much extensibility).
  - pedrow 6y ago
    .NET has a Global Assembly Cache[0] which I think (please correct if I'm wrong) is used to pre-compile the system frameworks and so makes startup faster. [0]: https://docs.microsoft.com/en-us/dotnet/framework/app-domains/gac https://docs.microsoft.com/en-us/dotnet/framework/app-domain...
sremani 6y ago
OCaml to F# transition is more incremental than to Rust transition because so much of the existing code base could be re-used. .net core got better, faster and almost parity with the upcoming release.
rattray 6y ago
Wow, I remember learning about F# and thinking, "too bad it's stuck on Windows, I'll never use it". Awesome to hear that .NET Core has really changed that. How is the incremental typechecking experience, eg in vscode? (Speed, UX) Does F# have a prettier implementation or other fast/deterministic/opinionated formatter?
- JaggerJo 6y ago
  There is iodide for vscode. http://ionide.io http://ionide.io JetBrains Rider also supports it. Fantomas can be used as a formatter. https://github.com/fsprojects/fantomas https://github.com/fsprojects/fantomas
  - davidspiess 6y ago
    Ionide is not quite there yet when it comes to medium/big sized projects. I switched back to Visual Studio because Ionide simply stops working after a while. Even switching branch requires you restart VSCode. So be aware of that. Fantomas comes already bundled with Ionide and works pretty well. Has a few hick ups here and there as well.
    - georgewfraser 6y ago
      There’s F# language server, which is not as featureful as ionide but a lot faster.
      - JaggerJo 6y ago
        ahh interesting. I'm actually using Rider for most of my work
- madarcho 6y ago
  We use Rider (enterprise license) to develop our F# services. Over the past year, the experience kept improving, small tweaks kept coming, and bugs were sorted out. At the moment, some of our larger shared type definition files are a slow to edit (seems Rider/.net is trying like crazy to look over all the symbols before I've even finished typing), but overall, I had a very good experience with it. Not aware of any linters out there. Rider might have built in rules to enforce it, but that wouldn't hook into your CI/CD.
wombat23 6y ago
> I evaluated and expected not to like F#. I actually quite like it. It's funny because that's exactly how I felt when I learned F#. I felt pleasantly surprised and never felt like there was anything bad about the language itself. I just wish it wasn't so deeply embedded in the .NET ecosystem.
- moontear 6y ago
  Why is it bad that it is embedded in the .NET ecosystem?
  - chrisseaton 6y ago
    Doesn't have the same kind of large and innovative ecosystem around it, like competitors such as the JVM.
    - __float 6y ago
      It's true the JVM has a large ecosystem, but the .NET one is still pretty substantial. I would also argue there's a fair bit of innovation in the .NET Core world :)
      - chrisseaton 6y ago
        > I would also argue there's a fair bit of innovation in the .NET Core world :) They need to make it more visible if there is! I think it's pretty rare to see a .NET paper. I can't remember the last time I saw one, where there are tons of major JVM research projects.
        freeone3000 6y ago
        The innovation in the .net world tends to be by companies in the .NET ecosystem, which historically have not been focused on open source or open research. Improvements in the microsoft world tend to be private.
deleted 6y ago
[deleted]
devmunchies 6y ago
I’m trying to make the same decision right now. I’m the first product engineer at a AI startup and started using node.js but... meh (i use crystal for stuff and have exp in ocaml, elixir, ruby) I’m leaning towards f# or Scala. I love static typing. Since it’s a data science, machine learning company Scala makes more sense.
- siwatanejo 6y ago
  Before choosing Scala I think you should watch this talk: https://www.youtube.com/watch?v=uiJycy6dFSQ https://www.youtube.com/watch?v=uiJycy6dFSQ (note: he's not a troll, he worked 5 years with Scala)
- didibus 6y ago
  Woa, ya those initial choices for an AI startup seem so wrong. Scala sounds most reasonable, I'd say even consider Java to be honest.
  - cultus 6y ago
    I honestly don't see a huge value proposition in Scala, now that Java has reduced pain points around FP. Scala has higher-kinded types, but you see people tie themselves in knots with those as often as not. It is just such a huge language. Scala 3/Dotty sounds like it will be a big improvement.
    - yawaramin 6y ago
      Java doesn't have one of the fundamentals of typed FP--algebraic data types with exhaustive pattern matching. And just in general--Scala, despite its warts, can be very succinct and packs a lot of power in simple-looking code.
  - devmunchies 6y ago
    No, sorry. None of the languages I listed are being used at the startup (except node). These are just what I’ve used previously. Everything is in python but I’m building out the main user-facing app to interface with all the models.
Scarbutt 6y ago
What about using F# just for the compiler and C# for the rest of the backend? That way, the friction of using libraries goes away, for example, using asp.NET core or other third party libs will be smoother. Though joggling between two languages may seem to have higher cognitive overhead I think you are already doing this by having to call C# APIs in lots of places.
- rienbdj 6y ago
  There is no friction to using C# libraries in F#, it’s just that you will be using the imperative / OOP features of F# rather than the functional programming ones.
  - Scarbutt 6y ago
    There's overhead in reading documentation, ex: all of asp.net core docs and examples are in C#.
    - cjaybo 6y ago
      Does your proposed solution remove the need for reading documentation?
      - Scarbutt 6y ago
        No, the overhead will be in how to best map the F# to the C# code all the time while reading C# docs versus just not having this mental juggling in C#.
        piaste 6y ago
        There's barely any overhead to consuming c# libraries from f#. You type "open SomeLib" instead of "using SomeLib;" and "let x = SomeClass (foo, bar)" instead of "var x = new SomeClass(foo, bar)". You check return values with "match Option.ofObj value" instead of "if (value != null)".
  - 6y ago
throwaway284534 6y ago
Does anyone else see the irony here? The Dark engineers switched their core language with another because the open source ecosystem wasn't broad enough to cover their needs. And yet they're asking their customers to make the same bet on their proprietary language and platform. I mean just look at this FAQ[1]. There isn't a clear path out of vendor-lock in, a terms of service, or even a guarantee that the platform won't disappear without notice. - [1] https://darklang.com/language https://darklang.com/language
- throwaway894345 6y ago
  I agree with this criticism, but I wonder how they could monetize without locking in users. I suppose they could open source their toolchain so anyone could stand up their own Dark framework on-premise and maybe they sell support and/or a managed service and/or "enterprise features" (whatever those are in this context)? Maybe these things will come sometime after the private-beta (perhaps they're just getting a better feel for their product's value proposition before committing to opening any particular piece of it up)?
  - siwatanejo 6y ago
    I think it's easy to monetize: make the BCL dual license AGPL+proprietary
  - goldenshale 6y ago
    Or maybe this is why Dark is a bad business endeavor in the first place. I would never bet my company's future on something like this, and the toolchain doesn't seem sufficiently powerful to warrant the risk. Sorry, but this is no Clojure. Instead of a proper comment syntax you define a dummy variable to a string? Ghetto.
- pimterry 6y ago
  It's interesting to contrast with Docker, who similarly pitched an exciting new development model & ecosystem. In Docker's case, it was indeed non-proprietary, built on existing standards, and has now got to the stage where you can now swap Docker out for competing alternatives to avoid lock-in entirely. On the other hand, while that model went great for Docker the technology, it has not gone well for Docker the business. I imagine Dark might see Docker as a cautionary tale of why _not_ to go down that road.
dzonga 6y ago
F# is probably one of the best languages out there. but this again seems misguided, considering F# doesn't get the love from msoft that C# gets. you might as well use C# since it's slowing becoming F#.
- goto11 6y ago
  It is true that C# is gradually adopting features from F#, but F# will always be a much better F# than C# is. C# is great in its own right, but if you prefer F# why not use the real thing?
- Jtsummers 6y ago
  If you already have OCaml, the transition of OCaml->F# is a lot smaller than OCaml->C#. Once you move your core stuffs over to F# (with necessary changes), you can more easily make a decision from there of whether any particular new work should be F# or C#.
- rienbdj 6y ago
  Currying and partial application and a major reason to use F# over C#
- steego 6y ago
  While C# is slowly adopting features from F#, the biggest value that F# provides over C# isn't its feature set. The biggest value is having good default behavior and how it nudges programmers to favor predictable and composable solutions. There are a million features and defaults in C# that constantly undermine a programmer's attempts to create good compositional code. If you and your team is disciplined enough to avoid falling into the traps, that's good. But a lot of teams are not that disciplined and tend to churn out the same buggy OO code with the same subtle bugs caused by the same default semantics. Also, F# is a pretty powerful language for language nerds. There's a reason there are literally half-dozen F# to JavaScript compilers, not to mention Erlang, CUDA, PHP (I know), WASM, etc. Until they start removing features from C# (Maybe something like a strict mode), it will never be F#.
  - kirse 6y ago
blargmaster42_8 6y ago
Dark seems nice but since it's going .net it should codegen to a .net core 3.1 application.
isuckatcoding 6y ago
Legit thought this company was dead. Glad to see they’re still trying.
- pbiggar 6y ago
  Thanks! I think?
  - isuckatcoding 6y ago
    My bad. I think this tweet from a few months back confused me: https://twitter.com/paulbiggar/status/1275433005822214146?s=21 https://twitter.com/paulbiggar/status/1275433005822214146?s=... How many engineers/employees are you guys now after the restructure?
    - pbiggar 6y ago
      Ah yeah, that confused a lot of people. It's just me at the moment. Planning to scale up a little bit next year once I have a solid plan of how to get to product-market fit.
darthrupert 6y ago
Thus reducing the number of people who care about it from 24 to 7.
- pbiggar 6y ago
  HN needs a like button!
ltbarcly3 6y ago
If a technology nobody will ever use changes backends, does it make it to #1 on hackernews? Turns out this is an easy one, yes.
- pbiggar 6y ago
  No one was more surprised than me!
samgaw 6y ago
The thing that killed any interest I ever had in Dark was the license[1]. It’s beyond vendor lock-in, it’s suicide at an undetermined date. tldr: Help build it but don’t use it. -[1] https://github.com/darklang/dark/blob/main/LICENSE.md https://github.com/darklang/dark/blob/main/LICENSE.md
- robocat 6y ago
  Dark is a proprietary product with source available for the runtime. https://en.wikipedia.org/wiki/Source-available_software https://en.wikipedia.org/wiki/Source-available_software AFAIK their eventual target market is the “οἱ πολλοί”. No need to be so negative, you are just not their target market.
siliconc0w 6y ago
I appreciate the vision - most apps I see these days are glorified CRUD sprinkled with modest business logic and still end up being 1000s lines of code, testing, and configuration apiece.
Nelkins 6y ago
If you're interested in learning more about F#, I strongly suggest joining the F# Foundation Slack. Unfortunately they make it surprisingly difficult to join, you have to create an account on the F# Software Foundation website (https://fsharp.nationbuilder.com/forms/user_sessions/new https://fsharp.nationbuilder.com/forms/user_sessions/new) and then "join" the foundation (http://foundation.fsharp.org/join http://foundation.fsharp.org/join ; you'll see the option to join once you have an account). There's a large community of very helpful people willing to answer questions.
avestura 6y ago
Nice
Indy9000 6y ago
F# Is a good choice for cloud orchestration. MBrace was doing something similar to this atleast about 5yrs ago. I've written a ml pipeline entirely in F# with deployment. My 2p re: Dark Rather than creating a completely new language, Dark could just provide an API or a framework and use F# as the deployment scripting lang. F# is succinct and easy to learn and work with for the customers (DevOps). Beats yaml anyday. Writing a new language that is production ready is no small task.. takes years to get the syntax, stdlibs, and tooling right. By that time cloud computing may evolve into something else entirely..
- Nelkins 6y ago
  I'm really enjoying the trend in the F# community these days of using computation expressions for configuration. Means you can get great IDE support and type checking with configs. Some examples: 1. https://compositionalit.github.io/farmer/ https://compositionalit.github.io/farmer/ 2. https://twitter.com/Cody_S_Johnson/status/1323227775034155008 https://twitter.com/Cody_S_Johnson/status/132322777503415500... 3. https://github.com/UnoSD/Pulumi.FSharp.Extensions https://github.com/UnoSD/Pulumi.FSharp.Extensions 4. https://github.com/SaturnFramework/Saturn/blob/73855f08d9c50e5d94097c5ab12c786947c424fb/sample/Saturn.Sample/Saturn.Sample.fs#L145-L161 https://github.com/SaturnFramework/Saturn/blob/73855f08d9c50...
k33n 6y ago
LOL
noisy_boy 6y ago
As an aside, this article made me want to try out F# on Linux. I followed the steps on Microsoft website and was basically up and running a toy program in 10 minutes. Then I spent next 40 minutes trying to figure out how to configure ionide on VSCode to respect my line breaks and not make if/else statements a super-wide line. Considering both are Microsoft products, this wasn't a great developer experience. Or maybe I'm spoiled by the rich formatting customization provided by IntelliJ's formatter for Java/Scala.
- pbiggar 6y ago
  I had a similar experience. The syntax formatter is https://github.com/fsprojects/fantomas https://github.com/fsprojects/fantomas, and there are some controls, though not as many as I'd like.
  - noisy_boy 6y ago
    I tried fantomas by installing it and then using the vscode plugin to use it but it kept crashing when I tried to format with it.
- nestorD 6y ago
  Note that Ionide, while the recommended VS Code plugin, is not a Microsoft product (it is mostly the work of Krzysztof Cieslak).
  - noisy_boy 6y ago
    I know - however, it is mentioned in the official steps[0] for configuring F# with VS Code. [0]: https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/get-started-vscode https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/g...
offtop5 6y ago
Why would anyone pick this over say Python. Call me pessimistic , but I can't imagine the appeal of a closed source proprietary language when so many good open source ones are free. It just seems like really nasty Vendor lock in.
- pbiggar 6y ago
  We're trying to do a new thing. If people don't like it, that's fine. So far, people love the concept (no infrastructure, trace-driven development), but it hasn't been complete enough, so that's what I'm working on.
  - offtop5 6y ago
    Anyway I can just use Python which I already know ? The base concept is cool, I was more caught off guard by having to learn a new language here
- richeyryan 6y ago
  Assuming competitive pricing it seems like a high brow alternative to a small LAMP app. I used to contract for a telco in my country and we had a shared server with a bunch of virtual hosts for various purposes. Data capture forms, family and friends schemes, corporate social responsibility stuff etc. The core systems stuff was all Java enterprise inter-operating with off the shelf Oracle and TIBCO stuff. Building those small once off apps into the main infrastructure would have required involving the bigger suppliers who were more expensive and would be stonewalling you with change requests before long. If you weighed the risk and determined that you were happy with these non-revenue path applications being subject to that risk, I think it might be ok. That said using something like Heroku is close enough and at least your application code is mostly portable.
- toolslive 6y ago
  maybe because F# and OCaml are vastly superior languages compared to Python. Mind, I said language (not eco-system)
  - 6y ago
nikolay 6y ago
It's great I didn't invest a moment with this vaporware.
runT1ME 6y ago
A bit peculiar they selected a .NET language after running into a lack of libraries in OCaml. I'd be perfectly happy to use C# or F# the language, but I still find .NET lagging behind the JVM/Python/Go ecosystems. Two large OSS projects I'm using for work are Scylla and Apache Beam, both of which don't have native support for .NET, and I'm sure we can find plenty of others.
- yellowapple 6y ago
  > but I still find .NET lagging behind the JVM/Python/Go ecosystems It probably depends on what libraries you seek. In the enterprise software world the only options for a vendor's library/SDK are often .NET or JVM (and asking them "Do you have a Python or Go library" will probably elicit a response of "What in tarnation do snakes and board games have to do with programming?"). As for whether it's CLR or JVM, the question's usually answerable with: if vendor.preferred_os == 'Windows': 'CLR' else: 'JVM' And since Windows is still pretty commonplace in a lot of smaller enterprise software shops, CLR ends up being the norm for a lot of the COTS products out there.
  - brown9-2 6y ago
    Its not necessary to speculate, the blog post about moving away from OCaml specifically talked about cloud provider SDKs (AWS and GCP): https://medium.com/darklang/leaving-ocaml-fce7049a2a40?source=rss-56c9b6a1f3e4------2 https://medium.com/darklang/leaving-ocaml-fce7049a2a40?sourc...
    - yellowapple 6y ago
      I was talking more in general, beyond Dark's specific needs. But yes, in Dark's scenario the library availability issues are clearer.
- thelazydogsback 6y ago
  Go?! I don't think there's even a comparison here -- the .Net ecosystem is huge compared to such a newcomer. I've been looking at .Net libs (for F# and C#) and JVM libs (for Clojure) recently, and I've came across way more old, crufty, poorly-documented Java libs than the .Net ones.
assert49 6y ago
Such posts are really annoying and meaningless to a large extent. Even worse this proves that their own language is not stable to invest in. I see no business value proposition too. Seems more like a bunch of folks geeking on stuff. Also heard from sources that the founder is quite an arrogant guy and not easy to work with. It's sad that investors hedge their bets on such wonky projects without understanding how this translates into a use case.
dhosek 6y ago
I was recently making a similar language decision about a project that I've foolishly started. Since I wanted my code to be easily portable and also (for my own use) wanted it to be able to run on iOS and MacOS, I ended up selecting C++ as the language [1]. I've got about 20 years of C++ evolution to catch up on and there are a lot of things that I haven't had to think about in those twenty years (I spent a couple days making sure I grokked universal references and why I would care), but as I've explored what libraries are available for my use case, I think it's the right choice. [1] https://www.finl.xyz/2020/10/21/choosing-a-programming-language/ https://www.finl.xyz/2020/10/21/choosing-a-programming-langu...
joseluisq 6y ago
> Initially, I expected to go to Rust. Rust has excellent tooling, great libraries, a delightful community, etc. But after spending about a month on it, I can't say I like writing Rust. Especially, I don't like writing async code in Rust. I like a nice high level language, and that's kinda what you need when you have a project as big as Dark to build. And Rust is not that. I'll publish "Why Dark didn't choose Rust" next. I'm interested in the next post of the author elaborating a bit more why Rust wasn't an option here. As I understood, the author has just discarded Rust because wants a "nice high level language" (aside async writing) which is something relative IMO.
UncleOxidant 6y ago
I'll preface this by saying I'm not even sure what darklang is - I didn't find a concise description of what it is and it's for, only some videos which I really don't have time to watch right now... But doesn't moving to F# pretty much mean that the users of darklang will be forced into the Windows ecosystem?
- BjorksEgo 6y ago
  F# is open source and cross platform now since .Net Core
davidgrenier 6y ago
If I may recommend, try to find and read a copy of John Reppy's Concurrent Programming in ML. The book is a little bit of an eye opener if only for that. Hopac is a library that offers an excellent delivery of this model of concurrent programming on .NET and has top notch F# primitives.
chrischen 6y ago
Curious how this compares to js_of_ocaml or Rescript that gives ocaml the JS ecosystem?
massung 6y ago
Having read the previous HN post on this (leaving Ocaml) and this one, I'm going to post a different perspective on this. As a programmer, I love reading blog posts about why someone made something, how they made it, and what tools they chose to use/create to facilitate their end-goals. Some of the frustrations the OP had with respect to Ocaml are some I - and many others - have experienced as well. Enumerating those constructively can potentially benefit the Ocaml community as well. However, as a possible target user... Reading blog posts like these are _scary_. It is very rare that I want to read a "hey, that service you use regularly? yeah, we decided to rebuild it from the ground up using entirely new tools 'just because'". Will I still be able to work? Should I postpone signing up/paying? What new bugs will appear? Which features I currently rely on will change or outright disappear/cease to work? What edge cases that are currently handled will be forgotten? The list goes on... There are often very legitimate answers to these questions, and sometimes taking a HUGE step back in order to meet demands you didn't know existed before is what's required. But those requirements, and how this step back will address them, should be clearly laid out to your users. More importantly, work such as this postpones any current roadmap features (potential) users may be waiting for and have been previously promised. Presumably an analysis has been done on how much they'd be postponed by, and why those features will benefit greatly once done. Sharing that would also be extremely helpful in assuaging concerns.
- deleted 6y ago
  [deleted]
askyc12345 6y ago
Guys, does it make sense to switch from C# to F#? I mean, C# adds more and more F# features each year and I think they will probably be on a par with F# in 3-4 years. By the way, native immutable records will be added to C# next week in C# 9.
- akra 6y ago
  IMO it depends especially if your coming from C# - sometimes yes, sometimes no for existing code bases. On the features you mention while some of those features are being added to C# (and not all of them are planned to) from what I've seen they often aren't as powerful/useful as the F# version, are not as consistent/concise due to legacy syntax or don't interact with other features as well. F# is also taking C# features so its not like you will be left behind either (e.g. Span). For me more importantly the underlying defaults are a feature that can't be ported which IMO F# wins here. C# is a fine OO language having worked with both extensively, just F# IMO is slightly better with less ceremony than typical C# code. Is it worth switching? It depends on your problem and where your starting from. In this case they are switching from OCAml so F# probably makes more sense. If your starting from a clean state it all depends tbh what you find easier to learn - IMO many JS/Python/Go/etc programmers if trying .NET Core might find F# easier than moving to C#/Java from their own personal preferences - its often called a "typed Python" by users. For C# users probably less so; but learning it might change your C# code style for the better.

347 points by nikivi 6y ago

I'm rooting for Dark, it's such a breath of fresh air, really hope this works out! I hope HN can forgive Pul for choosing F# over Rust :) Does anyone have experience porting code from OCaml or other MLs to F#, how does it work out?

__s 6y ago

> It actually has a much better type system, in my opinion. I don't know how anyone can say that with a straight face about a type system that has both Option & null (granted Rust technically runs into this, but they go out of their way so that you should never be using pointers unless you want to. Whereas in F# you'll run into this using references, & you'd expect interfacing to C# APIs wouldn't take the care that interfacing with C APIs does) That said, F# does sound like a good fit for them, so one funny reasoning aside, dive in. I enjoyed F# when I was able to use it

gameswithgo 6y ago
There are like a thousand little details a type system has, and you focus on one thing, the existence of null for .NET interop, and decide this means the type system can't be overall better?
- McWobbleston 6y ago
  The null thing is a bad example, particularly because it's from the .NET side and C# is focusing on removing that now through nullable reference types, but I'm honestly surprised they claimed F# has a better type system. F# lacks functors, first class modules, row polymorphism, GADTs, PPX extensions, and likely some others I'm not aware of. GADTs, row polymorphism, and PPX extensions I've wished for in particular because they solve some problems I frequently run into with MVU/Elmish architecture on the front end. F# instead has inline functions with static constraints (similar to C++ templates), type providers, computation expressions, and units of measure.
zzbzq 6y ago
I worked on some Scala codebases, which has this problem. It even lets you end up with Some(null). I call it the two billion dollar mistake.
- yawaramin 6y ago
  Was this because the devs didn't know about Option.apply?
ojnabieoot 6y ago
I have been using F# for 5 years and have never once needed to use “null” anywhere in my code - if I were to interact with a C# library I think null-handling is an acceptable price to pay for the interop (similar to weirdness with OCaml/Haskell and C FFI). F# makes that particular separation of concerns very clean and easy to handle. Idiomatic F# is safe against null reference exceptions. I think you’re needling a small wart in F# due to the .NET requirement, it’s hardly enough to say that F#’s type system is overall bad.
- StreamBright 6y ago
  >> I think null-handling is an acceptable price to pay for the interop Especially given how easy it is to deal with it. Option.ofObj what we use most of the time.
phillipcarter 6y ago
> Whereas in F# you'll run into this using references It depends :) F#-defined reference types cannot be assigned a null value by default. If your reference is an F# library (or one with F# bindings, of which there are several) then this isn't something you run into. Technically this can be bypassed by giving the type an attribute called AllowNullLiteral, but it is extremely rare to see that in practice because it's so unsatisfactory to use null from a cultural perspective in F#. Once a C# programmer uses F#, something switches on in their brain and they tend to eliminate all possible ways null can creep in as thoroughly as possible. It's neat. Another aspect where you don't see null is in initialization soundness. In F#, all values must be initialized before use. This is in sharp contrast to C# or Java where you can accidentally access something that hasn't been initialized before. While you can also technically bypass this to inject a null somewhere, it is also exceedingly rare because it's not a default behavior. F# data types also cannot be assigned a null value, so that's also a place where null doesn't come in. So it really leaves interop with .NET assemblies, some serialization scenarios, and .NET reflection. The first is really the only time people can still get "surprised" by a _null_ value. The rest are all technically possible, but just tend not to come up. The reason why this all matters is it's not a binary thing about having null/non-null. Just like it's not a binary thing about having exceptions/vs. not. It's about how frequently they can come about in normal programming scenarios. I can write a simple Haskell program that throws an exception at runtime, does that mean that Haskell is not safe? Of course not, because it's not usually what normal Haskell code does. The same thinking applies here. The ways that null can creep into an F# program are simply smaller than C# or Java and do create this mindset that nullis something that F# programmers tend not to think about that much.

melling 6y ago

From yesterday’s story about leaving OCaml: https://news.ycombinator.com/item?id=24974907 https://news.ycombinator.com/item?id=24974907

bachmeier 6y ago

The title is not a surprise, based on the previous post. The one surprise is that he seriously considered Rust. > "you'll never believe just how much a Garbage Collector does for you!" Of course, that's why it's hard to see someone moving from OCaml to Rust for any reason other than wanting to use Rust.

pjmlp 6y ago
As mentioned elsewhere, I believe that automatic memory management + affine types will win in what concerns masses adoption. Rust has been the catalyst to force language designers to look more seriously into affine types, but its use can only be justified in "no way GC/RC" scenarios like MISRA.
- mpweiher 6y ago
  To me, it looks like the sweet spot might be RC + weak references, which in terms of ease of use is close enough to a tracing GC as to not matter, + the ability to tune away the RC ops in specific circumstances, for example using affine types.
- darksaints 6y ago
  Its use can be justified elsewhere, but it should always be understood that manual memory management is always going to be more difficult. The problem I see, and the reason I sometimes reach for rust when I don't really require manual memory management, is that nothing else is really better for strongly-typed statically-compiled self-contained executables. Go: it's got the convenience and packaging and ecosystem, but an absolute shit type system. F#: carries around the baggage of the CLR, and the best tooling is Windows-exclusive. Type system is good but not as good as others. Scala: absolutely amazing type system, but lots of unneeded stuff too. JVM packaging is a huge pain, and pretty heavy weight. Native compilation options are few and have slow executables in comparison. OCaml: tiny ecosystem, multicore is always one year away, some weird ergonomic choices. Haskell: lazy, IO has terrible ergonomics, and the community consists of pie-in-the-sky type theorists. I would kill for a Dotty-like (Scala 3) native programming language that could omit all of the bullshit that was required to fit into the JVM and work with java libraries.

Jhsto 6y ago

Anyone here used dark? Any anecdotal experience report you could share?

andymoe 6y ago
It has great potential. I think the unique integrated web ide, tracing, function level versioning and deployment model are game changing. Anyone not going in this direction with their FaaS products should stop what they are doing and reevaluate. That said, his motivation for rewriting it is the right call. Dark does not have enough of a standard library for third party integrations (among other issues) or a way to easily contribute them which makes it tough to build in the large. I’m really rooting for Dark - even with the rough edges it feels like the future and how I want to eventually build software.
- mpweiher 6y ago
  Yes. The initial PR was a bit misguided IMHO, and left a big "huh?". The futureofcoding interviews were much better, what they are doing is really interesting, though I am unconvinced that all the stuff they're doing is actually required to achieve their goals. For example, they claim that a structured editor is required, but if per-method granularity is good enough, then a normal method browser would work just as well. As far as I can tell. https://futureofcoding.org/episodes/043 https://futureofcoding.org/episodes/043
tnolet 6y ago
Did not use it, but looked at it quite a bit. Felt like Force.com and the Apex language for the modern age.

bartleby_ 6y ago

I got a chance to start using F# for the first time for some cryptography course assignments and supremely enjoyed it. Having a language that's easy to script with, has access to .Net libraries for everything and is easy to run on any major OS is kinda great.

toolslive 6y ago

the advantage of F# over OCaml is that your ecosystem is way larger... you can always 'snarf' c# libraries.

randompwd 6y ago
sure, but c# ecosystem is nothing compared to jvm, rails, go, js etc..
- eatonphil 6y ago
  Sure, but there's no equivalently mature OCaml-like language for the JVM (Scala doesn't count)
  - Ivoah 6y ago
    Asking as someone with no OCaml experience but who quite enjoys Scala, why does it not count?
    - dkarl 6y ago
      I don't know OCaml, so I can't give you a great answer, but I know that OCaml has a different type system that has some features that Scala 2 lacks, such as union types.
      - yawaramin 6y ago
        OCaml doesn't have union types. It has what it calls variants, and what is generally known as Algebraic Data Types. So does Scala 2.
    - eatonphil 6y ago
      They are radically different languages, even if they're from the same family. Scala is about as similar to OCaml as Rust is to OCaml. Rust and Scala are a world apart from OCaml and Standard ML in terms of language complexity. And then F# literally has an OCaml compat mode because they are so similar (F# has a bunch of convenient syntax extensions if you don't mind not using the compat mode).

blunte 6y ago

I read good things about F#, including that it is a first class citizen of Microsoft... but I have worries that it could become second class if some financial decision deems it not worth the effort to support for them. From a functional perspective, I would think the two primary candidates would have been F# with its .NET ecosystem or Clojure with its Java ecosystem. Both are similar in more ways than other languages, especially considering the rich set of libraries available... But to me the deciding factor would be ClojureScript for the front end. They stuck with ReasonML, if I read correctly, because they already had so much code (50k lines?). But at the same time, the previous post complained about the build tools. Plus it's still Ocaml...

eterm 6y ago
F# is 15 years old and there has been a "F# foundation" for past 5 of those. If your concern about Microsoft abandoning F# is genuine then perhaps that can re-assure you.
airstrike 6y ago
I keep reading good things about F# but at the same time it seems to fly under the radar, with not enough learning material out there I did love this one article http://tomasp.net/blog/2018/write-your-own-excel/ http://tomasp.net/blog/2018/write-your-own-excel/ EDIT: Submitted the link here https://news.ycombinator.com/item?id=24980325 https://news.ycombinator.com/item?id=24980325
- dangets 6y ago
  I agree in the difficulty of finding abundant, good examples for F#. I'll throw out some plugs for ones that I liked. * https://pragprog.com/titles/swdddf/domain-modeling-made-functional/ https://pragprog.com/titles/swdddf/domain-modeling-made-func... Uses F# as implementation language, though I cannot recommend this book enough for general type-safe design modeling regardless of the language. * https://fsharpforfunandprofit.com/ https://fsharpforfunandprofit.com/ Website of the author of the book mentioned above. He also has some good Youtube videos on the topic. * https://www.demystifyfp.com/FsApplied/ https://www.demystifyfp.com/FsApplied/ A book that will walk you though developing a webserver, and also introduces you to Paket for dependency management. I don't develop F# (or .NET) professionally, but I had fun when I played around with it. I found the interop with C# very seamless as well.

jrumbut 6y ago

This is a great article but I really wish that somewhere on the page it said what a Dark is and why I would want one. I tried clicking homepage it wasn't there, I tried clicking demo and it tried to open YouTube which was not what I wanted to happen, then finally I found it in the documentation section. The first sentence or two from there, maybe as a subtitle or in the intro paragraph would help I think.

Cthulhu_ 6y ago
idk, I clicked Homepage and the blurb was right there. Looks like a language / environment to build serverless apps.
- kev009 6y ago
  One thing that makes it hard to grok is how large the scope seems to be and the cognitive bias many devs have developed against new platforms due to being burned in the past. It reminds me of a throwback to 90s era RADs that wanted to encompass everything for everyone without really having clear intent or at least a platform company backing them to snare enough users to become a new platform. Sometimes there are gems in the rough in things like that like Delphi, and I don't mean to dismiss any of the ideas or dreams, but IMO platform companies are going to continue to monopolize the language space (for instance, I see great irony in they are using .NET because Microsoft basically does what they are trying to do). So that's why I bring up Delphi above, it seems this could be an opinionated framework on top of a .NET language instead of yet another language?
  - seibelj 6y ago
    It looks like Dark is trying to be a new language, a backend server, a CI solution, and an IDE! Then there is a blog post that everyone churns: > Currently, we get 10 user signups a day, and on average, 0 of them stick. We do have developers who love Dark, but not enough. https://roadmap.darklang.com/goals-of-dark-v2 https://roadmap.darklang.com/goals-of-dark-v2 I think the company should focus on just one of those things and it would still be an enormous lift given their size. > The problems and fixes are across the product. One problem is that undo is slow, another is that you can't put a minus sign in front of an integer, another is that we need to define how namespaces will work in the package manager. The fixes range from adding tooltips in the UI, to adding a type-checker, to making the package manager public. https://blog.darklang.com/dark-v2-roadmap/ https://blog.darklang.com/dark-v2-roadmap/ Ayeeeee... this is like trying to carve Mount Rushmore using a spoon.

amelius 6y ago

How is the dotnet virtual machine compared to the java virtual machine? (memory use, performance, startup time)

mythz 6y ago
ASP.NET Core (Linux/Kestrel/C#) has the fastest plain-text performance on Tech Empower benchmarks (7.3M /rps): https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r19&hw=... It's also one of the more full-featured web frameworks benchmarked.
bob1029 6y ago
I haven't used the JVM in a long time, but .NET Core starts up pretty damn quick from cold IL. I believe the tiered compilation approach has something to do with the fast startup + insane web benchmarks.
- amelius 6y ago
  Did Microsoft Research publish papers on how the dotnet virtual machine pulls this off?
- whizzter 6y ago
  The reason for benchmark performance isn't related to the JIT only but rather of .NET being more "pragmatic" with memory slices(usable with stack allocs,mmap), value types and in/out/ref passing. These little things together makes the .NET code run with far less GC pressure and more cache locality like C++ code without making the code non-idiomatic (Yes, A JVM system can be written like QuestDB to achieve similar perf but it won't be idiomatic Java code). Then the Kestrel server + new ASP.NET Core runtimes takes advantage of it (for example the new JSON parsing API's are built to directly consume byte memory w/o sacrificing too much extensibility).
- pedrow 6y ago
  .NET has a Global Assembly Cache[0] which I think (please correct if I'm wrong) is used to pre-compile the system frameworks and so makes startup faster. [0]: https://docs.microsoft.com/en-us/dotnet/framework/app-domains/gac https://docs.microsoft.com/en-us/dotnet/framework/app-domain...

sremani 6y ago

OCaml to F# transition is more incremental than to Rust transition because so much of the existing code base could be re-used. .net core got better, faster and almost parity with the upcoming release.

rattray 6y ago

Wow, I remember learning about F# and thinking, "too bad it's stuck on Windows, I'll never use it". Awesome to hear that .NET Core has really changed that. How is the incremental typechecking experience, eg in vscode? (Speed, UX) Does F# have a prettier implementation or other fast/deterministic/opinionated formatter?

JaggerJo 6y ago
There is iodide for vscode. http://ionide.io http://ionide.io JetBrains Rider also supports it. Fantomas can be used as a formatter. https://github.com/fsprojects/fantomas https://github.com/fsprojects/fantomas
- davidspiess 6y ago
  Ionide is not quite there yet when it comes to medium/big sized projects. I switched back to Visual Studio because Ionide simply stops working after a while. Even switching branch requires you restart VSCode. So be aware of that. Fantomas comes already bundled with Ionide and works pretty well. Has a few hick ups here and there as well.
  - georgewfraser 6y ago
    There’s F# language server, which is not as featureful as ionide but a lot faster.
    - JaggerJo 6y ago
      ahh interesting. I'm actually using Rider for most of my work
madarcho 6y ago
We use Rider (enterprise license) to develop our F# services. Over the past year, the experience kept improving, small tweaks kept coming, and bugs were sorted out. At the moment, some of our larger shared type definition files are a slow to edit (seems Rider/.net is trying like crazy to look over all the symbols before I've even finished typing), but overall, I had a very good experience with it. Not aware of any linters out there. Rider might have built in rules to enforce it, but that wouldn't hook into your CI/CD.

wombat23 6y ago

> I evaluated and expected not to like F#. I actually quite like it. It's funny because that's exactly how I felt when I learned F#. I felt pleasantly surprised and never felt like there was anything bad about the language itself. I just wish it wasn't so deeply embedded in the .NET ecosystem.

moontear 6y ago
Why is it bad that it is embedded in the .NET ecosystem?
- chrisseaton 6y ago
  Doesn't have the same kind of large and innovative ecosystem around it, like competitors such as the JVM.
  - __float 6y ago
    It's true the JVM has a large ecosystem, but the .NET one is still pretty substantial. I would also argue there's a fair bit of innovation in the .NET Core world :)
    - chrisseaton 6y ago
      > I would also argue there's a fair bit of innovation in the .NET Core world :) They need to make it more visible if there is! I think it's pretty rare to see a .NET paper. I can't remember the last time I saw one, where there are tons of major JVM research projects.
      - freeone3000 6y ago
        The innovation in the .net world tends to be by companies in the .NET ecosystem, which historically have not been focused on open source or open research. Improvements in the microsoft world tend to be private.

deleted 6y ago

[deleted]

devmunchies 6y ago

I’m trying to make the same decision right now. I’m the first product engineer at a AI startup and started using node.js but... meh (i use crystal for stuff and have exp in ocaml, elixir, ruby) I’m leaning towards f# or Scala. I love static typing. Since it’s a data science, machine learning company Scala makes more sense.

siwatanejo 6y ago
Before choosing Scala I think you should watch this talk: https://www.youtube.com/watch?v=uiJycy6dFSQ https://www.youtube.com/watch?v=uiJycy6dFSQ (note: he's not a troll, he worked 5 years with Scala)
didibus 6y ago
Woa, ya those initial choices for an AI startup seem so wrong. Scala sounds most reasonable, I'd say even consider Java to be honest.
- cultus 6y ago
  I honestly don't see a huge value proposition in Scala, now that Java has reduced pain points around FP. Scala has higher-kinded types, but you see people tie themselves in knots with those as often as not. It is just such a huge language. Scala 3/Dotty sounds like it will be a big improvement.
  - yawaramin 6y ago
    Java doesn't have one of the fundamentals of typed FP--algebraic data types with exhaustive pattern matching. And just in general--Scala, despite its warts, can be very succinct and packs a lot of power in simple-looking code.
- devmunchies 6y ago
  No, sorry. None of the languages I listed are being used at the startup (except node). These are just what I’ve used previously. Everything is in python but I’m building out the main user-facing app to interface with all the models.

Scarbutt 6y ago

What about using F# just for the compiler and C# for the rest of the backend? That way, the friction of using libraries goes away, for example, using asp.NET core or other third party libs will be smoother. Though joggling between two languages may seem to have higher cognitive overhead I think you are already doing this by having to call C# APIs in lots of places.

rienbdj 6y ago
There is no friction to using C# libraries in F#, it’s just that you will be using the imperative / OOP features of F# rather than the functional programming ones.
- Scarbutt 6y ago
  There's overhead in reading documentation, ex: all of asp.net core docs and examples are in C#.
  - cjaybo 6y ago
    Does your proposed solution remove the need for reading documentation?
    - Scarbutt 6y ago
      No, the overhead will be in how to best map the F# to the C# code all the time while reading C# docs versus just not having this mental juggling in C#.
      - piaste 6y ago
        There's barely any overhead to consuming c# libraries from f#. You type "open SomeLib" instead of "using SomeLib;" and "let x = SomeClass (foo, bar)" instead of "var x = new SomeClass(foo, bar)". You check return values with "match Option.ofObj value" instead of "if (value != null)".
- 6y ago

throwaway284534 6y ago

Does anyone else see the irony here? The Dark engineers switched their core language with another because the open source ecosystem wasn't broad enough to cover their needs. And yet they're asking their customers to make the same bet on their proprietary language and platform. I mean just look at this FAQ[1]. There isn't a clear path out of vendor-lock in, a terms of service, or even a guarantee that the platform won't disappear without notice. - [1] https://darklang.com/language https://darklang.com/language

throwaway894345 6y ago
I agree with this criticism, but I wonder how they could monetize without locking in users. I suppose they could open source their toolchain so anyone could stand up their own Dark framework on-premise and maybe they sell support and/or a managed service and/or "enterprise features" (whatever those are in this context)? Maybe these things will come sometime after the private-beta (perhaps they're just getting a better feel for their product's value proposition before committing to opening any particular piece of it up)?
- siwatanejo 6y ago
  I think it's easy to monetize: make the BCL dual license AGPL+proprietary
- goldenshale 6y ago
  Or maybe this is why Dark is a bad business endeavor in the first place. I would never bet my company's future on something like this, and the toolchain doesn't seem sufficiently powerful to warrant the risk. Sorry, but this is no Clojure. Instead of a proper comment syntax you define a dummy variable to a string? Ghetto.
pimterry 6y ago
It's interesting to contrast with Docker, who similarly pitched an exciting new development model & ecosystem. In Docker's case, it was indeed non-proprietary, built on existing standards, and has now got to the stage where you can now swap Docker out for competing alternatives to avoid lock-in entirely. On the other hand, while that model went great for Docker the technology, it has not gone well for Docker the business. I imagine Dark might see Docker as a cautionary tale of why _not_ to go down that road.

dzonga 6y ago

F# is probably one of the best languages out there. but this again seems misguided, considering F# doesn't get the love from msoft that C# gets. you might as well use C# since it's slowing becoming F#.

goto11 6y ago
It is true that C# is gradually adopting features from F#, but F# will always be a much better F# than C# is. C# is great in its own right, but if you prefer F# why not use the real thing?
Jtsummers 6y ago
If you already have OCaml, the transition of OCaml->F# is a lot smaller than OCaml->C#. Once you move your core stuffs over to F# (with necessary changes), you can more easily make a decision from there of whether any particular new work should be F# or C#.
rienbdj 6y ago
Currying and partial application and a major reason to use F# over C#
steego 6y ago
While C# is slowly adopting features from F#, the biggest value that F# provides over C# isn't its feature set. The biggest value is having good default behavior and how it nudges programmers to favor predictable and composable solutions. There are a million features and defaults in C# that constantly undermine a programmer's attempts to create good compositional code. If you and your team is disciplined enough to avoid falling into the traps, that's good. But a lot of teams are not that disciplined and tend to churn out the same buggy OO code with the same subtle bugs caused by the same default semantics. Also, F# is a pretty powerful language for language nerds. There's a reason there are literally half-dozen F# to JavaScript compilers, not to mention Erlang, CUDA, PHP (I know), WASM, etc. Until they start removing features from C# (Maybe something like a strict mode), it will never be F#.
- kirse 6y ago

blargmaster42_8 6y ago

Dark seems nice but since it's going .net it should codegen to a .net core 3.1 application.

isuckatcoding 6y ago

Legit thought this company was dead. Glad to see they’re still trying.

pbiggar 6y ago
Thanks! I think?
- isuckatcoding 6y ago
  My bad. I think this tweet from a few months back confused me: https://twitter.com/paulbiggar/status/1275433005822214146?s=21 https://twitter.com/paulbiggar/status/1275433005822214146?s=... How many engineers/employees are you guys now after the restructure?
  - pbiggar 6y ago
    Ah yeah, that confused a lot of people. It's just me at the moment. Planning to scale up a little bit next year once I have a solid plan of how to get to product-market fit.

darthrupert 6y ago

Thus reducing the number of people who care about it from 24 to 7.

pbiggar 6y ago
HN needs a like button!

ltbarcly3 6y ago

If a technology nobody will ever use changes backends, does it make it to #1 on hackernews? Turns out this is an easy one, yes.

pbiggar 6y ago
No one was more surprised than me!

samgaw 6y ago

The thing that killed any interest I ever had in Dark was the license[1]. It’s beyond vendor lock-in, it’s suicide at an undetermined date. tldr: Help build it but don’t use it. -[1] https://github.com/darklang/dark/blob/main/LICENSE.md https://github.com/darklang/dark/blob/main/LICENSE.md

robocat 6y ago
Dark is a proprietary product with source available for the runtime. https://en.wikipedia.org/wiki/Source-available_software https://en.wikipedia.org/wiki/Source-available_software AFAIK their eventual target market is the “οἱ πολλοί”. No need to be so negative, you are just not their target market.

siliconc0w 6y ago

I appreciate the vision - most apps I see these days are glorified CRUD sprinkled with modest business logic and still end up being 1000s lines of code, testing, and configuration apiece.

Nelkins 6y ago

If you're interested in learning more about F#, I strongly suggest joining the F# Foundation Slack. Unfortunately they make it surprisingly difficult to join, you have to create an account on the F# Software Foundation website (https://fsharp.nationbuilder.com/forms/user_sessions/new https://fsharp.nationbuilder.com/forms/user_sessions/new) and then "join" the foundation (http://foundation.fsharp.org/join http://foundation.fsharp.org/join ; you'll see the option to join once you have an account). There's a large community of very helpful people willing to answer questions.

avestura 6y ago

Nice

Indy9000 6y ago

F# Is a good choice for cloud orchestration. MBrace was doing something similar to this atleast about 5yrs ago. I've written a ml pipeline entirely in F# with deployment. My 2p re: Dark Rather than creating a completely new language, Dark could just provide an API or a framework and use F# as the deployment scripting lang. F# is succinct and easy to learn and work with for the customers (DevOps). Beats yaml anyday. Writing a new language that is production ready is no small task.. takes years to get the syntax, stdlibs, and tooling right. By that time cloud computing may evolve into something else entirely..

Nelkins 6y ago
I'm really enjoying the trend in the F# community these days of using computation expressions for configuration. Means you can get great IDE support and type checking with configs. Some examples: 1. https://compositionalit.github.io/farmer/ https://compositionalit.github.io/farmer/ 2. https://twitter.com/Cody_S_Johnson/status/1323227775034155008 https://twitter.com/Cody_S_Johnson/status/132322777503415500... 3. https://github.com/UnoSD/Pulumi.FSharp.Extensions https://github.com/UnoSD/Pulumi.FSharp.Extensions 4. https://github.com/SaturnFramework/Saturn/blob/73855f08d9c50e5d94097c5ab12c786947c424fb/sample/Saturn.Sample/Saturn.Sample.fs#L145-L161 https://github.com/SaturnFramework/Saturn/blob/73855f08d9c50...

k33n 6y ago

LOL

noisy_boy 6y ago

As an aside, this article made me want to try out F# on Linux. I followed the steps on Microsoft website and was basically up and running a toy program in 10 minutes. Then I spent next 40 minutes trying to figure out how to configure ionide on VSCode to respect my line breaks and not make if/else statements a super-wide line. Considering both are Microsoft products, this wasn't a great developer experience. Or maybe I'm spoiled by the rich formatting customization provided by IntelliJ's formatter for Java/Scala.

pbiggar 6y ago
I had a similar experience. The syntax formatter is https://github.com/fsprojects/fantomas https://github.com/fsprojects/fantomas, and there are some controls, though not as many as I'd like.
- noisy_boy 6y ago
  I tried fantomas by installing it and then using the vscode plugin to use it but it kept crashing when I tried to format with it.
nestorD 6y ago
Note that Ionide, while the recommended VS Code plugin, is not a Microsoft product (it is mostly the work of Krzysztof Cieslak).
- noisy_boy 6y ago
  I know - however, it is mentioned in the official steps[0] for configuring F# with VS Code. [0]: https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/get-started-vscode https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/g...

offtop5 6y ago

Why would anyone pick this over say Python. Call me pessimistic , but I can't imagine the appeal of a closed source proprietary language when so many good open source ones are free. It just seems like really nasty Vendor lock in.

pbiggar 6y ago
We're trying to do a new thing. If people don't like it, that's fine. So far, people love the concept (no infrastructure, trace-driven development), but it hasn't been complete enough, so that's what I'm working on.
- offtop5 6y ago
  Anyway I can just use Python which I already know ? The base concept is cool, I was more caught off guard by having to learn a new language here
richeyryan 6y ago
Assuming competitive pricing it seems like a high brow alternative to a small LAMP app. I used to contract for a telco in my country and we had a shared server with a bunch of virtual hosts for various purposes. Data capture forms, family and friends schemes, corporate social responsibility stuff etc. The core systems stuff was all Java enterprise inter-operating with off the shelf Oracle and TIBCO stuff. Building those small once off apps into the main infrastructure would have required involving the bigger suppliers who were more expensive and would be stonewalling you with change requests before long. If you weighed the risk and determined that you were happy with these non-revenue path applications being subject to that risk, I think it might be ok. That said using something like Heroku is close enough and at least your application code is mostly portable.
toolslive 6y ago
maybe because F# and OCaml are vastly superior languages compared to Python. Mind, I said language (not eco-system)
- 6y ago

nikolay 6y ago

It's great I didn't invest a moment with this vaporware.

runT1ME 6y ago

A bit peculiar they selected a .NET language after running into a lack of libraries in OCaml. I'd be perfectly happy to use C# or F# the language, but I still find .NET lagging behind the JVM/Python/Go ecosystems. Two large OSS projects I'm using for work are Scylla and Apache Beam, both of which don't have native support for .NET, and I'm sure we can find plenty of others.

yellowapple 6y ago
> but I still find .NET lagging behind the JVM/Python/Go ecosystems It probably depends on what libraries you seek. In the enterprise software world the only options for a vendor's library/SDK are often .NET or JVM (and asking them "Do you have a Python or Go library" will probably elicit a response of "What in tarnation do snakes and board games have to do with programming?"). As for whether it's CLR or JVM, the question's usually answerable with: if vendor.preferred_os == 'Windows': 'CLR' else: 'JVM' And since Windows is still pretty commonplace in a lot of smaller enterprise software shops, CLR ends up being the norm for a lot of the COTS products out there.
- brown9-2 6y ago
  Its not necessary to speculate, the blog post about moving away from OCaml specifically talked about cloud provider SDKs (AWS and GCP): https://medium.com/darklang/leaving-ocaml-fce7049a2a40?source=rss-56c9b6a1f3e4------2 https://medium.com/darklang/leaving-ocaml-fce7049a2a40?sourc...
  - yellowapple 6y ago
    I was talking more in general, beyond Dark's specific needs. But yes, in Dark's scenario the library availability issues are clearer.
thelazydogsback 6y ago
Go?! I don't think there's even a comparison here -- the .Net ecosystem is huge compared to such a newcomer. I've been looking at .Net libs (for F# and C#) and JVM libs (for Clojure) recently, and I've came across way more old, crufty, poorly-documented Java libs than the .Net ones.

assert49 6y ago

Such posts are really annoying and meaningless to a large extent. Even worse this proves that their own language is not stable to invest in. I see no business value proposition too. Seems more like a bunch of folks geeking on stuff. Also heard from sources that the founder is quite an arrogant guy and not easy to work with. It's sad that investors hedge their bets on such wonky projects without understanding how this translates into a use case.

dhosek 6y ago

I was recently making a similar language decision about a project that I've foolishly started. Since I wanted my code to be easily portable and also (for my own use) wanted it to be able to run on iOS and MacOS, I ended up selecting C++ as the language [1]. I've got about 20 years of C++ evolution to catch up on and there are a lot of things that I haven't had to think about in those twenty years (I spent a couple days making sure I grokked universal references and why I would care), but as I've explored what libraries are available for my use case, I think it's the right choice. [1] https://www.finl.xyz/2020/10/21/choosing-a-programming-language/ https://www.finl.xyz/2020/10/21/choosing-a-programming-langu...

joseluisq 6y ago

> Initially, I expected to go to Rust. Rust has excellent tooling, great libraries, a delightful community, etc. But after spending about a month on it, I can't say I like writing Rust. Especially, I don't like writing async code in Rust. I like a nice high level language, and that's kinda what you need when you have a project as big as Dark to build. And Rust is not that. I'll publish "Why Dark didn't choose Rust" next. I'm interested in the next post of the author elaborating a bit more why Rust wasn't an option here. As I understood, the author has just discarded Rust because wants a "nice high level language" (aside async writing) which is something relative IMO.

UncleOxidant 6y ago

I'll preface this by saying I'm not even sure what darklang is - I didn't find a concise description of what it is and it's for, only some videos which I really don't have time to watch right now... But doesn't moving to F# pretty much mean that the users of darklang will be forced into the Windows ecosystem?

BjorksEgo 6y ago
F# is open source and cross platform now since .Net Core

davidgrenier 6y ago

If I may recommend, try to find and read a copy of John Reppy's Concurrent Programming in ML. The book is a little bit of an eye opener if only for that. Hopac is a library that offers an excellent delivery of this model of concurrent programming on .NET and has top notch F# primitives.

chrischen 6y ago

Curious how this compares to js_of_ocaml or Rescript that gives ocaml the JS ecosystem?

massung 6y ago

Having read the previous HN post on this (leaving Ocaml) and this one, I'm going to post a different perspective on this. As a programmer, I love reading blog posts about why someone made something, how they made it, and what tools they chose to use/create to facilitate their end-goals. Some of the frustrations the OP had with respect to Ocaml are some I - and many others - have experienced as well. Enumerating those constructively can potentially benefit the Ocaml community as well. However, as a possible target user... Reading blog posts like these are _scary_. It is very rare that I want to read a "hey, that service you use regularly? yeah, we decided to rebuild it from the ground up using entirely new tools 'just because'". Will I still be able to work? Should I postpone signing up/paying? What new bugs will appear? Which features I currently rely on will change or outright disappear/cease to work? What edge cases that are currently handled will be forgotten? The list goes on... There are often very legitimate answers to these questions, and sometimes taking a HUGE step back in order to meet demands you didn't know existed before is what's required. But those requirements, and how this step back will address them, should be clearly laid out to your users. More importantly, work such as this postpones any current roadmap features (potential) users may be waiting for and have been previously promised. Presumably an analysis has been done on how much they'd be postponed by, and why those features will benefit greatly once done. Sharing that would also be extremely helpful in assuaging concerns.

deleted 6y ago
[deleted]

askyc12345 6y ago

Guys, does it make sense to switch from C# to F#? I mean, C# adds more and more F# features each year and I think they will probably be on a par with F# in 3-4 years. By the way, native immutable records will be added to C# next week in C# 9.

akra 6y ago
IMO it depends especially if your coming from C# - sometimes yes, sometimes no for existing code bases. On the features you mention while some of those features are being added to C# (and not all of them are planned to) from what I've seen they often aren't as powerful/useful as the F# version, are not as consistent/concise due to legacy syntax or don't interact with other features as well. F# is also taking C# features so its not like you will be left behind either (e.g. Span). For me more importantly the underlying defaults are a feature that can't be ported which IMO F# wins here. C# is a fine OO language having worked with both extensively, just F# IMO is slightly better with less ceremony than typical C# code. Is it worth switching? It depends on your problem and where your starting from. In this case they are switching from OCAml so F# probably makes more sense. If your starting from a clean state it all depends tbh what you find easier to learn - IMO many JS/Python/Go/etc programmers if trying .NET Core might find F# easier than moving to C#/Java from their own personal preferences - its often called a "typed Python" by users. For C# users probably less so; but learning it might change your C# code style for the better.