Earlier quoted context omitted.
I have some good news for you about C#.
I love C#, its a great language
Perfect for blub programmers!
Why F#?
201–210 of 424 posts
Re: Why F#?
#202Earlier quoted context omitted.
Elixir getting a strong type system is interesting, but watch out for gleam though But they still miss the computation expressions, which open interesting possibilities like https://github.com/CaptnCodr/Fli and https://github.com/fsprojects/FsHttp
Gleam lacks lisp-style macros, and its implementations of BEAM and OTP are not exhaustive. For example, Gleam does not support: - Hot updates. - Full distributed system support. – Low-level process manipulation. - Named processes. - Advanced supervision strategies. - Behaviours other than GenServer. - Type-safe distributed messaging. - And several other things that I value in BEAM and OTP. I can't justify trading the…
I knew otp was still suboptimal in gleam, but thanks for mentioning all these additional points!
Funny how preferences and priorities vary among devs, I need my static type system! :-) But note even in static type systems there are variations. I'm talking about an hindley milner type system with its type inference like the one in fsharp
Re: Why F#?
#203People will do anything except actually try Elixir. :D ...I mean: pipes, immutability, transparent mega-parallelism... helloooo? I tried F# some years ago (after I was fired from a shop that decided they will go all-in on Java and F# and dropping everything else overnight) and I was not impressed. I mean the language is really nice but the C# baggage and runtime was just a bit much. And I was not left convinced that…
Elixir is dynamically typed, which presumably many people are put off by.
Yes, I agree that it's a big drawback.
Elixir made me more productive and gave me back my love for programming, and I work with it professionally for 9 years now. But the lack of static typing is getting so irritating that I started upping my efforts to get [even] better at Rust lately.
So I agree. It's one of the very top drawbacks of Elixir.
Re: Why F#?
#204>whitespace is significant, like in Python hard pass
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...
That's an interesting idea and implementation.
I don't think being whitespace-significant is a "hard pass" dealbreaker, but as someone who's not a fan of it, I'd say this only goes a small way towards alleviating that - like most "choose your preferred syntax" designs. Even if you're a lone-wolf developer, you're gonna end up reading a lot of example code and other material that's in the ugly whitespace-sensitive style, given that:
> The verbose syntax is not as commonly used ... The default syntax is the lightweight syntax.
And most people in practice are not lone-wolf devs, and so the existence of this syntax helps them even less.
Re: Why F#?
#205Earlier quoted context omitted.
I should have mentioned in the message, but I was looking for a strongly typed language. I was an avid-user of dynamically-typed languages, but that particular Ruby on Rails app became unmaintainable, and part of the culprit was due to the dynamic typing. I hoped that using a statically typed language would make it easier to maintain a complex app in the long term. And I must say that it totally materialised, to the…
This is a really minor point, but "strongly typed" and "statically typed" are not interchangeable terms. In the context of your comments here, you are exclusively interested in the static nature of the type system, rather than anything about the "strength" of it (which is something totally different and inconsistently defined).
You are absolutely right. Thanks for pointing it out.
Re: Why F#?
#206Earlier quoted context omitted.
I should have mentioned in the message, but I was looking for a strongly typed language. I was an avid-user of dynamically-typed languages, but that particular Ruby on Rails app became unmaintainable, and part of the culprit was due to the dynamic typing. I hoped that using a statically typed language would make it easier to maintain a complex app in the long term. And I must say that it totally materialised, to the…
These days there's Gleam[0], as a strongly typed alternative for the BEAM virtual machine. Of all the languages I haven't used yet, it seems to hit the safe + minimalistic + productive sweet spot the best. (Yes the C-inspired syntax is slightly off-putting, but syntax is the least important aspect of a language.) [0]: https://gleam.run/
Gleam, much like any language which primarily targets BEAM, is slower by an order of magnitude or two when compared to F#.
Re: Why F#?
#207Earlier quoted context omitted.
I'm sure it can be the better choice, but for me it was not. It seems there was some incompatibility between me and Scala. I find it such a complex language and I never managed to wrap my head around it. As I said F# was my last choice at the start of my evaluation, and Scala was high on the list due to the Java ecosystem. But in the end it didn't work out for me. F# on the JVM would be great though!
Is F# easier to learn than Scala? (I know a bit of Scala (in the old 2.x days) but have no knowledge of F#.)
At least the tooling should be way nicer. It is way more of an OCaml language than Scala. Also much like having to deal with JVM ecosystem in Scala, you'd need to deal with .NET ecosystem in F#. In my opinion, the latter can be an advantage. F# has a lot of depth but you do not need to grasp it fully to be productive with it.
Re: Why F#?
#208I did try F#, but I was new to .NET ecosystem. For 1 "hello world" I was quite surprised by how many project files and boilerplate was generated by .NET, which put me off. I am all for FP, immutable, and modern languages. But then where are the jobs and which companies care if you write good code? Now everyone wants languages which are easy to use with AI, while reducing workforce and "increased productivity". I have…
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.
Same with Nim. It works surprisingly well with AI tools. I think both have more straightforward syntax so it’s easy to generate. I’m curious how more complex languages do like C++ / Rust.
Last time I tried C++ with Copilot it was terrible.
Re: Why F#?
#209Earlier quoted context omitted.
I've spent my entire career, 22 years, primarily in C#. I'm quite employable.
> Because you love using Microsoft's shitty technologies If we go by the joke in gp, this is you.
I don't have any problem with the idea that Microsoft's technologies are "shitty" after all the response of my work laptop to its mandatory Windows 11 upgrade was a non-copyable diagnostic message with an opaque code in it which, as I understand it, is basically the equivalent of "Huh, oops, maybe try again?" and my colleague spent a week trying to uh, share data from a "Sharepoint" table.
But .NET's CLR doesn't seem especially shitty. It's not awesome, I don't feel that RIIR urge when I work with C# and I probably wouldn't with F# either but it's fine, it's like Java again, or maybe Go or Python. It's fine. I don't hate it and that's enough.
Re: Why F#?
#210Earlier quoted context omitted.
`var post = await _postService.getById(id);` the F# equivalent is `let! post = _postService.getById id`
You're missing the task {} block
This assumes the context is already a task computation expression, which is what you'd have in asynchronous code.