Hacker News

For reference, F# slack is already dead, community has moved to Discord https://discord.com/invite/fsharp-196693847965696000

Curious since you don't expand on it on the blog: in what way did Haskell's purity make it difficult to you?

Having used Haskell in production for a bit now, I don't even notice its purity. Most functions are in some kind of I/O context making it similar as other languages, except with the option of running without I/O capabilities for functions that shouldn't need it.

There was a large group of folks that left Ruby on Rails for Elixir (even has a similar looking syntax), yet it wasn't on your list of languages to consider. Just curious, was there a particular reason?

Apache Spark, Delta Lake are written Scala. Being JVM based, it has a large ecosystem. Scala seems like a better choice than F#.

Great story! Thanks for sharing it!

I understand your perspective. I like to view niche languages as a medium for learning. For instance, I enjoy using Rust in my personal projects—even if many of these projects may never be released—because the lessons on immutability, functional programming constructs, and trait-oriented programming significantly enhance my day-to-day work. Therefore, I believe that learning niche languages, even in the absence of a robust job market, is worthwhile.

>" I was quite surprised by how many project files and boilerplate was generated by .NET, which put me off.

With which language are you comparing with?

Because there's afaik csproj and maybe .sln

and both of them are let's be frank - foundational for almost all projects that arent just hello world.

Otherwise you end up with some cmakes or something similar that want to achieve something similar

I hear you on the opportunity side and I can't see that changing. The good news is in recent releases there's a lot less boilerplate - "dotnet new console -lang F#" results in two files, a short fsproj file and a single line of Hello World.

F# is quite usable with AI. All AI models are perfectly capable of generating idiomatic F# code. In fact, because it has a nice type system, if you ask the AI to model the problem well with types before implementing, hallucinated bugs are also easier caught.

I find F# easy to use with AI, mainly because it's statically typed (which results in compiler errors when the LLM generates non-working code) and it's very expressive, which allow me to more easily comprehend what the LLM is trying to do.

It is possible to start your project with the script possibilities offered by F# (as mentioned in the blog post). It is absolutely a viable approach and I even blogged about it a couple of months ago: https://www.asfaload.com/blog/fsharp-fsx-starting-point/

> But then where are the jobs and which companies care if you write good code?

