Hacker News new | past | comments | ask | show | jobs | submit | totalperspectiv's comments login

Bio-Rad Labs | Software Engineer | Full-time | Boulder, Colorado

This position for a small team in Boulder working on instrument development. You would help to build and maintain the data processing pipelines and internal tooling used by research and development for evaluating instrument performance. Portions of this architecture will eventually ship on the instrument itself.

Qualifications:

  * Experience building data processing pipelines / applications and managing data
  * Fluent in Python
  * Experience with relational databases
  * Experience with Docker
  * Comfortable at a command line
  * Comfortable in a Unix environment
Opportunity exists for working in TypeScript, C++, C, and Rust codebases if interested.

Please note, the job req linked here has out of date qualifications, but is the link to apply through: https://careers.bio-rad.com/jobs/software-developer-ii-pytho...


Does anyone know where to find the 1978 column Pratchett wrote about Star Wars? It's referenced in the article but I don't see a source and would love to read it.


I found a little more info about it but unfortunately no copy:

"‘SO, BANG GOES THE PERSONAL TOUCH’, Bath & West Evening Chronicle, 22 April 1978, p. 10. This is TP’s ‘Star Wars‘ piece that he tended to mention when talking of his years at the Chronicle, but I could not track it down when I searched the issues in the British Newspaper Library in Colindale, North London (now closed and moved to the town of Boston Spa). Perhaps it was in an issue missing from their collection, or I was looking in the wrong issues. Star Wars was released in London in December 1977, but only reached Bath the following April. Discovered by David Moger, to whom my thanks. CS"



The only other information I found was that it was published in the Bath Chronicle.

If you have access to their archive, that will narrow it down to "only" 365 issues.


I've had a look to see what's in the Bodleian and the British Library from there, but it doesn't look like 1978 is online. Post-1998 is on LexisNexis, and the BL's (paid) online service has up to 1950, but there's a gap in the middle. You could almost certainly go and read it in the BL reading room in London, though: their print/microfilm coverage of British newspapers is very good.




It's also very similar to my tool hck (https://github.com/sstadick/hck) which is in turn similar to choose, just faster, supports compression, and supports column selection via matching headers.


Multi-format, multi-threaded compression and decompression cli tool. This uses zlib-ng and libdeflate by default for a large performance boost over pigz, which just uses zlib by default. Notably this also supports snappy.


It’s odd that they didn’t include Nim in the benchmarks in their paper: https://dl.acm.org/doi/pdf/10.1145/3360551


I know nothing about Nim or genomics. Why is it odd that they didn’t include Nim?


Nim has had some success in genomics mainly thanks to the work of https://github.com/brentp

Nim can be sold as a "A strongly-typed and statically-compiled high-performance Pythonic language" as Seq (although it is more than that and does not actually have as a goal to be Pythonic, see https://nim-lang.org/ or https://github.com/Araq/nimconf2021/blob/main/zennim.rst).

Still, given the small size of Nim community and even smaller size of the genomics nim subcommunity, I would say it is not that odd that is not included in the benchmark. The existing nim genomics library might not even cover the functionalities required by the benchmark.


Nim is not really 'pythonic'. It does have some superficial similarity with Python (being whitespace sensitive) but it begins to diverge pretty soon. This is not really a criticism of Nim. I quite like many of the choices in Nim.

Seq claims that vast majority of python programs would work as is. I have not validated that claim, but Nim can absolutely not make that claim. Any python library would require substantial porting effort to be translated to nim.


Nim is pretty pythonic in terms of expressiveness.

Of course Nim is statically typed, but a lot of Python code that does not use dynamic typing heavily can be ported to Python surprisingly easily.


Calling Nim Python is like calling OCaml or Scala Python, it's not really true. The main reason people use Python is because it is Python, not because of an extractable list of things.


That is an extremely well put comment in the link. Thanks for sharing it.


It was indeed an great exercise! Part of the motivation for me was also performance oriented. I should add some Perl one liners to the benchmarks to see where they land as well. My experience is that they are usually a bit slower than awk.


I had this exact same progression, but with Python instead of Ruby. Go was a great intro to statically typed langurs though, I’d take go over JVM any day.

Currently love Rust, but Crystal, Nim, and Swift are all rather distracting.

Once Go gets generics I’ll be interested in giving it a second look.


I’ve been using smartstrings, which is both excellent and maintained. https://github.com/bodil/smartstring


Ah, nice, I was looking at the smallstring package that's appears abandoned. I'll be sure to check this one out.

The good thing about having a decent type system is that I expect that transitioning to smartstrings should be painless! Thank you for that.


In case somebody stumbles upon this conversation in the future: I just migrated a project to use smartstrings and it works a bit differently from smallvec. Smallvec lets you decide how big you want to make the static buffer before it allocates, whereas smartstring's static buffer size is alsways `size_of::<String>() - 1`, that is 23 bytes on 64 bit architectures and 11 on 32 bits. If I want, say, a static 128B string smartstring won't do any better than std::string::String.

It's still a very nice lib though, and a smart optimization, but it doesn't cover all of my use cases for small string buffers.


And the Pony guy


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: