tejasv

We do. Chaldal (YC S15), see https://chaldal.tech/

Not yet, it has been on my list for a long time. Meanwhile I recommend this blog that collates all good F# content from around the web weekly:

https://sergeytihon.com/category/f-weekly/

tejasv

6년 전discuss

Interop is janky. It works, but there are some gotchas that need to be worked around. It works in 95% of the cases without much mucking around, but it's not pretty, so you're better off tucking that away in some dark corner.

tejasv

6년 전discuss

Here's is a simplistic example of a state machine:

  let transition (state: State) (action: Action) : State option =
     match (state, action) with
     | (StateA, ActionA) -> Some StateB
     | (StateA, ActionB) -> Some StateC
     | (StateB, ActionA) -> Some StateB
     | _ -> None

If you get the quoted representation of the transition function, it can be visualized as a tree data structure (like code-as-data in LISP). You can analyze that tree to understand that if current state is StateB, only ActionA can be applied on it.

Couple this with another realization: "Any sufficiently complicated model class contains an ad hoc, informally specified, bug-ridden, slow implementation of half of a state machine." (not sure where I read this quote).

This means all the entity framework/ORM crap work that we do can actually be neatly represented as transforms on a F# state machine, which suddenly makes the application more powerful if you give it this structure.

We use this technique to auto-generate admin panels.

tejasv

6년 전discuss

Yes :) That moment when it simply clicks, it's not something that goes away. It has certainly made my day-to-day programming work a lot sweeter, hence I can't shut up talking about it. And it's not like I write some esoteric ML or data science code, a lot of these are boring line-of-business applications, yet it is so satisfying designing those in F#.

tejasv

6년 전discuss

If you're on a .NET stack, F# is a secret sauce; its just not many have bothered to look :) Maybe discuss with your CTO and make a collective decision to invest in it by understanding what it brings to the table, and don't worry too much about the future, like having to hire F# devs. As I described above, guiding existing devs to learn F# is the equivalent of training them to think better (as PG/Eric Raymond quote, it will "make you a better programmer for the rest of your days"). If a small handful of you within the company develop expertise, you can guide others. And what's more; if you do pick up F#, many skills are transferable to other FP jobs (like Scala). There's a leap-of-faith element involved, but it has been paying us dividends.

Also, I really like this post: https://fsharpforfunandprofit.com/posts/low-risk-ways-to-use...

tejasv

6년 전discuss

We're an F#-first company and I'd like to share our experience here.

All our new code is in F#, we started off from a C# codebase, so that made the transition somewhat manageable, as new F# code can be directly called from C#, and vice versa (still took over 2 years). All new frontend apps are also being written in F# (using Fable), as of 6 months back, migrating away from TypeScript, this forces everyone into a "design your model first, and well" paradigm. We've written quite a bit of code to blur the lines between traditional backend and frontend development roles, so what we have now are:

- product engineers (who write application logic on both frontend and backend to serve business needs)

- platform & framework engineers (who write the underlying persistence/serialization/versioning/frontend-backend-sync websocket/load balancing/IDE extensions/deployment etc)

- component designers who focus on visuals