Oh man, that is poignant :( They always say they do in the job description, but it always a different story once you get there.

I learn them as a fun hobby, with no salary expectations. It keeps the dream alive, and I learn a lot from the Common Lisp community that I do use in my job.

Opportunities do exist, even when they’re few and far between. I learned Rust in my spare time because I was really interested in it. Then we stumbled across something that would have really benefitted from a cross platform library and lo and behold, I got to use my Rust knowledge, even though the vast majority of my day job doesn’t use it.

I like F#'s syntax when all you're doing is pure logic. But when you have to interface with any IO like a database or REST call or something, you have to abandon the elegance of ML syntax and use these ugly computation blocks. In C# you can do something like this:

    var post = await _postService.getById(id);

    let getPostById id = async {
        let! post = blogPostService.getPostById id
        return post
    }

    let post = getPostById 42 |> Async.RunSynchronously

1. Do all logic in ML-syntax, then pass data into a computation block and handle I/O operations as the last part of your function, then return unit OR

2. Return a C#-style Task<> and handle all I/O in C#

Either way, ML-style languages don't seem like they're designed for the kind of commercial CRUD-style applications that 90% of us find ourselves paid to do.

As sibling comment pointed out, it's just .fsproj manifest and Program.fs file. What boilerplate do you speak of? It's on the opposite end boilerplate-wise to projects made in e.g. Java or TypeScript.

For F#, projects are needed to make full applications or libraries. Otherwise, you can simply write F# scripts with .fsx and execute them via 'dotnet fsi {SomeScript.fsx}'.

(obviously you can also specify dotnet fsi as shebang and integrate these scripts into general scripting on Unix systems - it's very productive)

Watching c# eat f# features as someone who has dabbled in f# lightly for over a decade has been wild. And supposedly DU's are in the works but multiple years out.

Though one thing I doubt c# ever gets that I love when I'm writing f# is pipeline operators. I love the way they read, from object/collection being worked on and then a list of operations being run on it in order from left to right (or you can do right to left if you need to for some particular reason).

It’s always puzzled me that so many languages have their own build systems and package managers. Why aren’t programming language-agnostic build systems like Bazel and Buck more popular? It seems so strange that every new programming language essentially has to reinvent the wheel multiple times, inventing a new build system, package manager, formatter, linter, etc. I wonder if we’ll ever see something like LLVM for these technologies.

While I've never used it in anger, I really quite like dune. Was there something specific that makes you characterise it as "ridiculously bad"?

I use C++ with Meson and Conan and I can say that there is an initial learning curve if you need to adapt Conan recipes but once you get past, the results are quite good.

My two cents is that F# hasn't received the same care and attention as C# and working with it can be awkward.

At the same time, a lot of the cool features (list comprehension, pattern matching, immutable records) have slowly trickled into c#, giving even less incentive to switch

    > I'm completely convinced that F# (along with Scala, Haskell, and OCaml) adoption has stalled due to having ridiculously bad build systems.

    > Hell, 80% of the reason I choose Rust over C++ for embedded work is because of the build system.

I would call .NET build system excellent.

Hiring devs is perfectly fine if you don't look for F# skills - just hire generally smart people, and allow them 1-2 weeks to get comfortable with F#. Make them just solve problems from project euler or something.

For those who have already done functional programming, they wont take more than 2 days to start getting productive. For those who have written a lot of code, it will take them ~2 weeks to pick up functional thinking.

Anyone who is still uncomfortable with F# after 1 month - well that's a strong signal that the dev isn't a fast learner.

Additionally, I've never had anyone reject our job offer because we do F#. I'm sure a whole bunch of people might only be looking for python or javascript jobs, but that's fine because I'm not looking for them. I always have more people who I want to hire but I can't due to budget constraints.

Source: direct experience - I run a pure F# company with a team size of ~80.

As a proficient Elm developer with industry experience, I’m wondering what are the biggest challenges in hiring devs? Is it the paradigm, learning the ecosystem, lack of interest? Are you currently hiring?

How does the typing system work for F#?

From the article, it looks like it's mostly dynamically typed. Or is it inferred? Or is it something else?

Like, if I write

    let hello value =
      print value
    
    hello "world"
    hello 2

To me, that'd be a point that might steer me away from the language. Deducible types seem vital to larger and long lived projects.

Thanks for your work on falco, it’s a really great library.

>- there are very few opportunities to use it professionally

- hiring devs can be challenging

Those drawbacks are huge, IMO.

F# supports both functional and OO call styles. That's why you have both `|> List.map` and `.Select`. It can be a bit confusing at first, but the interoperability with C# is worth it.

Array lookup in modern F# is just `foo[0]`.

Subtyping is much less common in F# than in C#, so the need for covariance/contravariance is correspondingly lower. Personally, I've never needed it.

F# support in Visual Studio is now excellent. You can also develop F# in VS Code.

FWIW I think writing F# is a really cohesive experience in day-to-day work. While there are usually at least two ways to do things, due to .NET interoperability requirements, it’s usually pretty clear which way is the “right” way to do something.

F# feels kind of similar to Python in this regard, where there might be more than one way to do it, but there is community and ecosystem consensus on what is the right way.

I think a lot of credit should go to Don Syme for this; he seems to have a very clear vision of what F# should and should not be, and the combination of features ends up being very tasteful and well composed.

I think these days F# is probably a big more polished than what you remember, so perhaps it's worth giving it another shot.

Being a hosted language always requires certain compromises (something that was also apparent in Scala). I used to do Scala professionally in its early days, but for me it felt it added just as much complexity as it addressed. I focused on Clojure back then (on the FP side at least), and I do think that F# probably brings more to the table than Scala. (if one is not constrained to Java, that is)

The tooling story is not great, but I've almost never seen great tooling for a language that's not super popular. I'm guessing what you get today with Rider is more or less as good as what VS has to offer.

Interesting - I'm curious where your thoughts are now on using FP/Scala in 2025?

I've always looked at F# with envy as it is a hosted ML that will have extremely battle tested bindings to the important day to day stuff via C# (Darklang's stories of struggling with postgres and AWS when using OCaml was a good cautionary tale on the risks of using less common langs as a startup)

Never had a chance to try out Scala but am a seasoned Clojurian, as an outsider it seemed Scala suffered a little from being not opinionated enough so the ML family has been more appealing to tinker with even though Scala supports type classes out the box and will also have great ecosystem support via the JVM

The funny thing is that you can write very similar code in C#, so maybe you don't need to switch which language you're using as a CLR frontend.

    using System.Linq;
    using System;

    var names = new string[] {"Peter", "Julia", "Xi" };
    names.Select(name => $"Hello, {name}").ToList().ForEach(greeting =>   Console.WriteLine($"{greeting}! Enjoy your C#"));

F# shines on the back end, where its functional-first style is very adept at crunching data. Think about data flows in your system: Any place where you use LINQ in C# today to select/filter/transform data might be even better in F#. Parsing is also a great F# use case (e.g. parser combinators), although a fairly narrow niche.

Personally I think F# is excellent for writing ye olde CRUD applications, especially as the business logic becomes more complex. F# is really good at domain modeling, as creating types comes with minimal overhead. C# has improved a lot in this area (eg record types) but it’s still got a long way to go.

I wrote a tutorial about how to get up and running with web dev in F# that might be of interest: https://functionalsoftware.se/posts/building-a-rest-api-in-g...

"As far as I can tell F# is one of those things where every single user is extremely happy" Isn't it because language has rather small community of passionate people, who are devoted to their language of choice?

F# popularity is somewhere between CHILL, Clipper and Raku langs, that are probably as obscure as F# for typical software dev.

The navbar takes up half my screen on an iPhone 13 mini :/

> It was the same thing with Clojure and Scala for the JVM. I have zero interest in first learning C# or Java, just to use those platforms.

FWIW, I managed to learn Clojure without knowing anything from Java/JVM before diving into it. I did have plenty of JS experience which made ClojureScript easier to pick up I suppose, but Java works more or less the same as every other Algol-like and/or OOP language out there so if you have any previous experience with something like that, basic Java is trivial to pick up even accidentally.

you are not supposed to do oop in f#

Wow, that sounds awesome. I'm jealous.

It exists in several similar languages such as elixir, and was even a proposal for ecmascript, but never really got traction.

The flagship editor is Rider

But it's Windows-only, so it's not an option for me.

I assume you're talking about Scott Wlaschin's "Railway Oriented Programming": https://fsharpforfunandprofit.com/rop/

Curried functions combined with that magnificent pipe operator, overlaid on the .NET runtime. Don Syme et al knocked it out of the park.

It's the one programming language that changed how I think about programming.

I'm only talking about the version before type providers. Then it got messy.

Before that, we could (and I did) recompile fsi.exe to do some custom prompt manipulation. It was a slog, but it worked, but then Microsoft faded from my life. Still, that early version (I believe 2.0) F# is just magnificent.

It might be great, but IME, MSFT docs and tooling are subpar, and anything dotnet related is/was a disaster.

along with what jcmontx said: F# is structured bottom from top. As in you can't reference something that is later defined earlier. I find that naturally leads to getting a decent enough structure "for free" because it forces you to have your basic functionality early on and build on that later.

That also, IMO, makes untangling/splitting up parts of the codebase easier as well.

The secret is currying. Replace your DI for currying and you'll start to see somewhat similar patterns

Have you tried using a book or a tutorial to see how things can be done using idiomatic F#?

That makes sense when one is used to the Visual Studio organization of solutions and projects, with some main method somewhere being the entry point, unless it's a WCF service or somesuch that gets run via a service manager.

I only used F# at its command line, fsi.exe, to give me commandline access to .NET for exploration, testing, and munging data. Over time, I built up quite a library of usable functions that I'd have the fsi.exe program pre-load when I kicked it off, leaving me at the prompt with all .NET namespaces and my code ready and accessible.

Once you get access to your database's data, it's easy to write queries against it and then play with the data. I could then port the F# processing bits that worked into my C# projects as necessary, but it was far easier to do it that way than to write the logic deep within complex multi-project solution files, where the various classes are spread throughout the projects' files.

I also just really enjoyed using F#.

You can use adapters via Foreign Function Interface and interact with C++ code. The deal breaker is that memory is separated, C++ code has its own heap and Ocaml too. Quiet different to F# in which operating with C# is seamless and the runtime is the same.

I’ll add that features isn’t really a constructive way to think about the differences between C# and F#. C# has more ‘features’ than most other programming languages. One of the core features of F# is less features and churn. Also, I really appreciate the way F# maintainers agonize over how to maintain the language and keep it coherent. You don’t get the feel they’re chasing features at all.

As a 20+ year C# dev...where do I learn how to structure apps in F#? In C# my ASP.NET Controller might use a service (or a mediator) to execute some domain logic and that in turn will use a repository pattern (or EF DbContext) to update/query a database. How are dependencies injected in? It seems like there are multiple ways of going about it, but I don't have enough knowledge of F# to know 'the proper way' to do it.

> For Elixir, you need some basic Erlang knowledge

As an Elixir programmer, this does not resonate. Basically the only thing I've ever felt I needed to understand Erlang for was ets, but let's be honest, that's not really proper Erlang but just the terrible ets query syntax. And all this requires is "ability to read enough erlang term syntax to be able to understand the ets manual". I don't think I could write a single line of correct Erlang by heart.

I feel like that's different in F#, where you still need to know lots of .NET internals which are all documented in C#y terms with C# examples etc. Elixir wraps pretty much all good Erlang/OTP internals in nice Elixiry modules, which solves that quite nicely.

Elixir has its warts but this really isn't one of them.

> For F# , you need some basic C# knowledge For Clojure, you need some basic Java knowledge For Elixir, you need some basic Erlang

Honestly, none of this really rings a bell. Having used all three options, I never felt that. Well, I already knew C# before getting into F#, but honestly, it felt like my C# knowledge at the time was more of a distraction. Been using Clojure for nine years, never done any serious Java and have not felt any need for it. Not knowing Erlang wasn't a problem with Elixir, like at all.

I've written a lot of Clojure now, and I've managed to avoided learning any Java really.

Erlang is not a difficult language. Unusual, but actually quite sane syntax. If you are already familiar with Elixir it would probably be pretty easy to learn the basics of Erlang.

I worked with Elixir for over five years without knowing anything about Erlang. I know Erlang now, but only because I was interested in learning it, not because I needed to do so to write Elixir code.

There's no need to be functional 100% of the time, and it's not pedantry.

You mark your functions and non-functions as such, so the compiler can get your back.

`async` is F#'s original implementation of async programming. It is the precursor to C#'s await/async.

`task` targets the .NET TPL instead, which is also what C#'s await/async and all of .NET *Async methods use.

While the `async` implementation still offers some benefits over `task` (cold vs. hot starts [0]), my advice is - if you're doing backend code on .NET, you should use task. The tigher integration with the .NET ecosystem & runtime results in better exception stack traces, easier debugging and faster performance.

[0] https://github.com/TheAngryByrd/IcedTasks?tab=readme-ov-file...

If you use task { } CE's you will get really good UX (it is recommended to use them over async CE's). They were introduced in F# 6.0 to address outstanding interoperability issues. As of now, writing asynchronous code is more convenient than C# (which is more convenient than Go or other languages which are less expressive w.r.t. writing highly concurrent code).

