the main reasons for my preference are that: gmail/fastmail are simple, I can use from multiple computers easily, have good defaults and most importantly, they almost always work. Outlook users seem to constantly have something broken.
I do realise that i am reaping the benefits of a centralised system, and in the case of gmail, monetised by advertising, surveillance and user lock-in. Probably the ideal for me would would be a self-hosted web client, e.g. Mailcow
Of course, and thank you for taking the time to ask!
For the foreseeable future the aim will be rather on the QuickJS/DuckTape level than beating V8. But! That is only because they need to be beat before V8 can be beaten :)
I'm not rushing to build a JIT, and I don't even have exact plans for one right now but I'm not barring it out either.
If my life, capabilities, and external support enable it then I do want Nova to either supplant existing mainstream engines, or inspire them to rethink at least some of their heap data structures. But of course it is fairly unlikely I will get there; I will simply try.
1. It always clearly identifies itself by name in the participant list (e.g., "Nomi.so Notetaker" or "Nomi.so [Host's custom name]'s Notetaker") so everyone can see it's present.
2. It also posts a message in the chat at the start, informing all participants that it's there to take notes and that the call is being recorded/transcribed.
If you're the host initiating Nomi, for instance through our desktop app integration, there's an additional step: you're required to explicitly confirm that all participants have consented before Nomi will join and start recording.
These in-meeting notifications and host confirmations are designed to ensure transparency. We're primarily focused on use cases, especially with enterprise clients, where trust and ethical recording practices are mandatory to make a deal. We have a strict policy against any covert use and have taken action, including banning accounts, when misuse is identified.
If I am in a call with someone using Nomi, can I send a message in the call or wherever to disable it, or will I have to ask the person using it to turn it off?
> If you're the host initiating Nomi, for instance through our desktop app integration, there's an additional step: you're required to explicitly confirm that all participants have consented before Nomi will join and start recording.
And in-car navigation systems make you promise to never touch the screen while you're driving the car on the road.
For instance, some cars periodically check if your hands are on the wheel. (Tesla does that, right?)
This type of check could helps confirm you are still engaged and proactively asking for consent. That would be a big step for us, we have searched the whole note-taking industry and it is very hard to find a method that is truly foolproof.
If you have a solution that wouldn't rely on pure user trust, please let us know.
> If you have a solution that wouldn't rely on pure user trust, please let us know.
Off-the-top-of-my-head... your software gets the video feeds of the other participants in the call, right? Your service could prompt people to give a simple Thumbs-Up / Thumbs-Down gesture to their cameras to signal consent (or text-chat message for those who can't gesture).
I can understand if there are legal reasons to inform, or if there is concern about the call data leaving local.
However, if the model was run locally, I do not think a product like this should need to notify that it is running.
There is nuance around whether an actual recording of the call would be stored. For example, keeping a copy without notifying the other party creates an unexpected risk if there was a data leak.
But otherwise this kind of behavior will become no different from a noise reduction filter passing over the audio channel.
It is simply augmented reality intended to assist in humans relating to one another.
In the beginning, when you read papers like this, it can be hard work. You can either give up or put some effort in to try to understand it. Maybe look at some of the other Jepsen reports, some may be easier. Or perhaps an introductory CS textbook. With practice and patience it will become easier to read and eventually write like this.
You may not be part of that world now, but you can be some day.
EDIT: forgot to say, i had to read 6 or 7 books on Bayesian statistics before i understood the most basic concepts. A few years later i wrote a compiler for a statistical programming language.
The state of the art is always advancing, which greatly increases the burden of starting from first principles.
I somewhat feel that there was a generation that had it easier, because they were pioneers in a new field, allowing them to become experts quickly, while improving year-on-year, being paid well in the process, and having great network and exposure.
Of course, it can be done, but we should at least acknowledge that sometimes the industry is unforgiving and simply doesn't have on-ramps except for the privileged few.
> I somewhat feel that there was a generation that had it easier
I don't think so. I've been doing this for nearly 35 years now, and there's always been a lot to learn. Each layer of abstraction developed makes it easier to quickly iterate towards a new outcome faster or with more confidence, but hides away complexity that you might eventually need to know. In a lot of ways it's easier these days, because there's so much information available at your fingertips when you need it, presented in a multitude of different formats. I learned my first programming language by reading a QBasic textbook trying to debug a text-based adventure game that crashed at a critical moment. I had no Internet, no BBS, nobody to help, except my Dad who was a solo RPG programmer who had learned on the job after being promoted from sweeping floors in a warehouse.
Careful now. That kind of provocative black-and-white claim will only alienate the 50.1% of American voters who appreciate Mr Joker’s anti-government and anti-woke agenda.
Serious question: why Rust? Sounds like this is not exactly systems level programming or any user would suffer from or even notice garbage collection latency.
Is Rust building up a decent ecosystem now for application programming? When I tried developing in Rust I came to the conclusion that you pay a heavy price for not having a garbage collector. Was I doing it wrong?
I find Rust super ergonomic for any kind of app. The memory management aspect is trivial and second nature to anyone used to unmanaged languages, and the type system equally is not difficult to understand.
It's a general purpose language, but it does give you full control. Plus, of course, you can encode a large amount of program states in the type system and borrowing checks enforce rules that programmers usually have to check in their head.
I find that when I write Rust, I have to worry about an order of magnitude less about silly things like lifetime bugs, reference bugs, resource cleanup, all of which are 80% of my job when I write C#, or other similar managed languages.
Plus Rust can generate a static executable, which is reasonably small, and doesn't require a third party runtime.
As someone used to unamaged languages since 1986, and with a major focused on systems programing, it isn't that clear cut.
Rust executables are only 100% static on OSes that expose system libraries as static libraries, and there are not many of those around, outside embedded systems.
As a counterpoint to the parent commenter, I like using Rust for personal stuff (like the project being linked to) for almost everything besides the memory model; I prefer Cargo to any other build tool I've used, and I like how I can eliminate boilerplate with stuff like Serde (for serialization), clap (for argument parsing), and even for how I'm able to write one-off macros to generate code for myself. The documentation for the language and tooling is great, and most packages have fairly good documentatio as well because any package published on crates.io will have it generated from the doc comments into a static site and hosted on docs.rs. The compiler error messages are better than any other language I've used, and at least for my personal use on Linux, I can easily compile with musl and get a fully static binary when libc is my only native dependency; I'm sure that Linux desktops are part of the "not many of those around" you refer to, but the same trick would work just as easily for any Linux server, and I do feel like there are plenty of those around!
If I could get all of those quality of life things in a language with a garbage collector, I'd probably use that for most things instead. Right now though, the closest options would be maybe OCaml or Swift, one of which doesn't really give me nearly as much in terms of quality of life stuff around documentation and tooling, and the other isn't nearly as streamlined to use on my platform of choice as I'd like, so I'm using Rust unless (or until!) something better for my personal projects comes along.
After years navigating this issue, I think the common understanding of "static" binary is just "something that won't give me a dll / dylib error on startup when I copy it to my friend's computer"
Which is a possibility, given that ldd/Dependency Walker result won't be an empty list.
Even shipping the whole computer on a container, might not do it, because most containers are leaky abstractions the way their Dockerfiles are written.
Yet in practice this works fine for all intents and purposes.
Sure, you might get a loading error if you try to run your Ubuntu 24.04-compiled executable on Ubuntu 18.04 if you use the default toolchain. tTat’s exactly the same as C or C++, only much easier to fix in rust by rustup-installing the right tool chain.
Compiling on Ubuntu 18.04 and running on 24.04 is absolutely not an issue. Same for windows.
In practice this is really not a problem, especially for cargo libraries that you anyway build from source.
I would say the same regarding dynamic linking, which is why most OSes have moved away from being static linking only executables, except embedded in the cases where it is a single blob uploaded into the device.
Not even modern 3D graphics APIs, none of them, work with static linking, yet another area static linking advocates have to accept the industry has moved on.
> Rust executables are only 100% static on OSes that expose system libraries as static libraries
This seems to be a weird hair to split. GP clearly means “a single executable you can run on any install of the target OS without dependencies.” Whether it’s a truly honest-to-goodness static binary that don’t link to libc or libSystem or whatever is important to approximately zero people, outside of internet pedants.
I agree that this is what many people -- including me -- are caring about.
However, it is not achieved in practice with "static" languages like rust and golang for me
I frequently run into dynlib issues with regards to incompatible glibc references when sharing binaries between different OS like Ubuntu and Fedora or even just different versions of the same OS
> I frequently run into dynlib issues with regards to incompatible glibc references when sharing binaries
Assuming you’re talking about rust binaries, this would only happen if your binary is using glibc symbols that don’t exist on an older version of glibc, and then try to run that binary on a system with the older glibc.
But glibc is a red herring here, because rust is only using libc to call syscalls on the host, because that’s how you’re supposed to do it on every OS, and that’s how you have to do it on every OS but Linux. (Only Go seems to want to implement their own syscalls on Linux.)
It’s a red herring though, because even if rust made their own syscalls and didn’t use glibc on Linux, you’d just fail with ENOSYS when these syscalls are used, instead of failing with undefined symbols at load time. If you try to run stuff that was developed against newer kernel features, on a system without these syscalls, you’re going to run into an equivalent issue. (You might get lucky and not need those syscalls in your app, but that’s not always going to be the case.)
It is, because so many folks make such a big deal of how using computers as they used to be until early 1980's, with single static linking model.
Ironically the same folks don't see to appreciate how object files and binary libraries work in static linking, lets make it even better compiling always from source.
> Good dependency management, a rich package ecosystem, defaults to static binaries which are easy to distribute and a tendency to be fast (even if it’s just the lack of startup overhead) make it a popular choice.
> .....
> Plus Rust can generate a static executable, which is reasonably small, and doesn't require a third party runtime.
People are using a term in a different way than you want them to.
They use static binary to mean “the dependencies I specify in my package manager are all put in the one binary, and it doesn’t require a separately installed runtime to run”, which is totally reasonable, and it is opposed to so many languages that don’t work this way.
You’re using static binary to mean “does not link to anything at all”, which on some systems results in worse portability, since the syscall interface is unstable and linking to libc/libsystem/etc is the only supported way to make syscalls.
You come into the discussion assuming definition B, ignore the fact that they’re using definition A, say that they’re making a big deal about definition B, etc.
There’s no confusion from anyone here but you. We all are using definition A. You’re the only one using definition B. It’s probably better if you just recognize that and move on rather than insisting everyone here is an idiot but you.
I've used both, and they are comparable in library support. I happen to write _much_ faster in Go, so it's usually my default choice for CLIs, unless I specifically need to bridge with another Rust program.
1. Historically a CLI like this would often be written in C, so Rust isn't that strange of a choice.
2. Rust is know for the borrow checker and being a great low level language. However, it's also an excellent modern general purpose language with a great ecosystem. People end up using it for all kinds of things because it's a joy to use.
"When I tried developing in Rust I came to the conclusion that you pay a heavy price for not having a garbage collector. Was I doing it wrong?"
Rust is tricky to grasp initially, the learning curve goes pretty much vertical immediately, but once you "get it" it's very nice. When I started out I overused borrowing and ran into heaps of lifetime problems. I think limiting yourself to only using references for function arguments and, rarely, return values is a good place to start. As soon as you are start adding references to struct you should stop and think about who owns the data and what its lifetime is. Thinking properly about ownership is the big shift from GC languages. Once you've gotten into that habit, lifetimes are downstream from that.
Rust is my main programming language and Python the second. Rust is very much useful for application programming - especially these sort of applications. In fact, Rust is the language I sometimes reach for when my shell scripts cross a certain threshold of complexity. Rust even has some tools and an RFC to address the use case of using it like a scripting language (I believe that Go has something similar too).
I don't face much friction from the borrow checker to consider it a 'heavy price for not having a garbage collector'. There are even tools like bacon [1] that can give your real-time feedback on your code. It's even better with the default language server. I sometimes train other developers in Rust - mostly people who are not even into systems programming (JS, Python programmers). However, they don't seem to struggle too much with the borrow checker either. Could you elaborate a bit on what you consider as 'the heavy price'? What sort of issues were you facing frequently?
Syntactically it's a pretty nice language, with a nice and sane ecosystem (crates, etc), and it's fun to write (which is a pro especially for unpaid hobby projects). If you get used to it, it's nice to write various things in it. I'd probably use it for CLI tools at this point.
You do pay a bit in syntactic overhead (lifetimes, borrow checking perplexities), though you get used to it. I'd still not use it for a standard product-y web app. For CLI tools though, it's pretty good.
I write a lot in Python, but I love to write small utilities in Rust as well. The tooling around command line stuff is just really good in Rust and the distribution (just a binary) is just simpler. On top of that Rust forces you to handle errors with IO, like paths correctly to a degree that gives you much more confidence in the resulting tool.
Honestly, Rust is a breeze to make CLI/TUI apps in. Some crates worth looking into: tokio (mostly for stuff built on top of it), clap, promptly, colored, ratatui. These are just a few ones to get you started, but there's lots more depending on what you need to accomplish!
Good dependency management, a rich package ecosystem, defaults to static binaries which are easy to distribute and a tendency to be fast (even if it’s just the lack of startup overhead) make it a popular choice.
It also helps that rust attracts the kind of devs that make nice tools.
As a user, if I have the choice between 2 apps, I’ll strongly favor a Go, Rust or ANSI C app over a Python, Ruby, Shell or C++ app.
This is because empirically, they usually work better, feel more polished, faster and I can easily contribute patches if I need. If a tool is written in Python, I’ll go out of my way to find a rewrite in another language.
Serious question: why not, if the author just knows Rust? Are you so allergic to anything written in Rust? Then get some new pills and ointments because there's going to be more and more of it.
As a Rust developer, let me point out that this is certainly the wrong way to respond when someone criticizes or makes an observation about Rust. Especially when they aren't hostile at all. It's clear from the commenters' question that they have a some preconceptions about Rust for which they are seeking clarifications from other Rust users. This sort of response will only make them give up on Rust due to the toxicity of the community, rather than address any real issues they may be facing.
It's just wherever you go, here, Phoronix, Linux Kernel Mailing List for example, the forums are full of haters that just ask "not again, why?" anytime Rust is mentioned. Maybe I've become biased because of that.
Rust helps with performance and security, lots of examples are evidence of that. It's not 100% bulletproof, but nothing is. But it helps. And yet IT people just yell on it for some reason. Like we all should just get stuck forever with C, C++, praise Go, and hate everything else.
The antibodies are probably to the "written in rust" addendum, which seems unnecessary unless rust adds something to the product. Much of the answer above to "why Rust" concerns the developer, and we are potential customers, so who cares? Just drop the "in Rust" and don't worry going forward.
Honestly though I thought we were past the "written in Rust" phase.
It works. Including on me. I'm much more likely to pay attention to a tool that I know is written in Rust. This is both because I love the language and really enjoy using it, and because I've gotten conditioned to believing that tools written in it will be extremely robust, fast, useful, and stable. I can easily rattle off a dozen tools I use on a regular basis written in Rust that are significantly better than their non-Rust counterparts (starting with ripgrep, which is extremely fast). It's effective marketing still.