Platform/framework engineers try to encapsulate as much magic as possible into computation expressions (F#'s monads), so product engineers can focus simply on writing out business intent, with readability given very high priority. We also make ample use of quotations to do some cool tricks (like predict the future states some type can take, based on current state + available transitions).

Our code written in F# has an order of magnitude fewer bugs when it makes it to production, given the amount of thought we pour in modelling the problem domain accurately, and thanks to functional programming itself. They're also more amenable to business requirements changing, simply because they've been modelled well to start with. Nothing that can't be achieved in other languages, but with F#, this happens more naturally.

Almost everyone in our team has learnt F# on the job, and overall, everyone's experience has been extremely positive. There's a bit of difficulty in the first 2-3 months, as junior devs get introduced to functional thinking, but if you've generally being doing functional programming, this is just about learning new syntax, tooling and F#'s choice of operator naming (map/bind/pick/collect/choose/..). Typically, based on prior experience, we ask newcomers to spend two weeks to a month, solving the first 100 problems on Project Euler in F#, without using the mutable keyword, and we assign a mentor to point out best practices and review their code.

The hiring pool for F# devs is much smaller than the regular applicant pool, but if a candidate shows genuine interest in F#, they are usually 10x more likely get through our interview process. If they've discovered F#, it means they find something lacking with mainstream languages, so they're likely to have many years of experience under their belt, and they've found a way to grow. That said, we don't restrict our hiring to simply F# devs.

For more info about us, see chaldal.tech (YC/S15).

tejasv

6년 전discuss

Agreed. You can't completely avoid it as we're running on a framework (and libraries) that's based on C#, but we architect our code such that these messy edges that interface with the outside world are implemented once, creating a nice walled garden for the rest of the F# code inside.

tejasv

6년 전discuss

As other replies to this comment describe, we make heavy use of opaque types where runtime enforcement of safety is need. Some examples: PositiveFloat, PositiveDecimal, NonEmptyMap, NonEmptySet, NonEmptyList, KeyedSet.

tejasv

6년 전discuss

We, at Chaldal (YC S15, chaldal.tech), use F# in production. Most of our backend projects are in F#, the last one is being migrated over slowly from C#. Our new frontend projects are also in F# (using Fable).

I want to share some insights of using F# with the community. We started from a C# codebase, and realized that a better language can help weed out most bugs in our system. And yes, it works. Pretty much all bugs we face these days are parts where the F# world touches something non-F#, like .NET and other libraries written for C#, where interaction (like nulls) is not well-defined. We've taken Scott Wlaschin's (fsharpforfunandprofit.com) teachings to heart, and we have a giant banner in our office that reads "Make illegal states unrepresentable".

It took a bit of learning for everyone to jump in, but our dev team has loved the experience as the language is a pleasure to use; when they need to go back to write C# or TypeScript code, a lot of these learnings transfer. People just become better programmers (as is true with learning any functional language).

To get all the benefits of F#, you must adopt the whole paradigm. While F# allows C#-like OOP, and while this can be an initial stepping stone in the path towards F#, you must go all the way. If you simply do OOP, the trade-offs aren't worth it, IMO, as F# is a functional-first language, and the OOP is mostly provided for interop with the rest of .NET.

IDE support has been janky in the past, but its improving. Latest VS 2019 is pretty good, and JetBrains Rider works pretty well on the Mac.

tejasv

6년 전discuss

Chaldal (https://chaldal.tech) YC S15 | Remote | Full-time

We build systems and infrastructure in the developing world. Our primary offering is a vertically-integrated 15-minute grocery delivery service, built in the world's most densely populated city, Dhaka, and looking to expand to other geographies. To support this system, we work on supply chains that connect farmers, wholesale markets, logistics networks and commodity exchanges. We work with the World Food Program in feeding the world's largest refugee camp. We're a profitable company and we're backed by the World Bank.

Our stack: - F# (C# for some legacy services that we're moving to F#) - Orleans - TypeScript - React, React Native - Service Fabric

We have fun building IDE plugins, DSLs and new ways of programming. If interested, email me at [email protected].

tejasv

8년 전discuss

Try F#

tejasv

9년 전discuss

lock them up and dont give them any food

tejasv

9년 전discuss

I've taken the approach of converting my models to XML, mostly because they map 1:1 from F#-land to XML-land, and I can use SQL Server's XML Indices, but most importantly, I can use XSLT to evolve my persisted models upon change change to F# code.

Then using a bit of F# Quotations, I can convert most match queries to XPath queries and query SQL Server directly (still work-in-progress).

But running into performance problems, so it's not 100% done.

http://stackoverflow.com/questions/41949177/f-data-types-sql...

tejasv

9년 전discuss

Chaldal (YC-S15) | Senior Engineers / Architects | SF, Singapore | Fulltime, Onsite preferred / Remote considered

Build out entire tech ecosystems in developing countries.

We're a US company, currently focused on Bangladesh, and we're building out the infrastructure for all digital commerce. We're already the biggest tech company in the country by far, supported by the government, with our own warehouses, logistics fleet and a 400-person ground-team, about to break through from urban to rural areas.

We believe in lean yet strong engineering.

Apply if you're extremely passionate about computer science, Haskell, F# or LISP, or if you can't find sleep because the world isn't as integrated as it can possibly be.

You'll be responsible for your own business unit, and you will be managing junior engineers. MUST NOT be afraid to get into the dirty details of the bits and MUST be able to visualize the entire system.

Email: founders [at] chaldal [dot] com

tejasv

10년 전discuss

We use Xamarin Forms a LOT for our internal and public facing apps. I started exploring it almost 2 years back, because native Android development just sucked, and C# has the async/await keywords, which is simply perfect for asynchronous operations in UI.

It has not been an easy road. After 2 years, I'm finally beginning to reap the benefits. The simple problem is this: this is another layer over the existing layers and it's very hard to get it right, especially if the underlying layers suck.

Just because you've learnt Xamarin Forms doesn't mean you can choose not to learn the underlying native platforms. You can skip over most of the details, but something will always come back to bite you, and then you have to go figure it out. Xamarin Forms works on top of Xamarin Android, that works on top of Android SDK and Android Tooling, which works on top of the JDK, which works on top of the OS you're developing on. So many places for something to go wrong, and usually presents itself in the form of a cryptic error at the top. Developing for iOS is considerably easier.

So there's still a fair amount of expertise to develop if you're completely new to mobile development. Take it for what it is -- an abstraction, and as with any abstraction, any concrete manifestation will have its issues, and you must be ready to roll up your sleeves to figure it out. And it does get keep getting better with every subsequent release.

But it does eventually help -- we have to get the complex bit right once, and then it simply works. Don't approach this like you would approach an Android app -- make sure you understand UI design best practices -- especially reactive design and data binding.

We also have .NET stack, so I'm finally in this beautiful world where all my logic is represented as C# Expression Trees on the server side, that gets serialized and pushed down to our Xamarin Forms Apps. Looking forward to WASM adoption, so I can finally get rid of that JavaScript mess.

So if you're writing a one-time app, and you just want to target Android/iOS, and you don't care how you've done it, no it doesn't make too much sense.

But if you're trying to make a long-term bet, in this awful fragmented device-oriented world, (and having to write the same app twice goes against the very nature of your existence), well that's my bet, I will be cautiously optimistic. If you're on .NET, it's a no-brainer -- there are simply too many other benefits to ignore, and philosophically very true.

The architecture itself (Forms, Xamarin.Android, Xamarin.iOS, Custom Renderers, Platform Effects, Bindings to access native libraries) is theoretically flawless (or very close to it), a work of art -- and I'm a sucker for theory, no matter the real world pain.

tejasv

10년 전discuss

If these alien beings are built using javascript (as pictured above in the matrix-esque image) then we definitely have nothing to fear.

This phrase should defeat them: "Hi, welcome to undefined"

tejasv

10년 전discuss

Once you guys made it big, you should rename yourselves to RethoughtDB :)

tejasv

11년 전discuss

Absolutely. That said, be prepared to take a lot of long-haul flights :)

YC is a value-add, no matter where you're based out of.

tejasv

11년 전discuss

Thank you!

Actually we believe this can work in all contexts. The immediate value add for the customer is lower prices, better quality, more convenience.

We have also seen a lot of inefficiencies in getting food from farm to consumption. One example is wastage - the more data we have on consumption, the better we can predict wastage, and the better we can redistribute food. So yes, we are hopeful that this will have a net positive impact on society.

Submissions

Ask HN: What is the performance and APK size overhead of React Native on Android?

An honest guide to the San Francisco startup life

Ask PG: How do you evaluate startups that are not US based?

comments