Yes mixing is just like with VB.NET.

When mixing, you often write business logic as self-contained F# libraries with a C#-friendly API; and use C# to integrate them with whatever imperative, reflection-heavy and DI-heavy frameworks .NET is promoting the current year, since those are filled with interop edge cases for F# anyway.

You really want to avoid a language sandwich though (e.g. C#/F#/C#), because you'll keep wishing to remove the middle layer. Sadly, the addition of source generators make this mistake even more appealing.

You have likely heard "functional core, imperative shell". This refers to having IO-heavy code that favors imperative patterns be written in C# and then have the actual domain logic core written in F# which is much better at expressing it. Because both languages are hosted on .NET, you simply achieve it by having two projects and having one reference another. It is very seamless F# and C# types are visible to each other if marked to be so.

The biggest advantage of F# is its gradual typing and full type inference which allows to massively reduce the amount of text required to describe application or domain logic. It is also extremely composable and I find doing async in F# somewhat nicer than in C# too. F# also has better nullability (or, rather, lack of thereof) assurances and, in my opinion, better UX for records.

Not sure that C# is the more capable language - its still that F# is mostly a superset of C# although C# is catching up. I think they are on par w.r.t capability (i.e. CLR compatible). In terms of conciseness, and expression F# still wins IMO; and given some of the extra features can be more performant at times (e.g code templating/inlining vs just JIT attributes). Custom CE's (Async/TaskSeq), nested recursive seq's great for algorithm dev, DU's, etc. There's a lot of little features C# doesn't have (or don't quite fit) that when I write C# I'm forced to implement still more cruft code around.

IMO its generally more readable as well to non-dev than C# and to dev's outside the Java/C# ecosystem (e.g. Node, Go, etc). I've shown F# code back in the day to non-tech stakeholders and they typically understand it (e.g. data modelling).

Unions remain the killer F# feature missing from C#.

Also, basic object initialization in C# has turned into a nightmare with recent versions. You need a flowchart to select among the 18 syntax options which suite your current needs.

With F# (and other newer languages), record fields are either `T` or `T option`. No need to worry about whether the value needs to be computed in a constructor and then remain immutable, whether it needs to be initialized by an object initializer and/or a constructor or not, whether it needs to remain interior-ly mutable throughout the life of the record, and so on. (Although as I recall you do still need to consider null values assigned to non-nullable references in your F# code that consumes C#.)

F# can be nicer to use for a functional programming style.

It's not always about the features such as keywords, built-in functionality and types. It's also how language features work together.

C# is more fit for an imperative or OOP style when F# is more fit for a functional style.

You may start to get a point when C# gets a two-directional type inference system. As it's now, any functional-looking code requires so much boiler plate that it's shorter and less bug-prone to copy your functions code everywhere you want to use them.

I've worked with .net professionally for almost 20 years. At the beginning with C# while last decade almost exclusively with F#.

F# is just a better language. Simpler, more concise, more readable with stronger type safety. I will never go back to writing C# as I'm finding it too frustrating at times and unproductive.

Everything is an expression (i.e. its an actual functional programming language), and along with it comes a different way of thinking about problems. Coupled with a really good type system which has discriminated unions, you'll have much fewer bugs.

Pro tip: don't write F# like you would write C# - then you might as well write C#. Take the time to learn the functional primitives.

A nicer, cleaner and simpler syntax, superior pattern matching, active patterns, discriminated unions and computation expressions

Can it do GUIs well?

I don't know if I would say 'well'. For simple GUIs it's OK but, for non-trivial GUIs I would use the approach to write the GUI frontend code in C# and have it call the F# 'backend'. If for no other reason than that the support and documentation for doing GUIs in C# is much better.

How about mobile?

Never tried, but I'm guessing more or less the same story as above. I would probably start by looking into .Net MAUI for that.

And how does it compare to e.g. Scala?

The biggest difference is that Scala is a much bigger and more of a multi-paradigm language. F# feels smaller and more focused and on its ML roots and functional programming. Not saying that Scala is less 'functional' than F#, but Scala supports you writing your code in a much more OOP way if you want. Yes you can (and sometimes have to) do OOP in F#, but it doesn't feel natural.

For web UI we have Fable and it's integration with well-known js frameworks, also WebSharper (although it's less well-known) and Bolero (on top of Blazor)

