veber-alex

yabai can switch workspaces without that dumb animation but it requires injecting code into the Dock which requires disabling System Integrity Protection.

Really wish Apple would give users more choices here without requiring third party hacks.

You forgot to zoom first.

huh?

Any python library that cares about performance is written in C/C++/Rust/Fortran and only provides a python interface.

ML will have 0 benefit from this.

FYI the free version of RustRover has forced telemetry that cannot be disabled.

"It’s also important to note that if you’re using a non-commercial license, you cannot opt out of the collection of anonymous usage statistics. This is similar to our Early Access Program (where statistics is opt-out) and in compliance with our Privacy Policy"

Fleet uses rust-analyzer for Rust support and not the jetbrains rust plugin that is used in RustRover and Intellij.

Considering the state Fleet is in you are much better off with VSCode for Rust + web dev support.

Or just array::map

https://doc.rust-lang.org/nightly/std/primitive.array.html#m...

It's like phones with 120Hz displays.

You don't know you need it but once you have it it's hard to go back.

python types can be ignored if you choose to ignore them.

Running pyright in CI/CD and in vscode has considerably improved the quality of my code, especially when refactoring.

The baseline M3 model is a complete joke, 8GB of RAM and support for only one external display.

This should have been a MacBook Air.

Edit: Oh, and one less thunderbolt port, nice.

And Intel CPUs

> It also looks like (soon) you’ll finally be able to configure global lints for a project. Until now, you had to hack your solution to keep lints consistent for projects.

> I questioned my sanity every time I circled back around to the Clippy issue above. Surely, I was wrong. There must be a configuration I missed. I couldn’t believe it. I still can’t. Surely there must be a way to configure lints globally. I quadruple-checked when I wrote this to make sure I wasn’t delusional.

You create a .cargo/config.toml in the workspace root so it covers all your crates.

inside the file:

  [build]
  rustflags = ["-Wclippy::lint_name_to_warn", "-Dclippy::lint_name_to_deny"]

The only limitation is that rustflags are not additive, so if you have other sources of rustflags like the RUSTFLAGS environment variable it will overwrite this setting.

pyright and ruff are my new go to python tools, replacing mypy, pylint, isort and black.

So far the only thing that bothers me about pyright is that it can't infer the type of collections based on later insertions.

So in something like:

  lst = []
  lst.append(1)

lst is of type list[Any]

I also program in Rust so I kinda expect this to work :P

I asked the maintainer about this and this is apparently by design, though mypy handles this correctly IIRC.

Yes but it is very easy to hold mutexes locked longer than needed because you usually don't think about when stuff is dropped in Rust, you just let it go out of scope.

I have gotten really annoying deadlocks because of this in the past.

But why?

There is no GIL in C/C++/Rust/Zig/Whatever, just use threads.

> b) As I understand it, Box gets "special treatment" by the compiler/type system, so pretending it's just a pure standard library component is a bit obfuscatory

There is a strong desire to stop that and have Box be a normal std type, the main thing that is blocking this at the moment is that Box has special deref magic that is not possible to implement with surface level rust syntax (even with nightly features).

Changing the type of runtime doesn't change the API at all.

Even in a single threaded runtime spawn requires Send and you need to use LocalSet + spawn_local for !Send futures.

What's the problem with Send bounds? So you use Arc instead of Rc.

> Isn't Rust's type system mostly about not having GC? What specific type system features are you looking for outside of borrow checking? Macros?

1. ADTs with exhaustive pattern matching

2. No exceptions

3. Zero cost generics

4. Traits

5. No nulls

6. No inheritance

> Comptime gives you literally everything you get from macros and generics without the complexity of needing to know 3 separate Turing complete languages to get it.

comptime doesn't allow you to create domain specific macros like html! in Rust, it also doesn't allow you to constrain what types are accepted by your functions. It also has its own problems with long compile times.

> So you’re stuck choosing a single CPU or having to write send and sync everywhere. There’s a lot of use cases where you would want a thread-per-core model like Glommio to take advantage of multiple cores while still being able to write code like it’s a single thread.

No your not, you spawn a runtime on each thread and use spawn_local on each runtime. This is how actix-web works and it uses tokio under the hood.

https://docs.rs/actix-rt/latest/actix_rt/

You can annotate the return type inside the closure in those cases, for example:

    let x = || async {
        let file = std::fs::read_to_string("foo.txt")?;
        Ok::<_, Box<dyn std::error::Error>>(file)
    };

The reason Rust chose stackless coroutines is because it allows zero cost FFI, which for a systems language is extremely important.

And why would I care about mypy docs? pyright does the correct thing by showing an error.

In any case, the second example is definitely not a stub.

> Um lol what do you think the error is here? This is widely accepted syntax for a stub.

No it isn't. The accepted stub syntax is an ellipses (...).

A competent type checker like pyright will error on this code.

  Function with declared return type "int" must return value on all code paths
    Type "None" cannot be assigned to type "int"

And if you need more proof that pycharm is useless as a type checker:

  def foo(b) -> int:
      if b:
          return 1

A classic error where you forget to return a value from all paths and pycharm is silent.

Each type checker can implement however strict rules it wants. And pyright gives the correct answer here:

  Expression of type "None" cannot be assigned to declared type "int"
    Type "None" cannot be assigned to type "int"

Well on Pycharm 2022.3 which is what I still have installed even this simple function doesn't show any error.

  def foo() -> int:
      pass

I sure hope they improved the type checker in later versions...

Pycharm has the worst type checker that exists today. It may have been the best a few years back but others have suppressed it considerably.

I recently switched from Pycharm to vscode which uses pyright and it's night and day on the amount of type errors it catches, it considerably improved the quality of my code and confidence during refactoring.

And to add insult to injury Pycharm doesn't even have a pyright plugin and the mypy plugin is extremely slow and buggy.

> You have to pulverize the macro into syntax atoms and then reassemble it piece by piece into an AST that the compiler needs. All the processing to do all of that should be a part of the compiler--not a smattering of 50 crates (syn being the most oppressive one) and a weak compiler API.

First of all it's not 50 crates, it's 3 main crates syn, quote and proc-macro2 and a few smaller helper crates which are used less often.

And the reason to not include them in the compiler is exactly the same reason why "crate X" is not included in std. Stuff in std must be maintained forever without breaking changes. Just recently syn was bumped to version 2 with breaking changes which would have not been possible if it was part of the compiler.

In any case, shipping precompiled proc macros WASM binaries will solve this problem.

> Serde has to enumerate the universe even for types that wind up not used. Those types then need to be discarded--which is problematic if it takes a non-trivial amount of time to enumerate or construct them (say: by using proc macros). Part of this is the specification that must be done because Rust can't do compile-time reflection/introspection...

Yes, it's a design tradeoff, in return Rust has no post-monomorphization errors outside of compile time function evaluation. I think it's worth it.

> I'm beginning to think that the folks who claimed that compiler speed is the single most important design criterion were right.

I don't agree. As long as the compile times are reasonable (and I consider Rust compile times to be more than reasonable) other aspects of the language are more important. Compile time is a tradeoff and should be balanced against other features carefully, it's not the end goal of a language.

proc macros are user written code, how can you "place them into the compiler"?

What does the orphan rule have to do with the compilation speed of serde? How does it reduce the work it needs to do?

The tier 3 Windows XP target is no_std only, which makes it useless for the vast majority of developers.

For all intents and purposes Rust is dropping support for anything below Windows 10.

It is suggested in the MCP that a new target can be created for older versions of Windows if members of the community will step up to support it.

https://github.com/rust-lang/compiler-team/issues/651