It's important to note that Go and C have very different design goals from Rust. Go was never designed to have zero-cost abstractions (garbage collection being the most obvious outcome of this, but there are many others), and it has a runtime. C was never designed for safety and security, memory safety or otherwise. In short, Go sacrifices performance and C sacrifices safety, while Rust's goal is to sacrifice neither.

Addressing the learning curve of Rust is important, but we aren't going to be able to do it by adopting concepts from Go or C. By and large, they just don't apply.

What are your thought on making `rustc` poly-lingual?

Ideally, all libraries (i.e. should be written by experts) are written in Rust, but applications are allowed to be written in RustScript.

RustScript would be optimized for lower learning curve. example[0]: - No `unsafe` allowed. - Everything is implicitly an `Arc<_>`. - All numerics are BigNum. - etc.

This is inspired by the popularity of using Rust within other languages, like Ruby. The way this would differ from using another language: All the Rust tooling would be the same. Realistically it would just be a different parser for the Rust AST. Therefore no memory layout issues, or FFI involved. Like syntax-sugar to the extreme, the compiler (except the parser) wouldn't even know the difference.

[0] I'm just listing simplifications, regardless of if they are a good idea.

So I'm actually a big fan of writing apps in multiple languages, and I wholeheartedly support writing apps in higher-level languages that incorporate low-level components written in Rust. (This is, in fact, what Servo-based Web apps are!)

But I'm not sure I agree that there would be benefits in introducing a new language as opposed to just using an existing one. I think a Rust that used automatic memory management would effectively be a new language. There would be all the costs that come with introducing a new language: new tooling (even if based on Rust tooling, it'd have to be heavily modified), bootstrapping an ecosystem and community, and so forth. While making new languages is awesome, we have our hands full with the one we have :)

There are a few Rust hosted dynamic languages already, see: https://github.com/ruse-lang/langs-in-rust

Dyon in particular sounds interesting for realtime apps as it uses a lifetime checker instead of GC.

not the OP, but i strongly disagree. you don't need to be an expert to write rust. Many of it's features are in a huge amount of other languages; parametric polymorphism, ad hoc polymorphism, type inference, etc. there's nothing new and groundbreaking besides ownership and lifetimes, from a language syntax perspective. it really just takes a little bit to get used to ownership and you're off to the races. the compiler helps you out in a big way with writing correct programs.

