Dark’s new backend will be in F#
blog.darklang.com
blog.darklang.com
Sorry, but this is no Clojure. Instead of a proper comment syntax you define a dummy variable to a string? Ghetto.
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.
Had Kubernetes not existed they would be doing just fine economically as they would be the dominant platform.
They got beat by competition.
By the way, it's "per se"
Docker allowed reproducibility to be accomplished by a person who likes the idea of it, but will shelve it if it doesn't work within an evening. This describes me, for example. I think it took off for that reason.
They also benefited significantly from the splash they made and the tech excitement factor. I still run into people in my consulting work that are fairly new to containers, but brand recognition on Docker is through the roof. Everybody has heard of them even if they don't know what it can do for them.
Yep I agree. I recently helped a customer to move from Docker EE to OpenShift. They were frank about the pain points they experienced and why they were moving. It really came down to competition. K8s solves the problems they were having in a better way. Now with so much momentum behind K8s, nearly everybody is re-platforming their offerings on top of K8s.
That said, this item from the FAQ is nice to see; I'd love to see more vendors not just making promises along these lines, but making them binding:
> if the worst should happen, we will open-source Dark ... We're committed to codifying the specifics in a legal framework
Instead of lockin, you can run serverless in your own framework though, such as Kubeless or Knative, which could be deployed on prem or in a more generic cloud deployment.
I guess if you've got a large enough environment that you have dedicated devs pushing things to Kubeless/Knative instances maintained by dedicated ops/sysdmins, then maybe that's the niche there?
Is it solely about the developer experience? Or is it about the economic ownership of hardware? Or both?
OCaml is a fine language, but it's not a wildly popular one. Should the authors have started with, say, Python or JS, they won't have the problem with support from third parties. Please note how their choice was between open-source Rust and proprietary (CORRECTION: also open-source already) F#, both descendants of the ML family.
When you pick a language and start to feel you're overgrowing its ecosystem, you either migrate off of it (as in the post), or start developing it to help it move in the direction you want. In the case of OCaml, Jane Street and Facebook chose the latter route.
UPDATE: Thanks for reminding that F# has been open-sourced: https://github.com/dotnet/fsharp/
I don't really think this matters. Dark is intending to be "batteries included" and relieve developers of the need for a huge ecosystem with multiple libraries for everything.
> And yet they're asking their customers to make the same bet on their proprietary language and platform.
I always use very popular open-source stacks.
That said, if given the choice between a tiny FOSS language and a tiny proprietary one (that might be profitable), I'll always choose the latter.
Small languages are extremely vulnerable to extinction regardless of who maintains them. But if at least one person's full-time job is to maintain a language, I feel much more confident than if 1-5 people are maintaining it part-time.
If it's actually going to be 'batteries included' in any meaningful way, then it will have to piggy-back off of one or more of these 'huge ecosystems', which invariably leads to the ability to integrate external pieces of these systems when needed. Which just makes it a wrapper around existing 'huge ecosystems'.
There's a reason why established languages such as Java, C#, C++, JavaScript, etc. have multiple libraries for the same problem - these libraries have different features, tradeoffs, designs etc. Same reason why existing projects get forked and new projects get started. Same reason these 'huge ecosystems' have frameworks, design patterns, idioms, best practices, etc. Competition, innovation, new designs, new ways of solving existing problems is a good thing.
I don't see dark as anything more than a very new framework, with lofty promises and zero evidence towards the idea that it will be better than existing systems in any way.
> Small languages are extremely vulnerable to extinction regardless of who maintains them. But if at least one person's full-time job is to maintain a language, I feel much more confident than if 1-5 people are maintaining it part-time.
A tiny FOSS language at least has a chance of getting some maintenance/bug fixes from the community. What happens when your proprietary language dies for lack of traction? Also, nothing prevents a person working full-time on a FOSS language.
(Not to put words in parent poster's mouth, just for reader clarity)
F# is no more proprietary than Rust. F# was started by Microsoft Research but is now an open source language 'owned' by the F# Foundation and licensed under the MIT license (https://github.com/fsharp/fsharp).
(The historical Visual F# compiler was developed by Microsoft per http://research.microsoft.com/en-us/um/cambridge/projects/fs...) but AFAIK today Microsoft's small full-time F# devtools team work on contributions to the open-source compiler in addition to their work on VS tooling.
It's a fun language to work in, with some neat features, but C# is gobbling up every compelling advantage inexorably.
Also Microsoft alongside Facebook is looking for ex-Mozillans to join their Rust teams, then what?
What do you mean. The whole page talks about "I" and "me". That's going to go well...
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.
> 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
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/
Ayeeeee... this is like trying to carve Mount Rushmore using a spoon.
Happy CircleCI customer.
Dark definitely is ambitious and you're entitled to be skeptical. Personally, I'm really glad this isn't just a fancy IDE on top of a conventional stack. I think we should be doing everything we can to support loonshots and crazy new ideas like this because these are the kinds of things that could change the game for all of us.
I remember communicating with Ellen (the co-founder that has left the company) back in April (2 months before they let everyone go) when they asked for feedback. I said pretty much the gist of this blog post and received a one line answer of 'well, that's like, your opinion, maaan'.
I should feel vindicated, instead I feel sad. Dark got 3.5 million in funding - I'd be very curious to know where that money went (specifically how much the founder and co-founder have paid themselves) because it sure sounds like the founders got to 'try ocaml lol' with 3.5 million of someone else's money and then write blog posts about it that routinely show up on HackerNews, telling the rest of us of their 'lessons learned'.
Without knowing anything regarding the specific details, I would be pretty surprised if investors wouldn't be ready for both ups and downs.
Dark is basically a language that's designed to be serverless out of the box. They've baked their own engine into the language as well as dependencies for various cloud providers, databases (postgres was highlighted a lot), etc so that you can build serverless applications quickly while having no knowledge of operating systems, infrastructure, or really even computer science.
It reminds me of a number of the languages out there that are low-code or no-code. A regular programmer probably wouldn't even recognize some of the syntax and symbolization this language uses.
Here's some examples: https://blog.darklang.com/spin-up-a-slack-app-in-seconds-wit... Most of us have probably built a Slack app by now (or bot) so this is a good example to compare with IMO.
Dark has a mission of appealing to 1B people and they say the first step is to appeal to developers.
Internal versioning as they release new methods on their own libraries? So it doesn't break old ones?
When we add a new version of a function, all the calls to the old function are unchanged. The autocomplete shows new users the new version (and not the old version), while people who are calling the old version get shown both.
> Q: Deployless seems dangerous! Won't I constantly break my application?
> A: ... snip ... With Dark's feature flags, you have precise control over how and when a specific feature or set of features becomes live, and for which part of your user base.
Hope it works out!
> Welcome HN! If this is your first time hearing about Dark, check out the website[1], our What is Dark [2] post, and How Dark deploys in 50ms [3] to understand what we're about. Thanks for checking us out!
[1] https://darklang.com [2] https://blog.darklang.com/what-is-dark/ [3] https://blog.darklang.com/how-dark-deploys-code-in-50ms/
It caches recent requests to your site, and as you make changes it constantly re-runs those requests showing you the resulting live values in code. This is close to something like Excel where code changes are instantly and visually applied to the input data.
There's incredible promise here, and I believe similar fast-feedback paradigms will become the mainstream programming experience within 30-40 years. We've already had a taste of this with Jupyter Notebook's ubiquity across data science; despite its many flaws it lets people iterate just a little faster.
As for Dark itself, it feels they put too much emphasis on language and not enough on ecosystem. I wish they had focused on a fresh new IDE experience for Django or Rails rather than additionally building a entire language and syntax from scratch.
I feel exactly the same. It looks like you have to watch some videos that explain what it is and what it's for and I don't have time. If they can't describe it in a concise paragraph then I'm not sure why I would care. Why is this ending up on the front page of HN 2 days in a row - apparently it's only because they're dropping OCaml. Ok, fine you're dropping OCaml and moving to F# for your... whatever it is.
The appeal it had to me was watching one of the videos in which he talks about inherent versus accidental complexity.
I’d say eliminating all the extraneous accidental complexity you see in the entire process of building software is what it aims to do. That really resonated with me.
Deployment, code versioning, IDEs, infrastructure. So many of these things can be replaced by a simpler holistic toolset.
I’d say for simple use cases they’re well past the 80% mark. And it really is enjoyable building something in this paradigm.
The challenges are obviously the next 20% which will be where all the really hard edge case parts come.
I’m really looking forward to seeing it evolve.
It’s worth watching the introductory talk, even if you never intend to build something with it.
Accidental complexity is something I’m sure all engineers battle with. It’s nice seeing a genuine attempt to eliminate it. Even if it has ironically come along with some of its own accidental complexity. (E.g. not having enough libraries)
I’m hopeful that they’ll continue to battle all the right parts of accidental complexity and stay aware (as they are) of where they’re introducing it
How is the incremental typechecking experience, eg in vscode? (Speed, UX)
Does F# have a prettier implementation or other fast/deterministic/opinionated formatter?
JetBrains Rider also supports it.
Fantomas can be used as a formatter. https://github.com/fsprojects/fantomas
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.
Although there are some aspects to performance that are Rider-specific, it uses the same underlying compiler to deliver tooling. So some issues might be solvable at a more core layer.
Disclaimer: I work on F# at Microsoft
What seems to happen consistently: I can delete a label in a type record, no lag. As soon as I finish adding a label (haven't added its type yet), all matter of slow hell breaks loose and there is a 5 second delay before anything shows up. This happens regardless of whether or not the type is used in a low (<20) or high (>100) number of places. The delay is the same in all records.
The issue you're describing sounds more like a compiler/core tooling issue than a Rider issue though. Would you mind filing an issue here? https://github.com/dotnet/fsharp
We collaborate with the Rider folks quite a lot and so they'll see this if it is indeed a Rider issue.
Pretty good.
> Does F# have a prettier implementation or other fast/deterministic/opinionated formatter?
It has something but I was not working on MacOS so we are not using it.
There's a large community of very helpful people willing to answer questions.
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.
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
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.
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.
Especially given how easy it is to deal with it. Option.ofObj what we use most of the time.
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.
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.
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.
The language itself is incredible, and just keeps getting better and better with every release.
It'd be neat to see people turning to .NET when writing those kinds of systems, but maybe it's just not cool enough in the Bay Area.
This is in contrast to the JVM where Java is showing its age, but mountains of work poured into the JVM keep it performant: OpenJ9 and Hotspot, Project Loom, Zero GC, as well as big non-Oracle investment such as Shenandoah GC contributed by Redhat, etc.
I think .NET can be quite an advantage, as stated also in the article.
but if I want to, say, set up a dev environment on linux, it comes with a set of quite different dependencies than what other languages use.
I mean, F# is a very reasonable choice if you want the .Net ecosystem and will most definitely solve the SDK issue but the whole thing certainly didn't convince me to try Dark.
I just thought your comment was top-level. It's unobvious on mobile.
Kind of amusing, given the whole article is about how great it is that it's embedded in the .NET ecosystem
But I also feel like the language is mainly used in a type of business environments that are already tied to .NET infrastructure anyway, and who actually appreciate the interlock.
And it could get much more traction outside of that circle, especially in the open source world.
I think that's still somewhat true just because there is momentum carried over from the past, but it's definitely something I see changing in the industry.
.NET used to mean SQL Server and Azure in addition. These days I'm seeing .NET Core with AWS and Postgres.
and now with .net core, its a better cross platform framework.
also, you can target wasm or native image now, no need to install it on the target env.
Got any examples of this?
I mostly only miss modules/functors, and being able to use them for abstract data types.
After working full time with F# for nearly two years I can attest to this. At worst there's inconvenient things, and as you get deeper into FP you'll wish F# had certain features, but all in all it's an very sane and well designed language. I think the only thing that's caused me any pain is the lack of type classes, and after doing a lot of MVU I wish lenses were a language level feature.
> "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.
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.
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.
You either have to run into the same problem as dark when it comes to libraries and ecosystem (ocaml, haskell, D, etc), use go and give up any nice language features, or run on a VM and deal with all the issues of packaging/weight (clr, jvm).
There are certain things that just work (i.e. quarkus, which I have a web service running on 13 mb of ram), but I have never been able to successfully compile to native on my own because of library dependencies. Getting things like Weld or H2 to work is pretty difficult.
AOT compilation has been a feature of most commercial JDKs, specially the ones targeted at embedded development like PTC and Aicas.
Unfortunately, those are not the features that you care about most in a compiler. In a compiler, your priorities are ease of extension, ease of specification, and ease of transformation. The last thing you want in a compiler language is to worry about ownership when trying to implement expression-rewriting optimizations. Conversely, OCaml is excellent at these things.
> One of my biggest annoyances was how often OCaml folks talk about Fancy Type System problems, instead of how to actually build products and applications. In other communities for similar languages (ReasonML, Elm, F#), people talk about building apps and solving their problems. In OCaml, it feels like people spend an awful lot of time discussing Functors.
In whatever case, it appears that the author's preference was F# > Rust > OCaml.
I don't have a problem with garbage collectors in general, but that's only one facet in deciding a language. There are lots of more important facets, and OCaml fares pretty poorly at these (e.g., tooling, ecosystem, community, pace of improvement, mindshare, etc).
And for language toolchains in particular, I wouldn't lock myself into a language with suboptimal performance--it's too hard to back out of that decision later, and it's easy enough to recoup some of that pace of development from Rust by just refcounting everything today if necessary (optimize it later).
I think this is unfair and OCaml has a lot going for itself. The fact that it also has an active academic community of people who care about Fancy Type Systems does not strike me as an intrinsic downside.
To me, OCaml has a very different paradigm from most languages, and that can be a big strength. Implementing something in OCaml after you've written out the types can feel like you are doing a duet with the compiler.
No one is arguing that this is a downside. The downside is that there aren’t many people who care about making useful software, or at least there is a relative dearth of content devoted to that end.
> To me, OCaml has a very different paradigm from most languages, and that can be a big strength. Implementing something in OCaml after you've written out the types can feel like you are doing a duet with the compiler.
I actually agree with this, but as much as I love a good type system, it’s gravy. I can ship software with Go because it has a decent runtime, tooling, ecosystem, learning curve, mindshare, etc even despite its simplistic type system; however, it’s much harder to do the same in OCaml. Also, there are languages like Rust with great type systems and concern about the more ruggedly practical concerns of software development.
Once set up, though, I agree that it drives very much forward. In compiler writing in particular, it allows you to express the things you care about (ASTs and transformations over them) with next to no effort.
As for batteries included, there are several options for foundational libraries; I found there to be too many choices rather than too few when I first started developing in OCaml.
As for foundational libraries, I agree that there were too many choices, but IMO fragmentation in the standard library is a bad thing (you need to know how to interop between them as you integrate third party libraries that use different standard libraries). Never mind the confusion that creates for newbies.
Moreover, for newbies, getting editor integration working well, understanding the unfamiliar (to put it nicely) syntax, and a myriad of other challenges without good documentation are other significant obstacles.
These are pretty significant downsides, and as much as I like the upside of a nice type system, I don't need it to build a product, but I need good tooling and a good ecosystem and a healthy supply of developers. I can ship a product with Go or Python (languages with impoverished type systems)--there might be more bugs but finding and fixing bugs is manageable--but OCaml presents significant challenges.
In the same sense that the president of the US is only one voice on US policy. If you've been writing OCaml and then you want to change your project to another language, you will most definitely miss the garbage collector. All of a sudden you have to solve problems a second time in a different way, which is something you wouldn't have to do using F#. There's no way I'd shift a serious project from GC to non-GC unless I had absolutely no choice.
I mean, if you want to use OCaml and not even bother to want to learn about functors, which are fundamental to the module system, then I don't know what to say. It would be somewhat like wanting to use Java and not learn how to use classes.
That said, the OCaml community is very interested in using the type system to eliminate entire classes of errors (eg,"make illegal states unrepresentable"). Rust community is the same. Jane Street has built a multi-billion dollar company using this approach. If you view such as "abstract language design", then your loss.
Yes, the Rust community is interested in the academic aspects of eliminating classes of errors, but it's also very interested in addressing pragmatic problems. Consider all of the sites for Are We (Web | GameDev | IDE | etc) Yet as well as the remarkable progress they've made in such a short time. Rust's entire history fits in the amount of time that OCaml has been struggling to solve parallelism.
> Jane Street has built a multi-billion dollar company using this approach. If you view such as "abstract language design", then your loss.
That's really great for Jane Street, but it's really not the badge of honor you (and the rest of the OCaml community) think it is that a single company has managed to muster some success with your preferred language in its 25 year history. It also doesn't do much to illustrate that the OCaml community is broadly interested in practical matters--only that one community has done, and they have done a lot of work to make OCaml manageable (like Google has done with Go, except that Go enjoys marketshare outside of Google).
Of course, not all projects have this as a high order concern, but some do, and it can make sense to use Rust for those.
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'
[0]: https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/g...
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#.
Agree. Mark Seeman calls these the "Functional pits of success"
https://www.youtube.com/watch?v=US8QG9I1XW0
I think the toughest thing about F# is that it doesn't offer as many Google-able easy solutions, so I'm stuck using it for utility and client libs at work. Trying to get a whole team onboard is a non-starter. It takes a good 6-12 months to adjust the mindset and most people are just looking to come into work, find their tough questions on StackOverflow and head out for the day.
For example, I may use a List at first, as it's natural to start with and offers niceties with [H|T] pattern matching or List.filter() somewhere, then if I decide to use a .Net List (ResizeArray) or Array or Set instead, I'm screwed. The pattern matching needs to either change syntax or go away, and all the List.Foo() calls need to change to Array.Foo's or whatever -- or I have to use Seq.Foo() everywhere to get extensibility even I don't want to pay for lazy evaluation. Long time F# fan here! -- but still some sore points.
Most of our platform infrastructure code is imperative, but as you get higher up in the abstraction hierarchy, you will start to see more things declared as functional or data-driven. We would really like for everything above our service/platform layer to be functional, but there are some areas where it is a better engineering choice to go imperative (at least for now).
I have always thought of imperative vs functional as a very mutual thing. The imperative code is the glue between your fictional/business reality (functional world) and the real world (CPU/OS/Networks/etc). Functional code can serve as a perfect model of the business if the imperative code (platform) supporting it is well-engineered.
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).
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.
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.
.net core got better, faster and almost parity with the upcoming release.
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...
If your concern about Microsoft abandoning F# is genuine then perhaps that can re-assure you.
I did love this one article http://tomasp.net/blog/2018/write-your-own-excel/
EDIT: Submitted the link here https://news.ycombinator.com/item?id=24980325
* 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/ Website of the author of the book mentioned above. He also has some good Youtube videos on the topic.
* 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.
Can read about how CircleCI's continued use of Clojure in 2017: https://circleci.com/blog/tips-for-optimizing-docker-builds/ And again in 2019: https://circleci.com/blog/update-how-circleci-processes-over...
At this point though I believe the F# community is active and resourceful enough to carry themselves even if Microsoft directed resources away from the language. One of the things I noticed early on about the F# community is they tend to be mindful about their investments, and like to mold existing, established work into something more ergonomic for the F# community. The Giraffe, Fable, and Bolero projects are all wonderful examples of this mentality.
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.
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..
1. https://compositionalit.github.io/farmer/
2. https://twitter.com/Cody_S_Johnson/status/132322777503415500...
3. https://github.com/UnoSD/Pulumi.FSharp.Extensions
4. https://github.com/SaturnFramework/Saturn/blob/73855f08d9c50...
https://www.techempower.com/benchmarks/#section=data-r19&hw=...
It's also one of the more full-featured web frameworks benchmarked.
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).
[0]: https://docs.microsoft.com/en-us/dotnet/framework/app-domain...
Although the cross-platform .NET Core runtime does get pre-installed with a number of default Microsoft packages in its local NuGet package cache.
Java has several implementations between open source and commercial vendors.
Likewise .NET has several ones.
So depending on the benchmarks and the set of chosen runtimes you can tick the boxes either way, depending on what one wants to prove.
Hence why I rather work with both.
[1] https://www.finl.xyz/2020/10/21/choosing-a-programming-langu...
Hopac is a library that offers an excellent delivery of this model of concurrent programming on .NET and has top notch F# primitives.
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.
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?
Turns out this is an easy one, yes.
I’m leaning towards f# or Scala. I love static typing.
Since it’s a data science, machine learning company Scala makes more sense.
Scala 3/Dotty sounds like it will be a big improvement.
Everything is in python but I’m building out the main user-facing app to interface with all the models.
How many engineers/employees are you guys now after the restructure?
It's sad that investors hedge their bets on such wonky projects without understanding how this translates into a use case.
tldr: Help build it but don’t use it.
AFAIK their eventual target market is the “οἱ πολλοί”.
No need to be so negative, you are just not their target market.
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.
The base concept is cool, I was more caught off guard by having to learn a new language here
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.
I mentioned Python as Dark appears to be heavily influenced by it. Python is meant to be dirty and fast to code in.
To be honest, I've never used a functional programing language. What Unity does is essentially allow you to call various apis , with C#, in the game engine, which is C++ base.
But it's real C# and I can hop over to my day job and utilize it. Dark isn't a portable skill set.
I really feel like you're focusing on the wrong thing.
To me, the pitch is that Dark is FaaS-native (meaning you don't have to bend over backwards or use complex tooling to get a good write/debug/deploy experience).
The language itself being new and proprietary is actually a drawback. They can make it very friendly and productive, of course, but the other features are what should really sell someone on using Dark.