Our great sponsors
-
zig
General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
diem
Diem’s mission is to build a trusted and innovative financial network that empowers people and businesses around the world.
-
cryptography
cryptography is a package designed to expose cryptographic primitives and recipes to Python developers.
I tried Zig recently but I found the unsilenceable lints to be a huge productivity killer. I actually posted a link to the GitHub issue this morning. https://news.ycombinator.com/item?id=32751317
This makes a normal workflow with `watchexec zig test` basically impossible since before I can even run the tests I have to spend time hunting down which variables are used/unused at the moment and (un)commenting them. And it seems like they're planning to double down on this by making you adjust even more trivial things like public/private and var/const before it will even compile your code. https://github.com/ziglang/zig/issues/335 https://github.com/ziglang/zig/issues/224
Maybe I'm a bad developer, but my code is never perfect the first time around. I always spend time experimenting and refining my designs. I want to find a design that works, and only then spend time polishing and prettifying before I git push.
I do understand the reasoning (they don't want people committing poor quality code), but this implementation just seems completely backwards to me. It breaks the natural order. It's like saying we won't let you ctrl+s until your tests pass to make sure you don't commit poor quality code. Stop nannying me and just let me get my work done!
This really irritated me when I started working with go, but it stopped bothering me and now I even mostly like it.
The missing error checks are annoying, but if you have appropriate editor config it is hard to miss them: https://cdn.billmill.org/static/newsyctmp/warning.png
Basically writing go without `staticcheck`[1] is not recommended. If you do have it set up, it's pretty easy to avoid simple errors like that.
[1]: https://staticcheck.io/
For operator overloading you can do something like this: https://github.com/christopher-hesse/tenet#interesting-featu...
You have to specify the names more times but you can also do any syntax you want.
Temporal safety can actually be provided via tagged index handles (where the tag is a generation count). But this should be implemented by libraries, not built into the language (like: https://github.com/michal-z/zig-gamedev/tree/main/libs/zpool)
The fanaticism of Rust devs makes me think it's probably massively overrated (see Node yesterday and Ruby/Rails the day before) and Go is associated by Google which gets a perhaps unfair but still unignorable knee-jerk reaction from me to avoid it.
I don't know enough about Nim to pass judgment.
Two reasons I decided to give Zig a try: The official chat channel is on IRC, instead of Discord or Slack (so the people involved care about efficiency, open standards, and avoiding trends/bandwagoning), and it has an early but promising-looking Swift UI-like cross-platform UI framework in development: https://github.com/capy-ui/capy
To add to that, I think the vulnerability is actually caused by unsafe code too:
https://github.com/chris-morgan/mopa/issues/13
> Maybe it would be called #[expect(deprecated)]
Both this and the reply saying you should open an RFC worry me that it was tongue-in-cheek.
Or maybe it's the obvious name choice, heh, because it literally exists with that very syntax: https://play.rust-lang.org/?version=nightly&mode=debug&editi...
Not stable yet, as you can see, but all the RFC and implementation work has been done, and a stabilization report was even put forward back in July: https://github.com/rust-lang/rust/issues/54503#issuecomment-...
> rust is not well-suited for interfacing with FFI
How so? Packages like neon [1] and rustler [2] suggest otherwise. I'm using both of those in a real product (I'm using neon directly, to write native modules for an Electron app; on the back-end, I depend on an Elixir package that uses rustler).
[1]: https://github.com/neon-bindings/neon
[2]: https://github.com/rusterlium/rustler