For mobile we have FuncUI (on top of Avalonia) and Fabulous (on top of Avalonia, Xamarin and Maui). Most of these frameworks use Elm architecture, but some do not. For example I use Oxpecker.Solid which has reactive architecture.

Can't help with Scala comparison, but at least DeepSeek V3 prefers F# for UI https://whatisbetter.ai/result/F%23-vs-Scala-9eaede00c7e4485...

Because it's a CLR language, it has access to all the same technologies as C#. That is, all the Microsoft native ones plus cross-platform with Avalonia.

https://fsharp.org/use/desktop-apps/

.NET for iOS and Android is very robust, I’ve been developing with it since 2018. Just avoid using MAUI for interfaces because it's still quite unfinished after the rewrite from Xamarin.Forms.

It can do GUIs well, although it takes some finesse to manage user state in an immutable-first language. Check out Fable for building web apps: https://fable.io/

I don't have much experience with Scala, but I think the two languages are pretty comparable in their respective ecosystems. The biggest difference I'm aware of is that Scala has typeclasses and F# does not.

Sprinkle some HTMX next to your favorite template engine and you're g2g

> people who write blog posts ... never a mainstream language

Don't you find it amusing that food critics usually write about little-known or new restaurants and never do any fast-food chain reviewing?

Successful language designers select for what's popular, not what's good.

