6 ms·
The Untouched Goldmine of F#
- rmanolis 2y agoF# secret superpower that no one has discovered for 30 years, and it will change its popularity in enterprise software.
- cies 2y agoI like TST. We use it in our code (FP'ish Kotlin). But I also like stack traces, as they show me call-stack to the point the error happened. Something TST does not always show: different call-stacks can result in the same (or very similar) TST-stack.
- trgn 2y agoit's secret superpower it to allow you to give up on trying your code to compile and then just to shim against some C# bindings
- neonsunset 2y agoC# bindings?? F# and C# build on top of the same type system and can transparently access each other's types.
- trgn 2y agomaybe I misunderstand, but iirc i had to compile C# first into a separate dll.
- Dansvidania 2y agoI must say this take seems a bit... grandiose... to me. People have been banging on with type systems and similarly "better" capabilities for at least 2 decades [0] and Enterprise continues with a stark preference for language "practicality" and low barrier of entry. IMO it's because it's best to keep engineers superficially interchangeable rather than having a highly stable system (perhaps stable over spec) and a costly workforce with lots of negotiation leverage. But I digress. [0] https://en.wikipedia.org/wiki/Worse_is_better https://en.wikipedia.org/wiki/Worse_is_better
- jcmontx 2y agoI really like F#, but I really miss having a full fledged f#-native ORM
- cies 2y agoNo you dont. Sorry for the blunt answer. ORMs are a bad idea, even when using OO langs: they make the simple queries slightly simpler (`Users.getById(id: Long)`), they do not help you for hard queries (ORM-using codebases of size usually have hard-SQL-queries "in strings"). Most users of FP langs know this and hence will not even try to implement ORMs. Look into jOOQ, LINQ-method-syntax (or whatever it is called, without the funny SQLish syntactic sugar), SQLDelight or sqlx for non-ORM options that improve embedding SQL in general purpose langs.
- rafaelmn 2y agoI like the idea of F# type providers but last time I tried (two years ago) they were pretty shit compared to any mainstream ORM/alternative - has that improved ? Also ORM for simple row selects is a straw-man - their use case is deserializing, updating relationship graphs where they hide away a bunch of code. Should that code be hidden is a different question - but pretending it's there to save you from typing SELECT * FROM foo is kind of disingenuous. Editing graph data structures in most FP languages is just not compatible with OOP approach hence no ORM.
- jcmontx 2y agoMost of the time we do simple CRUD operations, I want this plumbing to be as straight forward as possible. Don't be patronising...
- Dansvidania 2y agoI am always confused by this wish. If the operations are simple, why the need for ORM?
- cies 2y ago
- talles 2y ago> It may not have the information on the filename or the line of code like the ordinary stack traces, but these are useless information anyway. These are useless information?
- cies 2y ago> only Odin, F#, OCaml and Zig have [Tagged Unions or Discriminated Unions] The good old missing sum type story. Don't Rust, Haskell, Elm, Kotlin (with sealed classes), etc also have them?
- squeegee_scream 2y agoI got to this part of the article and concluded it wasn’t worth my time, nor probably anyone else’s 1. Absurd claim that file names aren’t important in a stack trace 2. Claims they’re sharing a feature of F# that is never used, then later reveals they’ve been studying F# for 3 months 3. Then this statement about tagged unions
- Dansvidania 2y agobit of a weird article to find on the top of HN, to be sure.. But I felt similarly when I picked up Haskell coming from Ruby and Java, so I can understand the attitude. :D
- do_not_redeem 2y ago3 months, and he's already deep in acronym soup touting DDD, CDD, TDD, and TST. I'm getting major architecture astronaut vibes.
- johnnyjeans 2y agoMost languages have them, or allow them to be expressed. The name "Tagged Unions" literally comes from C.
- AnimalMuppet 2y agoDid it? Didn't Pascal have tagged unions?
- johnnyjeans 2y agoI looked it up and apparently it actually comes from Algol, but I digress. Point being sum types and their equivalents are found all over the place. I wouldn't be surprised to find out modern prologs have them.
- troelsSteegin 2y agoThis is really about making stack traces easier to understand.
- cies 2y agoI dont think so, TST and stacktraces are different. Stacktraces show me call-stack to the point the error happened. Something TST does not always show: different call-stacks can result in the same (or very similar) TST-stacks. It is possible to return the stacktrace as part of the TST error (not just an error message but also a stacktrace).
- boxed 2y ago> It may not have the information on the filename or the line of code like the ordinary stack traces, but these are useless information anyway. That is the weirdest and most crazy thing I've read in years.
- cies 2y agoYeah, that's also my main problem with the article. Otherwise great to prmote TSTs. I think the TSTs should also contain the stacktrace. Not or X or Y, but both X and Y.
- arwhatever 2y agoNo doubt it’s harder to write structured code and assertions against a string stacktrace, but as a human reading it, the information is immensely valuable.
- twic 2y agoThe whole post feels like it came from a parallel universe. People adopted microservices because stack traces are too long! Exposing the implementation details of a function in its type signature is good! The most meaningful way to specify a function is by how it can fail (this one is fun, though)!
- antigeox 2y agoIn soviet F# the monads... uh....
- johnnyjeans 2y agothe endofunctors operate on the category of you!
- moi2388 2y agoI’ve been told by HR I’m not allowed to show people my endofunctor anymore..
- 2y ago
- jamalaramala 2y ago> The question is: Why companies moved from monolithic to microservices? What do they try to avoid? One of the main reasons why companies move from monoliths to microservices is to promote ownership and accountability in large codebases. In a monolith where everyone owns the code, developers can break each other's code. With microservices, each team becomes responsible for one part, and (as long as they keep their SLAs) they can't break each other's code. When something fails it's easier to identify who needs to fix what. Microservices don't make much sense for small teams if they don't need or don't have the headcount to split responsibilities.
- breckenedge 2y agoSounds like extra bureaucracy.
- jamalaramala 2y agoIt definitely is; but this bureaucracy can be useful when the company has thousands of developers.
- SideburnsOfDoom 2y agoYes and no. Would you rather ask for deployment of a microservice owned by a team of 10 people, or a monolith that has changes from a department of 100 people. Which deployment do you think has "extra bureaucracy"? Which one do you think can be done this week? There are co-ordination costs to microservices. But there are also independence benefits.
- fluoridation 2y agoSame-process modularization should solve that problem. Splitting the architecture into separate processes means a crash in one module doesn't propagate to other modules, but the whole system still breaks down if the process is essential.
- jamalaramala 2y agoNot all bugs are crashes. It could be a copy text or price calculation.
- deleted 2y ago[deleted]
- Nelkins 2y agoI upvoted this because I love F#, but I can't say I agree with the conclusions of the author.
- agentultra 2y agoIs TST essentially the validation monad[0]? Glad to see more folks finding and appreciating FP languages like F#. It's good stuff. Scott Wlachin has a great site to discover more F# goodness[1]. [0]: https://hackage.haskell.org/package/monad-validate-1.3.0.0/docs/Control-Monad-Validate.html https://hackage.haskell.org/package/monad-validate-1.3.0.0/d... [1]: https://fsharpforfunandprofit.com/ https://fsharpforfunandprofit.com/
- WorldMaker 2y agoIt seems a step on the path to learning both the Either Monad and the Validation Monad, especially for someone coming from golang which desperately needs a proper Either Monad and essentially has baked in the worst of both imperative and FP worlds in the way everything returns as if there were an Either Monad but not enough useful combinators nor a semblance of do-notation/Computation Expressions exist. Which is fun to see, really, because it is interesting watching someone rediscover FP principles from first practice.
- jitl 2y agoSo… if I ever decide I want to change the call stack of a lower level function… I’m going to break types that all my callers and callers’ callers and callers’ callers’ callers’ are depending on? Like, my call stack is enshrined in a type so that to change it means a refactor all the way up to main()?
- scotty79 2y agoUltimate job security. Write the code that no one will ever dare to touch. And you pass on your job security to those few brave souls who do.
- kkukshtel 2y agoC# has a much awaited and active proposal to add DUs to C# so I suspect C# will also support this once live (and continue its legacy of plucking great features from F#). https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md https://github.com/dotnet/csharplang/blob/main/proposals/Typ...
- garganzol 2y agoAnother reason why companies moved to microservices is because it is easier to manage smaller projects. Services have stronger boundaries, they can be swapped with newer and alternative implementations, it is possible to combine the power of different technologies. I came from the other side: I own a huge monolithic web behemoth which is almost unbearable to maintain now. It was built using a now outdated technology, but: it serves customers, it runs the business, it brings profits. Nevertheless, it is a huge pain to even try to change something in it. The project is at its dead end now, it is a one-trick pony who has become too old. Nowadays I build newer parts using separate well-defined services. It is not textbook microservices, I would call it just services. Imagine building a mini-product that is not publicly available and only used internally. This kind of productized services work well enough to never look back at the fragile monolithic approach.
- seamossfet 2y agoGod I remember having to deal with F# when I was an intern, what a nightmare. It's like the worst parts of Java and C# smashed into one esoteric language.