>startups should consider niche language with extremely limited hiring pool.
sure, but only if you're doing something that actually demands it - and actual innovation - instead of usual 'lets repackage XYZ as SaaS and growthhack' strategy.
F# is less popular, but it’s a first class .Net language with full MS support and integration onto .Net (VM and ecosystem). C# has been tracking F# and aiming for language parity for years (ie all your modern C# devs should be learning the same language facilities). F# is multi-paradigm so C# devs can write idiomatic C# with minor forced changes. And as a .Net language you can always decompile it into C# and keep going from there.
That’s a radically different proposition than, say, raw OCaml and not particularly niche. It also impacts hiring pools differently since competent functional C# devs are viable, but it tends to appeal to a certain calibre of dev.
Moving faster with fewer errors and more talented candidate pool are relevant to repackaged SaaS startups too. Leaves more time for the other stuff and scales better.
don't get me wrong - i want F# features in C#! I like the ecosystem and both languages.
I'm just pointing out that no matter how cool the language is if it doesn't serve business needs(hiring, onboarding ,ease of replacing staff, target market) it won't be picked.
I've worked with a lot of junior devs/graduates on a large F# project, in that context hiring/onboarding for F# hasn't at all been a limiting factor. Ultimately F# is not a particularly difficult language to learn.
Last I knew, Rider was pretty much the only IDE available for a large codebase when you weren't on Windows. Much love for Ionide, but it was a serious struggle.
VS Code with Ionide is okay but has many limitations for example in debugging or lack of support for F# fsi scripts.
If you’re serious about F#, investing in Rider or Visual Studio makes a lot of sense.
Having said that I wrote a Neo4J data extraction tool a few months ago and chose to write it in F#. At one point I observed how funny it was that I was developing in a Microsoft language and yet my dev workstation runs Fedora and my IDE comes from JetBrains and my code is running in kubernetes on a Linux cluster and there is not a sight of a windows machine in this whole pipeline.
I remember the days when the language, linker, compiler, IDE, the GUI components, everything was tied together. If you wanted the next version of VB you had to buy the new version of Visual Studio!
It's good for, and I am not being sarcastic or snarky, justifying high pay and gate-keeping. Developers should set up more barriers for entry - look at doctors and lawyers.
I think I agree with you. When I was part of a growing F# team a number of years ago, everyone we hired was an enthusiast who just loved coding in F# and wanted an opportunity to do it professionally. It turned out that this love, combined with the constraints of the language, led to a super-clean and legible code base. The quality was (in my estimation) outstanding, and I was sad to leave it.
I'm at my current company (actually writing mostly typescript and node services now) because of a YC "who's hiring" post that mentioned F# positions (bait and switch /s, but my experience lined up heavily with the team I ended up joining which didn't use F#).
Seeing that any startup is more likely than not to fail, why would I work for a company that is using a niche technology that isn’t going to be in demand when I look for my n+1 job?
How important is being a language expert in x vs all your other skills as a Software Engineer? My opinion is that "higher level" skills (like system design/architecture, product thinking/planning etc.) are so much more important than language minutia (outside of specialized fields).
If a business is turning away candidates because they "don't have n years of experience in x" that doesn't sound like a very dynamic/interesting place to work, it sounds like a code monkey job. AI is going to eat code monkey jobs.
Before you can demonstrate your skills on the job - you have to get the job.
Most of the 2.6 million+ developers in the US don’t have “interesting jobs” nor do they care if their jobs are “interesting”. They work to exchange labor for money to support their addiction to food and shelter.
If you look at the requirements for most jobs they want you to have $x number of years of technology $y. When every job application gets 100s of resumes, employees can be picky.
Besides, every technology has its foot guns, ecosystems, way of doing things and people who think they can just pattern match based on what they know are often the most dangerous.
One example is that I’ve seen people who know relational databases, optimization techniques and normalization try to pattern match their understanding of OLTP databases when using OLAP databases like Redshift and Snowflake and it being a complete disaster.
See also people who don’t understand how to do a single table design with DynamoDB.
In my particular niche (cloud + app dev + customer facing consulting) , I knows AWS inside and out and have used more AWS services than you can imagine in the past 7 years in a production capacity [1] and I’m currently a staff level developer at a consulting company (full time), the only company that would (has) looked seriously at me to do consulting outside of working with AWS is ironically enough - Google.
But they have the bandwidth to let me ramp up. When I have one open req, why would I hire someone who needs to ramp up on AWS when I have a dozen applicants with experience? Why would I put myself at a disadvantage?
A company would be absolutely insane to choose me over someone with experience with Azure, or GCP as a staff consultant over the probably dozens of applicants they have with that particular skill if they were an Azure or GCP shop.
When my current company hired me, they were short staffed and gave me a week to onboard and flew me out to a customer site to do support a large sales contract. They hired me because I could hit the ground running both technically and without “consulting training” like AWS had.
[1] seven years of experience between 2 working at a startup, 3 working directly at AWS (Professional Services) and two working as staff consultant at a third party company.
Similar for us in magnitude of sized company, maybe a bit bigger. Lots of services are F# (internal and main services), but we don't advertise it that much nor want to. Every time we consider switching (even to C#) the developers want to switch back even though C# is a fine language. Its not perfect, but its enjoyable to code in all the same. At this point the stack is battle tested.
For final export? AVIF, JpegXL, maybe even WebP (lossless mode).
PNG kinda sucks for high resolution stuff because decoding is extremely slow. The way PNG does lossless compression also only really works with flat graphic design, anything with gradients or texture blows up the file size.
Definitely not lossless AVIF. It is less efficient than lossless WebP. WebP is supported everywhere, but is not much more efficient than optimized lossless PNG. Lossless JPEG XL has the best lossless compression but can't be used for web without fallbacks.
Definitely not lossless AVIF. It is less efficient than lossless WebP. WebP is supported everywhere, but is not much more efficient than optimized lossless PNG. Lossless JpegXL has the best lossless compression but can't be used for web without fallbacks.
> Why two cloud providers? Initially we used only DigitalOcean, but a data intensive SaaS like tap needs a lot of cloud resources and AWS have a generous $1,000 credit package for self-funded startups.
So some Kubernetes experts migrated to AWS for $1k in credits. This is madness. That's weeks of migration work to save the equivalent of a day of contracting.
> Of course you can inspect it: open the source code you wrote and read it. Also, don't write the code you don't want to be executed?
This is not what they meant by inspection.
What they mean is that you can write a function, in Haskell, that given a value in the DSL, it returns the list of all requests it will perform on execution.
This can be useful for tests, security, caching, performance, debugging...
This seems like a cool article, but it isn't readable without Haskell background knowledge.
> For an intuition why this is true, consider that the constant functor Const r has an Applicative instance whenever r is a monoid, because pure stores a mempty value and (<*>) combines the held values with (<>). For a fun exercise, implement runAp_ in terms of runAp and Const.
Pipes are great where you want to chain several operations together. Piping is very common in statically typed functional langauges, where there are lots of different types in play.
Sequences are a common example.
So this:
xs.map(x => x * 2).filter(x => x > 4).sorted().take(5)
In pipes this might look like:
xs |> map(x => x * 2) |> filter(x => x > 4) |> sorted() |> take(5)
In functional languages (of the ML variety), convention is to put each operation on its own line:
xs
|> map(x => x * 2)
|> filter(x => x > 4)
|> sorted()
|> take(5)
Note this makes for really nice diffs with the standard Git diff tool!
But why is this better?
Well, suppose the operation you want is not implemented as a method on `xs`. For a long time JavaScript did not offer `flatMap` on arrays.
You'll need to add it somehow, such as on the prototype (nasty) or by wrapping `xs` in another type (overhead, verbose).
With the pipe operator, each operation is just a plain-ol function.
This:
xs |> f
Is syntactic sugar for:
f(xs)
This allows us to "extend" `xs` in a manner that can be compiled with zero run-time overhead.
if the language or std lib already allows for chaining then pipes aren't as attractive. They're a much nicer alternative when the other answer is nested function calls.
e.g.
So this:
take(sorted(filter(map(xs, x => x \* 2), x => x > 4)), 5)
To your example:
xs |> map(x => x \* 2) |> filter(x => x > 4) |> sorted() |> take(5)
is a marked improvement to me. Much easier to read the order of operations and which args belong to which call.
First of all, with the actual proposal, wouldnt it actually be like this? with the %.
xs
|> map(%, x => x * 2)
|> filter(%, x => x > 4)
|> sorted(%)
|> take(%, 5);
Anything that can currently just chain functions seems like a terrible example because this is perfectly fine:
xs.map(x => x * 2)
.filter(x => x > 4)
.sorted()
.take(5)
Not just fine but much better. No new operators required and less verbose. Just strictly better. This ignores the fact that sorted and take are not actually array methods, but there are equivalent.
But besides that, I think the better steelman would use methods that dont already exist on the prototype. You can still make it work by adding it to the prototype but... meh. Not that I even liket he proposal in that case.
Functional Programming hasn't even been tried for game development, really. There is a lack of overlap between the game dev industry and academia. The studios are (rightly) risk averse and try to use the same broad strategies to build games - OOP, maybe ECS for large swarms, etc.
Personally, I think that FP could be a great fit, but we first need to come up with architectures that solve real game development problems. We have to do this with small scale experiments first (game jams are perfect for this) and then scale up only if they succeed.
This project is exactly that - kudos to the author.
Game programmers are mostly extremely skilled and well aware of functional languages, how they work and what they do.
They aren't using them because they aren't a good choice for delivering games that need to run fast and consistently in real time.
Immutable data structures and garbage collection might be nice for people writing something, but that isn't what someone buying software wants, they want smooth and fast.
It's a force multiplier when you have a small team of strong developers.