Live data from Hacker News

Viewing profile — throw868788

throw868788

HN member
Joined
Sat, Jul 10, 2021, 7:00 AM UTC
HN karma
69
Public activity
63 items

About throw868788

No profile information was provided.

Recent public activity

  1. comment
    Comment #41197696

    Indeed. The company I work for uses F# for large revenue workloads across many services; mostly coming from non .NET dev's. It handles large scale customer traffic quite well witho…

  2. comment
    Comment #39964886

    Its funny because I've found the opposite; the fact that the smaller community (and lets face it - most FP langs have a much smaller community than needed to get the scale you are …

  3. comment
    Comment #39964789

    I do think this depends on region, as I've seen F# and Scala jobs typically outnumber Clojure for example depending on whether it is a .NET or Java shop. Mileage does vary. However…

  4. comment
    Comment #36146041

    Would be interesting to see actual stats in F# usage which I doubt are relatively available. Given the reaction to this post from what is an old article there's still probably an u…

  5. comment
    Comment #36135058

    Seems like a common theme that people prefer the F# language, but try to explain reasons why it hasn't succeeded from a technical view. I think the reasons IMO aren't technical but…

  6. comment
    Comment #35177688

    There are differences between implicit/pre-emptive and co-operative multitasking though and there is probably tradeoffs for each. For Java however, much of the existing API exposes…

  7. comment
    Comment #33041686

    I see that in places I've worked. I've always resisted growing my team's headcount as I've seen it break efficiency first hand. However I'm well aware it makes our team less notice…

  8. comment
    Comment #32492405

    I've used F# in a professional job and its fine - on very large scale apps for large corps. There's features in it that I feel make certain apps much easier to write that have no e…

  9. comment
    Comment #32244115

    I think this is a problem with many languages - e.g. Scala, Kotlin, etc. The easier justification really is: Does it fit your problem space? Will you save dev time overall, is it m…

  10. comment
    Comment #32231876

    Just use a mixed solution then i.e. why not both? You're picking one thing that F# isn't great at - generated code tooling which IMO isn't in the spirit of many modern languages an…

  11. comment
    Comment #32231670

    My view: F#, or to be honest a cross-platform IDE like VS Code isn't probably appropriate for many of these apps or rather the dev workflow that Microsoft promote in those framewor…

  12. comment
    Comment #32231467

    These are nice but: - Templates are no substitute for intuitive and minimal code for a number of reasons. (e.g. how to extend, how to customize, confidence that it isn't brittle if…

  13. comment
    Comment #32221177

    I think that's the barrier with C# in general - the framework nature of it means there's a lot of "I don't know what I don't know" especially with ASP.NET which is quite large in s…

  14. comment
    Comment #32220781

    Honestly I've found F# pretty OK to use compared to some other languages, especially when not using Visual Studio on a non-Windows machine where F# IMO is the better choice. Given …

  15. comment
    Comment #31732455

    He's linked it here: https://devblogs.microsoft.com/oldnewthing/20190913-00/?p=10... . Its a good read. The LE format, especially with UUID 7 like UUID (seq UUID's), seems to be ea…

  16. comment
    Comment #31501041

    This is what I think .NET's generics are like. Type information including all parameters are available, and JIT does as you say. The approach has some advantages (binary size, less…

  17. comment
    Comment #31118374

    > "hey, system, go through this btree, pull these items, merge with items from this other btree, etc” What I've always wanted in Postgres in one quote expect to also allow other in…

  18. comment
    Comment #30849894

    I guess what I don't understand by this proposal is how the exchange rate is actually maintained. Will they print a lot more cash to keep the exchange rate depreciating as thus? Th…

  19. comment
    Comment #30827413

    Realising this is what made money a lot easier to understand for me, and simplified the difference between different kinds of money. In the end its easier just to think of them as …

  20. comment
    Comment #30319948

    I've defined it myself (when doing C# with functional heavy code but it feels clunky) but there's still edge cases where it isn't as nice especially with functions of multiple args…

  21. comment
    Comment #30295750

    I do think the pipe operator is very tied into the first-class currying support and HM type inference in F#. In C# I think it makes a lot less sense. To be honest I think each lang…

  22. comment
    Comment #29621978

    Integrating the two apps hosted on different platforms is also quite difficult normally. Things you take for granted that need to be shared, reachable, etc between apps all now nee…

  23. comment
    Comment #29585685

    Sadly in my experience it is common for F# given its finance background at least historically, particularly in London/Europe. There is a culture of not showing your cards in these …

  24. comment
    Comment #29585640

    Different data structures have different tradeoffs that are used for different contexts. Usually arrays are faster than a linked list however I've seen arrays been used pretty badl…

  25. comment
    Comment #29574836

    Many of the points here don't necessarily have to do with the language, well at least to me and could easily have occured in other languages such as coding style. Sure - the langua…