You gave up using a programming language after a day? And Haskell after installing/building some dependencies for 20mins? Tbh, this sounds like you were not really trying. What kind of experience with a programming language do you expect to have after a mere day? Learning takes time. Anyone might spew some not idiomatic code within a day, but really becoming proficient usually takes longer.
Do you have any references for the "Rust is heavily influenced by FP" thing? To me it does not feel that much FP. I have (for now) given up writing FP like code in Rust. ML-influence -- Yeah maybe, if I squint a bit.
> What kind of experience with a programming language do you expect to have after a mere day? Learning takes time.
It does, which is why you need tooling to get out of the way and let you actually learn. Working out obscure tooling commands to build a hello world app then having to grok the error messages absolutely destroys the learning loop.
For rust it took me approximately 3 minutes from scratch to install, bootstrap a project and run the hello world CLI. The rest of the day was spent purely, 100% learning rust. Not Cargo.
20 minutes to install some beginner level dependencies, presumably with little feedback as to what is going in? Dead.
As I see it, this is a completely legit beginner level perspective. When I first touched a programming language (C, Borland compiler) I was able to run a first program within minutes. I completely understand the frustration with development environments that frustrate an aspiring user unnecessarily - I had this experience with F#, VSCode an Ionide, which is a very ugly case. Haskell was not that bad, but it it certainly is not for the faint of heart.
> You gave up using a programming language after a day? And Haskell after installing/building some dependencies for 20mins...
I'd do the same. It's 2022. There are so many options without this friction, why would you fight your way through it?
If either language had some magic power or library, that'd be one thing, but their only selling point is the FP paradigm, which is only arguablysomewhat better than what other languages do. Not only that, but most other languages let you do FP to varying degrees anyway.
Haskell's promise is not only FP. That's part of it though, of course, to have an ecosystem, which encourages to continue in an FP style. Haskell's promise is also strong type safety and, as a distinguisher to many langauges, lazyness by default. Aside from that, its implementation is quite performant, if one needs to worry about such things.
I will take a 20min build process for dependencies (probably a few commands, which hopefully are documented in the project's readme and probably only once for most of the lifetime of a project on your personal machine) over a language, that is quickly up and running, but breaks any number of basic principles (for example looking at JS) and lets me shoot myself in the foot. Some languages and the lessons we take from learning them are worth some initial effort. Of course it is not great, that things are not as easy, as they maybe could be, but if the language has other perks making up for that, it might still be worthwhile.
> but if the language has other perks making up for that, it might still be worthwhile.
Totally agree, I just think for the vast majority of developers, the trade off here isn't worthwhile. This is reflected in Haskell's stagnant growth despite it's model being better for a lot of things.
Sure -- people have the right not to try things, which is basically what messing around with a programming language in a new language paradigm for 1 day is. That's fine, although it should also be expected that their opinions on things they haven't tried won't be given much weight.
Day one experience matters a lot to most people. For better or worse, your community won't grow if newcomers have to spend a day hating things first.
It won't matter if you're looking for a language to make your baby for the next 5+ years, but most people are trying to solve small problems on an incremental basis.
> Do you have any references for the "Rust is heavily influenced by FP" thing? To me it does not feel that much FP.
The original implementation of Rust was in an ML dialect (I think OCaml?), so from that we know immediately that the original authors were familiar with FP and used it for their own purposes. It seems odd, then, to assume that there would be no influence of their own language.
But if we look at the actual feature set, we find a lot of things that previously belonged almost entirely to the realm of FP. The type system as a whole has a fairly FP feel, plus algebraic data types, exhaustive structural pattern matching, maps and folds, anonymous functions, the use of the unit value for side-effecting work, the functioning of the semicolon operator (which is identical to the OCaml usage)... there's quite a lot, and those were just the examples off the top of my head!
My job/hobby is to produce code. It is not fighting a toolchain. It does not bode well for long-term efficient use of my [limited] time if I'm spending a whole day fighting toolchains from the outset.
User experience matters, and developers are ultimately users.
IME learning the (usually shitty) tools and the culture/ecosystem eat up way more time when starting with a new language than learning the language itself does.
I can absolutely understand abandoning such an effort if one's earliest interactions with the tools and/or ecosystem are very unpleasant.
Immutability, most things are expressions, no nulls. I think this is what they mean, it's a good experience if you want to go purely functional, they took influences from everything though.
Do you have any references for the "Rust is heavily influenced by FP" thing? To me it does not feel that much FP. I have (for now) given up writing FP like code in Rust. ML-influence -- Yeah maybe, if I squint a bit.