C++ intersected the mass of C programmers with the new OO fad, and kept all of C's warts. Had Stroustrup made C++ better, he wouldn't have an army of adopters who already knew C. Maybe merit will win out in the long run [1]? I'm not hopeful.

Java needed to be close enough to C++, and C# to Java. And Brendan Eich joined Netscape to "put Scheme in the browser".

[1] https://www.theregister.com/2025/03/02/c_creator_calls_for_a...

My favorite language is Python, but I wouldn't write a blog post about it because no one would care.

New mainstream languages are rarer than new better (in some way that can be favorable) languages.

The build system is exactly the same as C#, MSBuild with its .NET SDK, and syntax and community are entirely subjective; F# has the least weirdo community I've personally seen for an FP language. Weak arguments to say the least.

I'll give you the chicken-and-egg hiring problem and it being second-class to the .NET team, though; I'd add poor IDE support by modern standards, only Rider feels right. I love F# but I've moved on for these reasons.

Elixir is dynamically typed, which presumably many people are put off by.

The shop went all in on Java and F#? Why not C# and F#? That’s really odd, unless there’s context I’m missing.

> Elixir

For me, it's Erlang. I just really like its horn clause syntax, it's so clean and readable. I know a common complaint is lack of piping (and even though you can implement it trivially, the order of arguments for some functions makes it of dubious use) but it's a small price to pay.

