petr_tik
Joined 10 years ago
Joined 10 years ago
I agree that listing Haskell or OCaml on one's CV isn't enough. I think this holds the same way for other languages, at least in the company where I interview.
To the people who are interested in solving problems using functional languages. You should apply, even if you think you are not part of the "selective" in-group like PhD or language expertise
One data point - I get paid to solve problems by writing OCaml code. I am a self-taught programmer with a linguistics undergrad degree.
I hope this helps others who are interested, but are feeling insecure because of the stereotype that one needs a PhD to write programs in a particular language.
From the manpage of mold-1.3.0, I get the impression mold is designed to scale up to 32 cores, but not more.
man mold | rg -C2 32
--threads
--no-threads
Use multiple threads. By default, mold uses as many threads as the number of cores or 32, whichever is the smallest. The reason why it is capped to 32 is because mold doesn't scale well beyond that point. To use only one thread, pass --no-threads or --thread-count=1.
Is this correct or does the manpage need to be updated?Given that the UK has left the EU, couldn't you call every trade deal or cultural exchange with a non-EU country a Brexit project?
Even if it is, what is wrong with that? The people of Britain voted for Brexit and now need their elected officials to deliver, which motivates projects like these
Edit: to clarify, i live in London and i didn't vote for Brexit. Regardless of the outcome, I consider it a national security issue and a productivity boost to have cheap energy collected from a diverse set of sources from solar plants abroad to domestic nuclear energy plants and off-shore wind turbines.
If you live in Britain, would you really prefer Britain stop investing in projects like these, just because there was an election result you disagreed with?
On the contrary, the rust crate ecosystem and tooling means a lone developer can compose specialised libraries to produce a working artefact that scratches her own itch. Such productivity is the opposite of getting something working at all.
Trying to build an OSS cpp project or even worse, use an OSS Cpp library in your own project is more along the lines of "getting something working at all". Every third-party and some enterprise-internal Cpp libraries require one answers the following questions:
- how do I build the damn thing?
- how do I run the tests?
- how do I use the library? Vendor into the repo? apt install?
- what APIs does the system/library provide?
- where can I find the documentation and examples?
- how do I set up code completion?
- how do I know am using the library interface correctly?
- how do I know I didn't violate any invariants/safety guarantees?
Compare with the list of dependencies across the Cargo workspace members.
https://github.com/lapce/lapce/blob/master/lapce-core/Cargo....
https://github.com/lapce/lapce/blob/master/lapce-ui/Cargo.to...
https://github.com/lapce/lapce/blob/master/lapce-rpc/Cargo.t...
The cost of adding a new rust dependency when measured by the number of questions you need to answer beforehand is nearly constant. This means a layman can be more productive in rust.
eg. https://github.com/rust-analyzer/rust-analyzer/blob/master/d...
Rust has a built-in macro marker for tests. I suspect rust-analyzer uses this fact when it searches all AST nodes with the #[test] marker that contain a call to the symbol in question for the implementation.
So adding the related tests interface to other languages would require similar AST-level primitives.