i also feel fracturing the community would be terrible. i came from basically a dynamic programming background (had done java and c++ in soft. eng. in school and that's it) and I had no problem learning rust.

https://github.com/jonathandturner/rhai ?

It doesn't do exactly this, but it's similar I think.

It's also important to note that Go was designed for programmer productivity and Rust wasn't.

GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management.

Compile times in Go are a fraction of Rust compile times, which is another productivity boost.

Go gives you one good way to do concurrency, Rust believes in tyranny of choice.

Without mentioning that you don't paint the whole picture, just the parts that are favorable to Rust.

> It's also important to note that Go was designed for programmer productivity and Rust wasn't.

Rust was absolutely designed for programmer productivity. Source: I was one of the designers.

> GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management.

That's true, it is a productivity boost. But it also has a cost. Rust didn't want to pay that cost, especially when the same mechanisms are useful for preventing data races. (In fact, removal of GC was something that happened as a consequence of the data race freedom features; it wasn't a design goal from the beginning.)

> Compile times in Go are a fraction of Rust compile times, which is another productivity boost.

And rustc performs much more optimization. Again, a tradeoff.

> Go gives you one good way to do concurrency, Rust believes in tyranny of choice.

That's untrue. Go has threads, channels, mutexes, condition variables, and atomics. Rust has threads, channels, mutexes, condition variables, and atomics. The only thing I can think of that Rust has that Go doesn't is, like, SIMD, and I'm sure your comment wasn't just referring to SIMD.

> The only thing I can think of that Rust has that Go doesn't is, like, SIMD, and I'm sure your comment wasn't just referring to SIMD.

Just to clarify, are you referring to Rust using SIMD by way of LLVM, or by way of being able to use SIMD primitives / intrinsics directly in Rust code?

The former works much better than I had anticipated. I've been surprised by the extent that my iterator code ends up vectorized without me doing much work.

The latter does not give me warm Rust feelings today. There's a SIMD crate, but it doesn't look maintained and only works with the nightly compiler releases. I didn't think there was any stable way to do inline assembly, so I think linking C is my best bet here?

> The latter does not give me warm Rust feelings today. There's a SIMD crate, but it doesn't look maintained and only works with the nightly compiler releases. I didn't think there was any stable way to do inline assembly, so I think linking C is my best bet here?

Yeah, the person formerly working on simd is no longer able to contribute to random open source projects. It's still something the Rust team wants to make stable, just not right now. SIMD is a bit complicated because you need to address target support in a straightforward way.

> Rust was absolutely designed for programmer productivity. Source: I was one of the designers.

If you mean productivity as "memory safe and no null pointer errors" then Yes, Rust is productive compared to C,C++ or even Go. If you mean productivity as "ease of use" then no, Rust is not easy to learn or to use compared to Go.

I agree with some of your points, but think this is phrased a bit harsh. FWIW, I write both Go and Rust on a regular basis.

Here's where I would agree with you:

- Go makes it harder for someone to write overly abstract code (a common affliction!).

- Being able to occasionally do type assertions in an ergonomic way is surprisingly nice.

- I wish Rust had something in the stdlib like net/http.

- I like that go fmt is so unconfigurable and canonical.

Here's where I would disagree:

- I find ADTs (Rust's enums) super helpful for productivity.

- Removing nil pointer derefs is wonderful, particularly for refactoring.

- I spend too much time in Go rewriting bits of code that I would just use generics for in Rust or C++. Rust's iterators are wonderful and I end up using them over and over again.

- Maybe it's my C background, but I like being able to occasionally use macros. Even for tests it makes things much more readable.

- The borrow checker ends up moving many concurrency issues from runtime debugging to compile time debugging.

- I think cargo is more pleasant to use to manage code than using go + godeps/glide/etc.

I forgot to add - I partially agree with you about the productivity of GC. For non-performance sensitive code, GC simplifies a lot. Otherwise, I find Go much nicer to reason about than Java since it has real arrays (value types!).

But I find it a mixed bag of whether the naive Go version of something that shares memory by GC is simpler than the naive Rust version of something that shares memory. Sometimes ref-counting (Rc<T> in Rust) is fine, although that's more expensive than GC. Sometimes Rust's ownership model nudges you to make the code much simpler and makes it clear that something only has a single writer. Sometimes you wish you were in C and just did it yourself...

> Sometimes ref-counting (Rc<T> in Rust) is fine, although that's more expensive than GC.

To nitpick: The jury's still out on that one, because Rc in Rust isn't thread-safe reference counting. I believe that non-thread-safe reference counting is quite competitive with global, cross-thread tracing GC.

When people (rightly) talk about how much slower reference counting is than tracing GC, they're almost always talking about either thread-safe tracing GC vs. thread-safe reference counting or single-threaded tracing GC vs. single-threaded reference counting. When you compare Rc to a typical multithreaded GC'd language, you're comparing multithreaded tracing GC to single-threaded reference counting, which is a much more interesting comparison.

> When people (rightly) talk about how much slower reference counting is than tracing GC, they're almost always talking about either thread-safe tracing GC vs. thread-safe reference counting or single-threaded tracing GC vs. single-threaded reference counting.

Reference counting has always been slower, even in single-threaded cases. This should be obvious because pure reference counting requires modifying counts whenever locals are assigned, which happen orders of magnitude more often than main memory updates, and now each local assignment requires touching main memory too.

As soon as you defer these updates somehow to recover that cost, you've introduced partial tracing. You can find papers from way back acknowledging this overhead, and suggesting optimizations [1].

[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.9...

> This should be obvious because pure reference counting requires modifying counts whenever locals are assigned, which happen orders of magnitude more often than main memory updates, and now each local assignment requires touching main memory too.

I guess so, but it's worth noting that this isn't the case in Rust, because Rc benefits from move semantics. Most assignments don't touch the reference counts at all.

Right, Rust's borrowing is like the optimization link I provided, just slightly less general IIRC.

Yes, this is a great point! I was a bit sloppy in my wording above.

> Sometimes ref-counting (Rc<T> in Rust) is fine, although that's more expensive than GC.

This is a very interesting and hard comparison to make.

The marginal cost of GCing one more thing is much less than the marginal cost of RCing one more thing. But you need to pay the cost of the GC runtime to get there, and Rust doesn't, so it's a rather hard comparison to make.

However, the cost of RCing something itself is pretty small (and you don't RC very often in Rust anyway), so this rarely matters :)

As a long-time C++ developer I find I can be very productive writing Rust. Many modern C++ idioms translate almost directly to out-of-the-box Rust-isms. Some (including some important ones) don't, but these are relatively easy to understand and work with.

Compile times are actually not that bad. I've seen some real doozies in my day, and plenty of hacks to overcome C++ compile times (distributed compiling, pre-compile steps to collect many dozens or more source files into a single TU, etc.). Rust is just fine. Besides, for the kinds of programs Rust is targeting being productive isn't synonymous with belting out as much code as fast as one can.

As for concurrency, I think having options is great. There is rarely a one size fits all solution for concurrency and having choice mirrors real use cases very nicely.

Furthermore I really enjoy generic programming. One of the worst parts of C is the lack of real generics. It gets tiresome writing the same array, hashtable, etc. code for each different type. Hiding it behind macros is terrible. It's one of many things that make both C++ and Rust superior to Go, in my view.

That said, I do perceive a certain "feature my preferred language offers is the most important thing ever" myopia about some aspects of the Rust community. It's similar to a certain segment of the C++ community zealously beating the drum of "performance, performance performance" to the exclusion of other important things. Rust hasn't the popularity or use in the wild for its warts to be exposed yet, but time will tell. Every language has flaws and proper (and improper) uses.

I would offer a counterpoint -- Rust's guarantees and strong typing offer a different kind of productivity to an intermediate or experienced user. One where a compiled program is much more likely to be "correct" than in any other mainstream-esque language I've used. The properties which combine to create this effect make refactoring much less scary, allow easier navigation in large codebases (IMO), and allow for other valuable properties for productivity.

This is why I think there's room for another bigtime language that hits the rust sweet spot of functional-flavored imperative programming with a GC.

GC for in-memory data structures, RAII and lifetimes for system resources, ML-style type and module systems. That would be very close to the ideal language IMO.

The key problem: in-memory data structures can embed ownership of system resources.

I'd take an approach inspired by Standard ML's eqtypes. In Standard ML:

(0) Some types are eqtypes (akin to Rust types that implement the Eq trait, but managed entirely by the language, you can't define custom Eq impls).

(1) If a type constructor is an eqtype, then the result of applying it to an eqtype is an eqtype, but the result of applying it to a non-eqtype is a non-eqtype. For example, “list of ints” is an eqtype, but “list of functions” isn't.

Similarly, I propose that:

(0) Some types are copytypes (akin to Rust types that implement the Copy trait, again, managed entirely by the language).

(1) If a type constructor is a copytype, the result of applying it to a copytype is a copytype, but the result of applying it to a non-copytype is a non-copytype. For example, “list of ints” is a copytype, but “list of file objects” isn't.

Subtleties:

(0) If we have first-class functions, functions must be parameterized over whether they can be called more than once (akin to the distinction between FnOnce and Fn in Rust).

(1) When a value goes out of scope, its destructor is called. For copytypes, the destructor is guaranteed to be trivial, and can be optimized away. For “base non-copytypes” (e.g., file objects), the destructor is explicitly implemented by the programmer. For “derived non-copytypes” (e.g., lists of file objects, closures that have captured file objects), the destructor is automatically generated, and it does the obvious thing (destroy all file objects in the list, or captured by the closure).

FWIW, Copy already behaves like that in Rust: a "custom" Copy impl is just opting in to the default copy implementation, there's no way for the programmer to inject any code.

The reason the impl is required is to ensure people write what they mean: it is backwards incompatible to go from Copy to non-Copy, so it would be unfortunate for a type to accidentally be Copy because an early version of the type happened to only contain Copy types. (The trait is really just a marker for "this type can be safely duplicated with memcpy".)

The Send and Sync traits are similar, and are in fact almost identical to eqtypes in that an explicit implementation is not required.

> Copy already behaves like that in Rust: a "custom" Copy impl is just opting in to the default copy implementation

Yeah, I realized that, then deleted that part of my post.

> The reason the impl is required is to ensure people write what they mean: it is backwards incompatible to go from Copy to non-Copy, so it would be unfortunate for a type to accidentally be Copy because an early version of the type happened to only contain Copy types.

In my proposal, with an ML-style module system, you can define an abstract non-copytype whose internal representation is a copytype, just like in Standard ML you can define an abstract non-eqtype whose internal representation is an eqtype.

If you want a modern language with (optional) GC, with seemless FFI to C, and with almost C performance then you should take a closer look at Nim. Rust can learn a lot from Nim regarding productivity.

http://nim-lang.org

Arguably, programmer productivity is one consequence of safety (and productivity isn't necessarily only gained by increased safety either of course!).

Are there different productivity levels between Go and Rust? Probably. But to say Rust wasn't "designed for programmer productivity" definitely isn't right from where I'm standing.

Honestly, the more you program in rust, the more you get used to its mannerisms. I don't at this point find that I'm less productive in it than in Go, and with gennerics I'm generally able to reuse code more often meaning that I usually write less code. Similarly in C I lose time on screwing up basic things that I have to debug in testing, whereas in Rust I don't have to even worry about that.

I'm actually not buying the productivity argument, after you've learned the language. Claiming that it is less productive when you barely know it isn't fair, it's similar to saying that Italian (as an English speaker) is much more complex and hard to communicate in than English, when you've only studied the language for a month.

It does have a steep learning curve, so it's either worth it to you to learn it, or not. But once you know it, I think your overall productivity is higher or the same as other languages, and on top of that you end up with fewer production issues!

I'd say my experience matches this. I've written well over 50 KLOC of both Go and Rust in the last few years (I love both), and I don't personally experience a big productivity difference between them. There is one dimension where I feel like Rust makes me more productive though: when writing code that I want to go as fast as possible.

I bet there are things that would be more productive in Go, maybe building web applications, but I haven't built any in Rust yet, so it's hard to compare.

As a reference point, I feel much more productive in Rust/Go than I do in any unityped language. I suspect the same is true of C, but I've never been a heavy C practitioner.

I'll stop here though, because this is all pretty subjective and wishy washy, and it will undoubtedly vary from person to person and be dependent on what kinds of problems you're solving most frequently.

    Claiming that it is less productive when you barely know it isn't fair...

I'm really quite familiar with both go and rust, and I can say straight out that go is more productive than rust.

...but because rust is in any way a worse or less productive language (that remains to be seen), but because it has an immature ecosystem with few high quality crates and virtually no tooling.

Go has a lot of very polished tooling (eg. gocode) that is supported in multiple editors, and a variety of high level packages for all kinds of things.

Certainly I'm willing to acknowledge that if you're using vim without any plugins to write your code, or if you're evaluating the effectiveness of writing individual functions, it's a much more abstract kind of thing.

...but have you actually bench marked yourself coding a real world project, from scratch, in both, from idea to delivery? I have, and for me rust was an order of magnitude less productive than go. At least.

Once the tooling for rust gets up and going we'll be a much better position, but...

You're effectively saying that there is zero productivity boost in the extensive go tooling ecosystem (which rust currently doesn't have); that's pretty hard sell...

> Go has a lot of very polished tooling (eg. gocode) that is supported in multiple editors

Have you tried racer? It seems quite similar, and apparently it does more (see [1]).

I mean, I agree in the abstract that yes, having tooling and a bigger library ecosystem matters a lot. But the things you've cited so far (code completion and an AWS library) are things that Rust does have. I'd be more interested in hearing specific problems with those.

[1]: https://github.com/nsf/gocode/issues/307#issuecomment-155080...

     It seems quite similar, and *apparently it does more*

Have you tried the go-plus (https://atom.io/packages/go-plus) tooling?

Really, please try it out. That's the kind of experience that's really missing from rust; autocomplete, fmt, test watcher, linter, code coverage, debugger, doc summary; you hit install and it works.

Racer isn't there yet.

> You're effectively saying that there is zero productivity boost in the extensive go tooling ecosystem (which rust currently doesn't have); that's pretty hard sell...

You could say something like "you're effectively saying that there is zero productivity drain from not having features like generics (which Rust currently does have); that's a pretty hard sell...

Tooling matters a lot, and that's why we're investing in it. But "tooling" is not a synonym for "productivity." There's a lot of factors.

You'd have a much easier time arguing that go not having a package manager makes you less productive compared to cargo (very true); you're kidding yourself if you think having generics makes up for having to write your own AWS client in terms of productivity.

Can you build something more quickly in go right now, than in rust?

For many applications, the answer is, right now: Yes.

Building (using the tooling that does exist, and the libraries that do exist) make completing a project successfully easier and quicker than in rust.

Does that make go 'more productive' than rust?

Or is 'productivity' just how effective you are at expressing logic as code?

Well, I guess it depends what word games you want to play.

My personal experience has been that using rust is great, fun (if verbose) and you can spend 5 or 6 hours writing a nice crate that doesn't do anything meaningful; and when you do have to do something meaningful, its a tonne of work to get it to compile (ugh, c libraries...) and you end up having to write or modify/fix the packages to do many of the things yourself.

That is not productive.

Perhaps you see a different side to it from where you sit, but I do think #rust suffers from a certain degree of confirmation bias.

I think 'productivity' depends on your problem domain.

For building actual applications rust simply isnt even in the same space as java, c++, c# or go at this point in terms of 'productivity'.

> you're kidding yourself if you think having generics makes up for having to write your own AWS client in terms of productivity.

It doesn't appear you need to write your own AWS client - or at least, not from scratch: https://github.com/rusoto/rusoto

> Perhaps you see a different side to it from where you sit, but I do think #rust suffers from a certain degree of confirmation bias.

From the outsider perspective of one who knows neither Go nor Rust well - Rust seems to acknowledge it has problems and gaps they're working on. Poor IDE support is one close to my heart. Compile times are another. Heck, I'm just rehashing the roadmap, aren't I.

With Go I hear more about how they've intentionally avoided things in the name of simplicity, and having some opinionated stance on having one correct way to do things. I get the impression that Go will never have generics, by design. C# already covers most of the things I'd use Go for pretty well - I don't see much advantage to switching to Go.

Rust, even in it's relatively untooled state, already has me seriously considering trying my hand at nontrivial projects in it. I've been chasing static analysis and appropriate annotations to catch threading bugs, data races, iterator invalidation, potential null derefs, etc. in C++ for some time, to great effect - and who knows how much time saved - in bugs avoided. I'm convinced it's a question of when, not if, I'll try switching over properly.

I'm arguing _against_ any one feature; I picked generics because it's the classic criticism of Go. I do think that package management might be a bigger factor, but my point is that there are multiple factors. You can't say "well Rust doesn't have tooling, so it's not productive."

I think we're mostly in agreement here, other than that I think your first post put too much weight on one specific part of a complex equation, and that you feel there's a clear-cut answer, and I don't.

(I do agree that "there's a package for this" vs "there isn't" is a huge factor of productivity. It's actually the one I personally cite most often when talking about my own productivity in Rust.)

No sure why you were down-voted, but it probably has something to do with connotation. I agree though -- library maturity, tooling maturity are also very important factors when it comes to productivity. A steep learning curve, however, probably has less to do with productivity and more to do with adoption, which I think is what the parent was trying to get across.

But, of course, adoption rate can indirectly impact library and tooling maturity. :)

> GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management.

Swift is a recent high-level productive language without a GC.

Swift still has automatic memory management. It may not have a tracing GC, buy that's not super relevant from an ergonomics perspective (except that potential cycles require extra work/annotations).

If syntax isn't going to be changed, is that really addressing the learning curve of the language?

Edit: I'm going to answer my own question here: yes. I just sometimes think Rust is a victim of its own success when people expect to learn Rust quickly because they learned Python in two days.

No one expects to master C++ in a weekend.

Go outperforms rust on all kinds of benchmarks, has a larger community, better documentation, more third party libraries, and significantly better tooling.

What's the value proposition for using rust over go?

Where are these benchmarks showing Go outperforming Rust? I've only seen the opposite with Rust convincingly out performing Go, it would also have more predictable performance thanks to the lack of a GC.

At a language-level Rust has generics, a better Type system and is better suited to functional programming.

Seems Systems-level programming, High-performance computing and resource-constrained embedded devices are areas where Rust would shine over Go.

Source?

First Google result for "Rust vs Go speed": https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

Rust seems to perform significantly better on some workloads while Go outperforms it marginally in other ones (except reverse-complement where Go is almost 50% faster than Rust).

Edit: As for the other points you make – they are often subjective and I've read the opposite to your statement at least as often.

The ones where Go outperforms us currently are the ones with heavy SIMD use; explicit SIMD is still unstable in Rust, so you're at the whims of LLVM generating it. We'll get there...

Do those Go programs use explicit SIMD ?

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

I assume that they're better about generating it implicitly. That is, it's about why Rust is slow, not about why Go is fast.

I don't think Go emits SIMD at all. Their assembler doesn't even support parsing it.

I think these are probably just bugs that we need to look at. The benchmarks where we do worse are the string benchmarks; perhaps it's our Unicode correctness that is hurting us, or something like that.

It definitely does: https://github.com/golang/go/blob/b851ded09a300033849b60ab47...

I should look into those benchmarks if you think there might be string problems. To be frank, I've never looked too closely at anything except for regex-dna.

Oh, interesting. I was inferring that from the Go code out there that uses machine code directly: https://github.com/minio/blake2b-simd/blob/master/compressAv...

I guess it must be a recent addition.

I think it was recent, yeah. I also recall there being problems with their assembler not being able to parse various SIMD instructions in the past. I also recall seeing code like in your link too.

Hmm, Go 1.7 introduced support[1] for various AVX instructions (plus at least one SSE 4.2 instruction), some of which are used in blake2b-simd.

I can't wait to get SIMD on Rust stable. It's going to be exciting.

[1] - https://golang.org/doc/go1.7#tools

Oh, by the way, if you want to investigate the string benchmarks, that would be really awesome--I'm curious to know what's going on there :)

> about why Rust is slow

If the Go programs don't use explicit SIMD, then "explicit SIMD is still unstable in Rust" does not explain the difference.

> What's the value proposition for using rust over go?

Productivity features like generics, a more mature optimization pipeline, freestanding (runtime-less use), highly optimized libraries like serialization frameworks and regular expressions, etc. etc.

The hard part doesn't go away with unless you pull in a GC or something similar to take care of lifetime bugs. In Go you always use a GC and circumvent the explicit lifetime management syntax of Rust. Some data structures are very hard to write without something akin to a GC, so my bets are on a few opcodes trickling down into mainstream cpus making GC easier to implement in optimal time and space. I'm surprised Android hasn't forced anything like that in their supported ARM designs, since such cpu support has been available in production systems in the 1970s and hence isn't anything revolutionary, just not on the radar like vector instructions have been.

Is this based on your experience learning lifetimes in Rust? I very rarely find myself needing to do convoluted lifetime tricks -- most of the code I write doesn't even need explicit annotations. So I'd be curious to hear what project you may have worked on as a beginner where lifetime management because a serious obstacle.

I'm not talking about Rust lifetimes but lifetimes as a common term used in many languages. What I mean is that in Rust you're forced to explicitly deal with the lifetime aspects of variables before the compiler will generate any code. In C and C++ you're free to skip that and introduce leaks or use after free bugs, which are accepted by the compiler due to the language definitions. I didn't mean to say it's more difficult. In fact, it's less work to deal with these issues in Rust before the code gets generated rather than debugging mysterious bugs. Put differently, you're debugging your code while trying to compile it instead of debugging it after hopefully someone was able to trigger it and provide enough clues for you to identify the issue.

Could you provide references for the claim that hardware support for GCs had been in CPUs for decades?

Burroughs line of machines and Intel iAPX 432 and it's derivative i960 (which is actually in use). The project for which the Intel CPU was designed together with Siemens would have given us a safer foundation due to using this processor in an Ada based operating system in the 1980s. But then UNIX won and gave us the hegemony of C and all the avoidable security bugs associated with it. Lisp machines had similar designs. These days there are RISC-V designs that have similar features. Just like DJB has been wishing for a few extra arithmetic instructions for crypto in x86 processors, I wish for instructions that would make garbage collectors more efficient and also provide support for memory safety features.

https://en.wikipedia.org/wiki/Intel_iAPX_432

https://en.wikipedia.org/wiki/Intel_i960

https://en.wikipedia.org/wiki/Burroughs_large_systems#Tagged...

http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...

I'm sure there were similar design in the 1990s, but I don't have references ready off the top of my head like the above.

Thanks. I will definitely look into these when I have the time. I'm actually a grad student in EE but this topic interests me. Maybe I can get something published on hardware accelerated GCs... one day!

Genuinely curious, do they not teach historic designs in EE course plans? To learn from and improve, but not reinvent something half-way or worse. Also, older designs are much easier to study completely compared to the super complex logic inside your current day x86.

Personally, I would call it hardware-assisted gc if we consider hardware acceleration to be things like GPUs, crypto accelerators, etc.

An undergrad computer architecture course would typically gloss over the history of CPUs and focus either on MIPS or x86 (or both). For example, I did two courses on x86, starting from 8086 (and 8088), through Pentium, and some bits of Itanium.

You're right that starting with a simple architecture makes things much easier. 8086 for example operated in 16-bit real mode (segmented memory), and so the memory layout was trivial compared to 32-bit protected mode in x86.

I haven't taken any graduate architecture courses yet, but my assumption that they would go into more detail on the development of CPUs through history.