[bborud]

It is a suprisingly hard thing to implement well. I have no idea how many times I have implemented slice-like things in C (back in the 1990-2000s when I mostly wrote C) and it was one of those things I never managed to be happy with.

[pjmlp]

Something that even Mesa and Modula-2 already supported by 1980's, maybe one day C will eventually get proper slices.

[baranul]

Good point. As for C and slices, doubt that many care, at this point. Many will use C alternatives that have slices or are long time C users that just deal with it.

[neonsunset]

It can be done but that requires a better, more expressive type system.

[rednafi]

An expressive type system also often means slower build times. I dislike working with Rust for this exact reason.

While most people highlight the difficulty of picking up the syntax, I find Rust to be an incredibly tedious language overall. Zig has a less expressive type system, but it compiles much faster (though not as fast as Go). I like what Zig and Odin folks are doing over there.

I like the balance Go strikes between developer productivity and power, though I dearly miss union types in Go.

[4ad]

An expressive type system absolutely, positively, unequivocally does not imply slower build times (especially with a Church-style type system). There are plenty of programming languages with advanced type systems which compile extremely quickly, even faster than Go, for example OCaml.

Don't make the fallacy of conflating Rust's slow compile time with its "advanced" (not really, it's 80's tech) type system. Rust compilation is slow for unrelated reasons.

[taurknaut]

Old doesn't mean non-advanced. GraalVM is based on a paper (Futamura) from fifty years ago. Off the top of my head I can't think of many language features younger than the eighties—maybe green threading? That would be surprising but might fit. I suppose you could also say gradual typing. Haskell has many recent innovations, of course, but very few of those have seen much use elsewhere. Scala has its implicits, I guess, that's another one.

Personally, I write java at my day job and the type system there makes me loooong for rust.

[pjmlp]

No need for Rust, when JVM has Haskell, Scala, Kotlin, Clojure, Common Lisp.

[taurknaut]

I prefer rust to all of them, but I also come from a very systemsy background. Plus it has the benefit of being much easier to embed inside or compose around basically any runtime you'd like than managed code, which is why I chose rust rather than basically any managed language.

But, it's just a tool, and the tools I choose reflect the type of stuff I want to build. The JVM is extremely impressive in its own right. You're just not going to to find any one runtime or ecosystem that hits every niche. I'm happy to leave the language favoritism to the junior devs—for the vast majority of situations, what you're building dictates which language makes the most sense, not vice versa.

[neonsunset]

As a start, Go could separate container and slice types, the way C# did it with T[]/List<T>/other and Span<T>/Memory<T>. No lengthy build process required.

[jerf]

I'm not deeply familiar with those C# types, but I think maybe it already does. An array, which includes the size of itself in its type so that a four-element array is not the same type as an eight-element array, is already in Go. Go's language affordances make it easy to just have slices without the underlying arrays, since they're generally not useful on their own, but you can take arrays and slice into them if you like.

[rednafi]

Yeah, but the at the same time, I find C# code a sigil soup. Go makes a different tradeoff.

I've been involved in a few successful large scale projects and never felt like the type system of Go is holding me back too much. Sure the error handling could be better, union type would make interface munging easier, but the current state after generics isn't too bad.

[neonsunset]

> Sigil soup

Last time I checked, C# had clean and focused syntax for working with collection types. Could you provide an example?

[thegeekpirate]

You'd most likely be happy with Odin (https://odin-lang.org), which I find to be essentially a fixed Go with no GC.

[dist1ll]

It's possible to build languages that compile faster than Go, with a much more expressive type system.

It's just that compile times and DevEx haven't been a priority for most projects.

[pjmlp]

As proven by other languages with similar type systems and faster compile times, Rust's case is a matter of tooling, not language features.

[_flux]

Not sure if that's really a proof, as it could be the exact combination of language features that makes up the slowness. For example traits, non-ordered definitions in compilation units and monomorphization probably don't help. GHC also isn't a speed demon for compilation.

But sure, LLVM and interfacing with it is quite possibly a big contributor to it.

[pjmlp]

Haskell isn't the only language around with complex type systems.

However, it is actually a good example regarding tooling, as the Haskell ecosystem has interpreters and REPL environments available, for quick development and prototyping, something that is yet to be common among Rustaceans.

[neonsunset]

Rust has Cranelift: https://cranelift.dev

[burnished]

Based on a first hand account I read (but cannot source offhand) Rust's slow compiles are because anytime there was a tradeoff involving compile time at the expense of something else they'd always choose that something else. Not cause they hated fast compilation, guess it just wasn't high on their priorities.