It is, hands down, my best experience working in a functional language. I do hobby work in it, and it seems super nice, but I'm not sure where everyone is.
> still very few people use it.
Looking at a chart of GitHub and StackOverflow usage[1], OCaml/F# seem almost steady compared to the other functional languages, my suspicion is that Rust absorbed a lot of programmers looking for functional concepts in programming languages.
My impression - the people who use it historically (and I've met a few) aren't the companies that typically proponent open source software and the like. They are "closed source" shops (e.g. finance, insurance, etc). Even I am not willing to post on more than a throwaway account. I'm currently using it for large scale production systems in a very large public company powering a large data volume product with very high peaks of customer traffic and it works a treat. We decided to try C# 9 after some F# because "higher management" - compared to F# the dev's have found it verbose and painful still, despite the new features.
The productivity benefits are small and sprinkled - I don't personally think there isn't one "killer feature/app". It isn't just one thing, its little things that add up. Given the team jumped from other ecosystems (e.g. Go/Node/etc) they found F# easier to approach than C#. This is the perspective of the team I run and it comes up in PR comments (I do less code writing these days). Comments like "don't have to do this in F#", or "we need a framework for this because C#" are known to occur. Easier unit test writing, less dep injection headaches, concise function passing, easier inlining of math for perf, easy mocking/stubbing, unions, etc etc.
The big weakness to me is that the people that use it typically don't want to flaunt it, and that means good mentoring, the best/simple patterns to use, etc and management buy-in are not really public. Communities that you can join are not into large scale apps, meaning good scalable patterns and lessons learnt are hard to find.
C# has been adding new major language features all the time since its inception, including pretty much everything we are seeing being added to Java these days.
Yeah, and this "kitchen sink" approach is partly why I stopped writing C#. Same thing is turning me away from JS.
It's exhausting trying to stay up-to-date with the language, in addition to changes in the frameworks and tools on top of the challenges of my day job.
I might be showing my age, but I've come to appreciate that features come after long and careful consideration, and not every single release.
My experience with F* is several unsuccessful hours of trying to compile hello world thanks to a complete lack of instructions for configuration and installation.
I'm a new developer (an intern, actually). I just started writing a system that requires a couple secret strings. Currently I just have them as constants with my code, with the idea that I'll figure out something to do with them once I make sure everything is working.
What should I do with those secrets though? I'm not sure how to store them securely. So far I've been considering putting them in the server configuration so they can be read from environment variables, but that seems inconvenient for me and other developers and also not that much more secure.
You read them from a config file and fill them into the config by hand while deploying. Never push secrets embedded into code or portions of the config file to your source repo.
You can hardcode the secrets to test stuff, but the first time you push the code to the repo should be the time you change it to reading from config. And add config to gitignore cause even if you don't stage the particular lines with the secrets in them, there will come one time where you'll rush or will have too long of a day when you'll push those secrets by accident. If you've got a public repo, then it's over. On a private repo then you may not notice this or not remember to remove it with a force push.
A point in time when you get tired of juggling config files manually in dev/prod is the point in time you explore the system for secret management and auto build/deployment as clearly your project has become useful/popular enough.
Those are my IMO and what I use as thresholds. Of course, if your environment is more relaxed there's no limit on further improving this practice.
The long standard for lots of software is to have a blank "file.conf.example" file (with only the variable names but blank values) which you commit to git, and have the code look for a file named "file.conf" which you explicitly exclude from git using gitignore. This allows you to have a template config file while still preventing the secrets from being written to git. Then you can have the software provide some sort of alert when it is launched for the first time saying "config file not found, please duplicate file.conf.example, fill in your details, and name it file.conf."
How to handle organizational secrets is definitely your concern, however, you are probably too junior to be making decisions on implementing security best practices in production. Likely your company has methodologies in place to deal with deployment secrets. Ask a senior dev how they handle secret management. In many companies there are key management tools such as Hashicorp Vault or Ansible vault. Basically without knowing your environment its hard to tell you what to do, but there are lots of options out there, and your company may have already implemented some of them.
At the VERY least, extract them to Environment Variables... ensure .env is on your .gitignore, and have your localized/dev configs in your local .env ... production environments should have them set. For more complex environments you can set via a secure key service, or build from there.
Again,. the LEAST you should do is use environment variables and keep the actual keys out of your code. .env files are a developer convenience measure, and easy enough to use side channels. I go a step further and ensure a fallback that might be the dev environment, but that is not the same as any higher environment
Maybe software for specifically Linux is kinda KDE's whole thing. I'm just happy they go out of their way to package and test their code against other OSs in the first place.
It wouldn't surprise me - I'll often do the same with Python on non-Windows systems rather than bothering with the native calculator; I'm not even sure if Linux has one (or if it's the same across distros), and Python is ubiquitous, fast, and has familiar syntax.
Personally I used to use Maple for this kind of thing circa 2002. It used to launch on Windows in a fraction of a second (faster than the built in calculator tool!), and was an amazing calculator for pretty much any purpose.
Unfortunately some version of Maple around that time switched to a Java-based front end, and thereafter took forever to load, and had a UI littered with glitches.
I've used J (a language in the APL lineage) as an interactive calculator before. It makes some things pretty easy, especially if you need to operate on series of numbers.
What's the sum of the numbers from 15 to 20 inclusive?
i.6 N.B. Returns an array 0 1 2 3 4 5
15 + i.6 N.B. Returns an array 15 16 17 18 19 20
+/ 15 + i.6 N.B. returns the number 105
edit: Or course, if we're talking about languages helpful for calculation, we simply must include a reference to https://frinklang.org/
