veber-alex

You can make it on stable Rust by using an enum with a missing variant. The compiler will give you a niche automatically.

Of course that doesn't scale to larger types as even with a macro the compile speed will be horrible.

> Obviously if the function is on a hot path iterating and summing with a number is far more efficient versus filtering.

I got curious and checked this in Rust, the generated assembly is the same!

https://rust.godbolt.org/z/jhGWdYPz1

This proposal seems pretty bad to me.

I think Go lacks the features to make this ergonomic and flexible.

Before adding iterators the language should add tuples so that you won't need to special case 0,1 and 2 artity functions.

And shorter syntax for anonymous functions to make writing this less verbose, I believe this has been proposed before.

Also the special case for "0..N" ranges seems very unnecessary.

You can get versioned link directly into rustdoc:

https://doc.rust-lang.org/1.71.1/src/core/slice/mod.rs.html#...

Because there isn't a one size fits all solution to error handling?

Because before anyhow/thiserror became popular there were 5 other popular crates for handling errors and if Rust added one of those to std we would be stuck with a subpar solution forever?

Because cargo is so easy to use that your preferred error handling solution is one `cargo add` command away?

Because for simple cases the tools the standard library offers are good enough?

I am confused by the examples, do you actually need to write your code as a text string?

  a, err := f()
  if err != nil {
      return
  } 
  a, err = f()

This will compile.

What's the tradeoff? what advantage having null pointers give?

> Go’s error handling is more verbose than those other languages, but structurally, there’s a lot of commonality under the surface.

In Go the type system doesn't force you to check for errors, the same way as languages with null pointers don't force you to check pointers before dereferencing them.

That's the real problem with errors and null in Go, not the verbosity (though that doesn't help)

By that logic Python is a systems programming language because MicroPython exists.

Just because you can provide some niche examples where Go is used as a systems programming language doesn't mean it is a general purpose systems programming language.

Putting Go in the same category as C/C++/Rust/Zig is ridiculous.

KVM is a type-1 hypervisor [1]

[1]: https://www.redhat.com/en/topics/virtualization/what-is-KVM

There are a bunch of typos and missing generics all over the place, looks like something there doesn't like angle brackets.

This has nothing to do with safety, just correctness.

> And turning warnings into errors just encourages people to write 'let _ = ...' to get rid of the error.

No? writing `let _ = make_future()` will clearly not await the future, why would you do it instead of just adding `.await` ?

Using `let _ = ...` is sometimes fine for Result if you really sure you don't care about the potential error you got but it's a no go with futures.

Futures in Rust are annotated with the #[must_use] attribute [1], same as the Result type [2].

This means the compiler will emit a warning (can be upgraded to an error) if you forget to await a future even if it doesn't return anything.

[1]: https://doc.rust-lang.org/nightly/src/core/future/future.rs.... [2]: https://doc.rust-lang.org/nightly/src/core/result.rs.html#49...

You can achieve the same thing in Rust or any other language that offers some sort of field privacy (which Zig doesn't btw) by wrapping the hash map with your own type and exposing the interface you want.

Who uses bun in production?

Seems totally insane to me to use a pre-1.0 application written in a pre-1.0 language in production considering Node and Deno basically do the same thing.

According to the docs[0] you can't declare a go version in the main module or workspace that is lower then the go version of one of your dependencies.

  A module’s go line must declare a version greater than or equal to the go version declared by each of the 
  modules listed in require statements. A workspace’s go line must declare a version greater than or equal 
  to the go version declared by each of the modules listed in use statements.
  
  For example, if module M requires a dependency D with a go.mod that declares go 1.22.0, then M’s go.mod 
  cannot say go 1.21.3.

so the "go" directive is like "rust-version" in Cargo.toml and the "toolchain" directive is like the rust version in a rust-toolchain file.

[0]: https://tip.golang.org/doc/toolchain

It is different.

The rustup toolchain toml file is under your control, dependencies have no affect on it.

This Go feature is like the rust-version key in Cargo.toml where if a dependency specifies in it's own Cargo.toml file that it needs a rust version higher than you what you have you will get an error and your code won't compile (there is no option to auto upgrade the toolchain in rust).

Yes, in some compilation modes, but those benchmarks were compiled in "ReleaseFast" mode which disables all safety checks.

This entire argument is dumb.

No one is using a Vec<T> with indexes for long term storage if you know you will remove and replace items there, it's obvious regardless of programming language that it's a bad idea.

You use a dedicated data structure for this where the keys have a generation and that solves the ABA problem.

Rust has multiple crates that provide such data structures.

> Zig’s requirement of explicitly passing around an Allocator type removes any ambiguity completely.

Not really...

    var list = std.ArrayList(u21).init(std.testing.allocator);
    try list.append('a');

Does creating the ArrayList allocate memory? Is appending to the array list reallocates? The only thing you know is that ArrayList will sometime use the allocator, you can't tell when. And this gets worse once the abstraction level increases, if you have your own type which accepts an allocator and has 100 methods it's impossible to tell which methods allocate.

In both languages you still need to know the specifics of the data structures you are working with, the only real problem that Zig solves is to actually allow you to use custom allocators with the std collections, which is something that is still unstable in Rust.

Gatekeeping people from publishing crates behind owning a domain will never work in the Rust ecosystem.

> "integer math is allowed to panic on overflow"

This is configurable, by default with optimizations on math overflow doesn't panic in rust, it wraps around.

Obviously the kernel won't enable panics here unless in debug mode.

absence of UB is literally memory safety.

Rust proponents mean exactly "memory safety" when they say rust is safe because that is the only safety rust guarantees.

> EXCEPTION_ACCESS_VIOLATION is well-defined & memory safe. That's just a crash, same thing that happens when Helix crashes because it called .unwrap() on an error.

Just because both of those things cause a crash doesn't mean they are the same.

Crashing due to an incorrect .unwrap() is a bug in the business logic of the application, the developer made a wrong assumption.

EXCEPTION_ACCESS_VIOLATION is a crash due to a memory issue that a memory safe language would have prevented.

> It's correctness that affects the user experience, not memory safety.

Memory safety is part of correctness, your program can't be correct if it crashes with EXCEPTION_ACCESS_VIOLATION.

> let b:&str = &"str";

This has nothing to do with DST but with type coercion.

The type of `b` is `&&str` but you requested the type to be `&str` which is fine as the compiler can coerce from `&&str` to `&str` in this case.

In the same way you can write

  let b: &i32 = &&&&1;

and it will compile fine

stackful coroutines break FFI

If you are holding indexes to a collection and plan to delete elements you will never use Vec.

There are dedicated data structures for this [1] that will not let you access another item by mistake.

[1] https://crates.io/crates/slotmap

This looks like a bug to me, the fact that Arc is thread safe shouldn't matter with the removing the allocation here.

I opened a bug about this on the rust repo. [1]

[1] https://github.com/rust-lang/rust/issues/97751

They maybe rear their ugly head but they also allow you to collect the iterator into any collection written by you, by the standard library or by any other crate.

While in python you have list/dict/set/generator comprehension and that's it.