> I mean the language is really nice but the C# baggage and runtime was just a bit much

This was my experience with F#. Frankly, I've never been happy with my experience with CLI on Linux, and the toolchain inherits a lot of baggage from its C# heritage. Microsoft's toolchains have a very distinct workflow to them. F# has some interesting aspects to it like active patterns (something I wish was more common in the ML-family), but tbh I'm more than happy with ocaml.

If one need to get on Beam, is it better to start on Elixir or Gleam?

It's pretty baseless to claim that modern dotnet is inherently shitty. They've made tremendous strides in the dotnet core era.

F# making you unemployable is debateable, but I don't see what makes F# any less employable than most other FP languages. They have some niche applications that make it useful rarely, but when they're useful its a terrific tool for the job. F#'s ability to interop with the rest of the dotnet ecosystem positions it better than most functional languages for business usecases.

I'm sure Microsoft has developed a lot of bad tech, but by and large their languages have been great. msvc c++ compiler as a possible exception, but f# in particular is excellent.

I've spent my entire career, 22 years, primarily in C#.

I'm quite employable.

> felt too much .NET-y and too much MicroSoft-y

That was kind of my main problem with dotnet stack in general, although that was some years ago. I've tried sneaking F# into our project by building set of tests (the main codebase was in C#), but some of my teammates would have none of that.

My personal perception of the dotnet community was that developers either were too pigheaded about doing things "the Microsoft way", or hyped about "innovation" — "Oooh... check this out, Scott Hanselman made a whole new conference talk about it...", and then you'd look into this "innovation", and it often turns out to be some decades old, well-known thing, only "wrapped into MSFT packaging", which is not really bad by itself - it just seemed that people didn't actually use them in a practical way. I just never found that sweet-spot between pragmatism and excitement. You have to find a middle ground between: "This works! Sure, yeah, but isn't it darn ugly and probably not scalable?" and "This is so beautiful, and cool, but nobody besides Jeff really understands it." And my personal experience was that .net programmers would always want to be on one of those sides.

This rings true to me as well. I'm not sure what I get out of F# that I can't get from Rust, unless you specifically want .NET, which I don't.

I'm .NET dev and haven't touch a windows device since 2019. Work on Mac, deploy to Linux.

I am also a C# dev and haven't worked on a Windows machine in 5 years.

C# and F# both work fine with Rider or VS Code on Mac or Linux.

> i can't bring myself to deal with Microsoft Windows and their tech

Even in a VM? Why not?

This isn't such a big issue in my experience. Auto-formatting helps a lot, the code needs to be just syntactically correct.

The default F# autoformatter is bundled/supported by VS Code, VS and Rider [0].

[0]: https://fsprojects.github.io/fantomas/docs/end-users/StyleGu...

F# has both "lightweight" (indentation-based) and "verbose" syntax. If you don't like significant whitespace, you can just use the latter.

https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

You never touch python code either?

I was with it until I heard no braces :/

Static typing removes the downside of whitespace.

Oh, and every language with line comments (so most of them) has significant whitespace.