Hacker News Reader

Comment by webkike | Hacker News Reader

It's definitely simpler than most other systems languages in what it gives you access too. Go, D, C++, C# are all far more complicated than Rust is. I would argue Modula-3 is not as simple because it contains a garbage collector - thus making the connection between written and compiled code less simple. Don't know much about pre scheme

View on HN

Go, at least, is far simpler as a language than Rust, and the implementation (compiler) is less complex overall, especially if you count LLVM on Rust's side. I suppose that Go programs exhibit more complex behavior at runtime due to the GC and green threads and stuff, but it's a huge stretch to call Go more complicated overall.

On the other hand, I'd argue that Rust makes up for the complexity with performance, power (ability to express more complex programs in less code), and safety (not just memory safety, which Go also mostly guarantees, but the ability to leverage the type checker to verify code correctness in general). C++, on the other hand, is more complex (due to all the legacy drift), yet equal in performance, less safe, and less powerful in most respects (there are some things C++ can do that Rust can't, but more things for which the opposite applies).

Consider how interfaces work and how you would have to implement them. Rust may have a more complicated type system and I suppose enums are more complicated in Rust, but the things I value as simple are more simple in Rust than Go.

What about interfaces? The basic idea of fat pointers with vtables works the same as Rust's trait objects. If you mean the ability to dynamically cast from one interface type to another, which Rust doesn't support - that does require a global list of implemented interfaces per type, but without generics that's not too hard to implement. (In Rust, it would be drastically more complex, verging on impossible to pull off with a good UX, due to various language features including wildcard impls, type-parameterized traits, and a Turing-complete type system.)

When ever you would need to box a trait object in Rust Go automatically performs a heap allocation that is garbaged collected at some point. A bit more is explained here https://research.swtch.com/interfaces Basically there are some property of Go interfaces that make them far more dynamic than traits and implementations in Rust.

> (In Rust, it would be drastically more complex, verging on impossible to pull off with a good UX, due to various language features including wildcard impls, type-parameterized traits, and a Turing-complete type system.)

Swift can downcast, and it has generic extensions and generic protocols. I highly suspect it has a Turing-complete type system as well.

Supporting this requires heroic effort in the compiler, but it can be done.

> I suppose that Go programs exhibit more complex behavior at runtime due to the GC and green threads and stuff

Given the GP's note about the connection between written and compiled code and how a GC affects that, I think this is exactly what is being referred to. I.e. a GC makes everything much simpler up until it doesn't, and then it makes it much more complicated. That point may never be reached in many programs, but it may be hard in some cases to tell whether it's something you have to worry about at all.

> GC makes everything much simpler up until it doesn't, and then it makes it much more complicated

I would say that's true in general, but in Go there's a lot more room to ask the GC to get out of your way if you need that than most.

How is Rust simpler? In terms of cognitive complexity on the part of the user, Modula-3 is much simpler; it is easier for a programmer to learn to write new Modula-3 code and correctly read Modula-3 code than it is for Rust code.

In terms of implementation complexity, Modula-3 is also much simpler, despite the existence of a GC. A Modula-3 spec would be a great deal smaller than an equivalently detailed Rust spec. Many people have independently implemented Modula-3, whereas an independent implementation of Rust is effectively impossible, due to all of the unspecified implementation-defined behaviors. If you told me I had 1 year to implement either language from scratch, I would much rather choose Modula-3.

There are two alternative implementations of Rust in the works; one is _almost_ able to compile rustc at this point.

What are these implementations? The one I immediately found by searching (https://github.com/thepowersgang/mrustc) is accompanied by an explicit nongoal to correctly implement the language. It also doesn't seem particularly independent from rustc, given the similarities in implementation strategy and the fact that some parts look like rustc code converted to C++.

Mrustc is one; my understanding is that it isn't yet, because its purpose in life is to make bootstrapping/ddc stuff easier. Once that works, I thought it intended to add the stuff that's missing.

There's another that's not public.

> ddc stuff

Note: this refers to "Diverse Double Compilation", which is a mitigation tactic against Reflections-on-Trusting-Trust attacks.

I suggest you email the team that did the C formal semantics about doing one for Rust. They did it in K Framework (Maude-based) with a front end, KCC, designed to be usable like GCC. Their other work includes functional and logic languages. A team that did an executable semantics for all of those seems ideal for a formalized compiler for Rust given it's like several styles combined. Their rewriting based tools could probably handle at least a subset. Then you get DDC for free plus a way to equivalence check reference compiler for certain features.

https://github.com/kframework/c-semantics

http://www.kframework.org/index.php/Main_Page

I'm talking about the mean distance in expectations between a program and the compiled output. I don't think Modula-3 is much more complicated or even moderately more complicated. I think it's all pedantry of personal definitions at this point. What makes a language "simple" or even "the most simple" aren't even questions that are possible to answer objectively.

"I'm talking about the mean distance in expectations between a program and the compiled output."

Then you should be talking about Rust, C++, Java and other complex languages if that's your concern. Wirth-style languages use simple constructs that map straightforward to assembly. He actually designs the language in conjunction with the compiler so the simplicity is maintained. If it's hard to compile, he just takes it out of the language. Modula-3 adds select complexity to a Wirth-style language to give it exceptions, multithreading, and a standard library. Most of them are similarly straight-forward in implementation. It's why it compiles lightening-fast.

That is what the Assembly view of the compiler is for.

Also your complaint can be applied to C as well.

Given how optimizing compilers work, and the amount of UB being exploited, the language stoping being simple long time ago.

Modula-3, like many Wirth-inspired languages, can be described in a few pages with developers understanding those pages. You can be writing useful code in a day, using most of its features in a week, and probably master it in months to a year. The GC doesn't make it any less simple as that's one component that lets you ignore the complexity of memory management. The component itself can also be simple.

Rust being simpler than other programming languages you cite actually means those languages are enormously complex. That is, given how much more complex Rust was to Wirth-style languages, Smalltalk, Scheme, and so on. It has extra stuff. Hence, the extra complexity. The compiler is also harder to write to make all that work.

Have only checked Rust out a bit, but you mention C#. Does Rust have functionality similar to, and as easy to use, as Linq?

Linq, ick. It's a performance nightmare. No one knows what it is actually doing in the background so firstly, everyone writes horrible O-cubed performance with it, and then it is a series of random poking around to try fixing it.

Depends if you're using it with ORMs or not. It's equally as useful with data in memory. Definitely slower for some things though (yes, it's always slower in one sense... But its also easier to make parallel, so it can even out in the end)

Still, I now prefer doing such things in Rust.

In Rust, you'd generally use functions that return iterators or Tokio's streams for Linq-style tasks. Check out the "Complex Queries" example on http://diesel.rs for an example of what a Linq-like library looks like in Rust.

Yes, it does. Also a C# programmer. I really like Rust. About as easy to use to transform, filter, group etc, but considerably faster.

How are you defining complexity in a programming language?

I suppose it's the difference between the computational model presented by the language verses the computational model presented by the computer. A combination of how many components require some runtime environment to exist and how many disparate language features there are. Not an intuitive definition of simple for sure, but this is in the context of a system's programming language. In terms of just plain simple, I'd say scheme or just lambda calculus even takes the cake.

So the fact that that is a scheduler and a garbage collector in go means that by your definition even the simplest go program has a large complexity cost?

Not necessarily large, but it factors into the mean complexity cost.

Reply on news.ycombinator.com