181–190 of 230 posts
Earlier quoted context omitted.
Starting with F# on Mac is worlds away from what it was in the past, I bet you could be up and running in 5 minutes: brew install dotnet-sdk dotnet new console -lang F# (in your project directory) Start VS Code in that directory, install ionide via extensions, write code… dotnet run
Exactly. And you can even pick between 3 IDEs - JetBrains Rider (best IMHO) - Visual Studio for Mac - VS Code with Ionide
Earlier quoted context omitted.
> F# is such a great language. I very much feel this, I found it productive, but it feels like a complete ghost town. I'm considering swapping to Go over using .NET for tooling/scripting.
Really? Were you active in the slack/discord channels?
Earlier quoted context omitted.
We use F# in prod. Could not be happier.
Completely ignorant here: - I really want to do a project in an almost "pure" functional language. I tried with Elixir and Phoenix, and while they are certainly great, and I wouldn't mind using it again, Elixir, and subsequently Erlang didn't feel like FP a lot of times, it felt like the warty Elixir/Erlang way to do FP, so it didn't scratch that itch for me (but again, still a great experience overall) - is there a…
Earlier quoted context omitted.
We use F# in prod. Could not be happier.
Completely ignorant here: - I really want to do a project in an almost "pure" functional language. I tried with Elixir and Phoenix, and while they are certainly great, and I wouldn't mind using it again, Elixir, and subsequently Erlang didn't feel like FP a lot of times, it felt like the warty Elixir/Erlang way to do FP, so it didn't scratch that itch for me (but again, still a great experience overall) - is there a…
(I think learning Standard ML first was very good for my programming practices, but I wouldn't suggest it for real projects)
Earlier quoted context omitted.
> This is exactly what I wrote, but in a Stockholm-syndrome-y way. Do you complain about having to put braces around C expressions to not get unexpected behaviour from the compiler? > He points out a real ambiguity in the syntax where the parser literally parses the same-looking and same-behaving statements completely differently. No, he doesn’t. If that what you got from the article, you were bamboozled. He points o…
If you shouldn't write code that way then it should be a compilation error (or at the very least a warning) to write code that way.
It’s perfectly legitimate code and working code. It’s just hard to read.
Should language prevents you from writing hard to read code if it means making trade off? I personally think that’s what linters are for but you are free to disagree.
I’m going to bed and don’t think I will revisit this comment thread. It’s probably the longest discussion I ever had about syntax points you don’t even encounter while using the language.
I have fond memory of writing OCaml. It’s nice to use. It gets out of your way. The compiler is quick. It gives nice error message. The syntax and semantics are flexible enough and elegant enough than you don’t feel like your fighting the language and your code feels nice. That’s what matters to me at the end of the day.
Why would a company use ocaml? I’ve worked in software now for most of my life, from small to the biggest companies. I’ve watched teams with senior developers use non mainstream languages to build services and just about every time those devs get board again, leave the team, leaving them stuck with this system that’s hard to develop and different from the rest of the orgs, eventually resulting in a complete rewrite.…
Earlier quoted context omitted.
Not really third-party; ocaml-ppx is something similar to `javax` in the Java space? But it is optional and doesn't come bundled with OCaml. Recursive structures are only rare in Rust _because_ they suck to write and have terrible performance characteristics in the language. In languages like Haskell, OCaml and Scala using tagless initial encodings for eDSL's [2] are really, really common. I don't write Rust like I w…
A lot of these things that you mentioned are valid flaws in Rust. I'm not going to dismiss them as not important or non-problems because they are genuine issues. Compile times suck. We could use hot reloading and a REPL. Debugging macros, instrumentation and perf stuff is good, but I assume it could be better. That's what I expect from a language community. Not constant denial about the state of usability. And it rea…
Compile times in Rust are a problem, but the RLS does a good enough job of feedback and the development loop happens enough in compile time, that users don't miss it enough, compared to, say, Java which relies heavily on runtime behaviour/reflection for application behaviour.
Debugging token macros could be better, such as with a better macro-stepper, but you don't write enough macros in Rust to care heavily about it to make it a big deal, unlike in a Lisp.
Hot reloading would be nice, but not and ~essential~ part of development and deployment like in BEAM. Better reflection utilities might be nice but I doubt Rust libraries will ever be heavily dependent on it in the same way that Go or Java are.
I think you should give F# a shot instead. 1. No standard and easy way of implementing interfaces No problem in F#, you have interfaces, abstract classed, ... 2. Bad standard library In F# you have access to the full .NET standard library and ecosystem. There are also quite a lot of libraries that are especially designed to take advantage of F# (SQL libs for example). 3. Syntax problems 3.1 OCaml doesn’t have a singl…
> NuGet is a decent/good package manager I remember F# designed its own package manager (paket) because of NuGet's deficiencies. I haven't been on that ecosystem for a while now. Have things changed? (My memory is that paket added friction and I eventually dropped it for nuget on my personal projects).
Earlier quoted context omitted.
Functional programming community likes this stuff. They go into the classical mathematicians’ trap of writing more and more general versions of something even though it’s not necessary.
I don't think this is correlated to functional programming. Programmers in general tend to over-architect because we're often learning as we're going and sometimes it's more fun to use some cool concepts. Since design patterns started becoming en vogue back in the day, OOP codebases got filled with those patterns. Now we are left picking up the pieces with things like `AbstractProxyFactoryBean` or whatever. Same thin…
Of course, I haven’t read every file, so maybe I got lucky with my random sampling.
Earlier quoted context omitted.
I'm sure some companies out there might find a competitive advantage for using exotic languages and tech stacks. But I get the impression the more common scenario is that the engineers were bored and given the chance, wanted to play with something new and shiny. It also depends on the company's prestige. A company like Jane Street using OCaml? Considering both their prestige and the amount they pay, I'm sure they wil…
Jane Street wasn't all that prestigious when they started using OCaml. The way they put it is "it was easier to find great programmers in the empty set of people who know OCaml than in the huge set of other programmers" (roughly). So, on the contrary, I think it might help boring cludgy company find quality talent. I think there is a fallacy being repeated in this thread, namely that the choice is between mainstream…