Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Two years of Rust

blog.rust-lang.org

Post reply on HN
Print view View original

31–40 of 312 posts

Re: Two years of Rust

#31

Post by steveklabnik »

cwzwarich wrote: post #30
steveklabnik wrote: post #26

Earlier quoted context omitted.

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.

Re: Two years of Rust

#32

Post by webkike »

cwzwarich wrote: post #22
webkike wrote: post #8

Earlier quoted context omitted.

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

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. Ma…

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.

Re: Two years of Rust

#33

Post by webkike »

comex wrote: post #18
webkike wrote: post #8

Earlier quoted context omitted.

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

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…

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.

Re: Two years of Rust

#34

Post by nickpsecurity »

kibwen wrote: post #28
nickpsecurity wrote: post #4

Earlier quoted context omitted.

Simplicity? Modula-3 was simple, fast, and safe. PreScheme was less type-checked but powerful and simple. You can learn how to use them in a day coming from an imperative or functional language. Rust looks like it gives users extra power/safety with quite a bit of a learning curve (most say weeks to months) due to extra complexity. Definitely not simple, though. https://en.m.wikipedia.org/wiki/Modula-3 https://en.m.w…

The Modula-3 Evangelism Strike Force! We meet again! :)

Lol. While we're at it, I guess that makes Adacore and pals pushing Ada the Imperial Army, Ada Division given DOD background.

Re: Two years of Rust

#35

Post by kbenson »

comex wrote: post #18
webkike wrote: post #8

Earlier quoted context omitted.

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

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…

> 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.

Re: Two years of Rust

#36

Post by comex »

sillysaurus3 wrote: post #7
brandur wrote: post #3

I'm consistently blown away by just how good the project management for this language is. It's not just the forward progress that the language is making (which is considerable), but also just how well they package the information up into a form that the rest of us who are not involved day to day can digest, like has been done here. Another example is the "This Week in Rust" newsletter which takes progress that would'…

I'm still on dabbling in Rust, but I'm fairly convinced that in another few years after this Tokio churn has gotten a chance to settle down and the async patterns are more broadly refined, there won't be many justifiable reasons to not write new projects in it, whether they're as low level as a Postgres extension or as high level as a DB-backed HTTP application. Not being hindered by the compiler telling you what you…

The comment I'm replying to really doesn't deserve to be in the grey. Rust is a great language, but like any language it has plenty of tradeoffs and room for improvement. Right now it has no REPL at all; in a few years it might, but who knows. And even if it does, it's unlikely to be able to fully replicate the experience of a LISP REPL, if only because the language is thoroughly statically typed - which of course has lots of benefits as well. Tradeoffs!

Re: Two years of Rust

#37

Post by nickpsecurity »

webkike wrote: post #8
nickpsecurity wrote: post #4

Earlier quoted context omitted.

Simplicity? Modula-3 was simple, fast, and safe. PreScheme was less type-checked but powerful and simple. You can learn how to use them in a day coming from an imperative or functional language. Rust looks like it gives users extra power/safety with quite a bit of a learning curve (most say weeks to months) due to extra complexity. Definitely not simple, though. https://en.m.wikipedia.org/wiki/Modula-3 https://en.m.w…

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

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.

Re: Two years of Rust

#38

Post by brandur »

ben_jones wrote: post #27
brandur wrote: post #3

I'm consistently blown away by just how good the project management for this language is. It's not just the forward progress that the language is making (which is considerable), but also just how well they package the information up into a form that the rest of us who are not involved day to day can digest, like has been done here. Another example is the "This Week in Rust" newsletter which takes progress that would'…

In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc.

> In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc.

I think the most classically cited problem is the learning curve. Understanding ownership and lifetimes, and understanding how to satisfy the borrow checker can be quite daunting.

Here are a few that I think about personally and which are probably a little more unusual to see:

* Batteries not included: the standard library's been pretty stripped down in favor of moving things out into external crates. The justification is that packages included in the standard library tend to ossify and become liabilities as they outlive their usefulness [1]. I buy the argument, but am a little worried that it's going to result in a fractured ecosystem where even extremely common functions like HTTP don't have "one true path" so we get a dozen different packages that try to handle it.

* Tunnel vision focus on Tokio: to my eye the community seems a little obsessed with Tokio and zero-cost futures. It's really nice how performant it is, but I'm not crazy about how futures-based concurrency spreads into your code through huge amounts of necessary boilerplate (`.and_then(...).and_then(...).and_then(...)`). I think that for most cases where performance is not an absolute mission critical necessity, a light runtime that manages asynchronous operations for you (say like Go's) is probably the way to go because it unlocks far better productivity. I'm cautiously optimistic about the possible inclusion of something like an `await/async` construct.

[1] https://blog.rust-lang.org/2017/05/05/libz-blitz.html

Re: Two years of Rust

#39

Post by nickpsecurity »

webkike wrote: post #32
cwzwarich wrote: post #22

Earlier quoted context omitted.

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. Ma…

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.

Re: Two years of Rust

#40

Post by sillysaurus3 »

brandur wrote: post #10
sillysaurus3 wrote: post #7

Earlier quoted context omitted.

I'm still on dabbling in Rust, but I'm fairly convinced that in another few years after this Tokio churn has gotten a chance to settle down and the async patterns are more broadly refined, there won't be many justifiable reasons to not write new projects in it, whether they're as low level as a Postgres extension or as high level as a DB-backed HTTP application. Not being hindered by the compiler telling you what you…

> Not being hindered by the compiler telling you what you can and can't do; freeing yourself from the write-compile-debug cycle, reducing it to repl-done; etc. Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost. I saw someone use the analogy of a credit card on here before: purchases are very easy t…

Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost.

If you understood the wins of untyped languages, you'd be aware that this is often the most optimal path for a startup to take. Get features done now + fix them later is, in hundreds of cases, the way that startups win.

It's also a win for people who come home from work and want to get features done on their side projects rather than write perfect code.

It's beginning to get tiresome to continually hear the Rust community go on and on about how amazing Rust is and say, with a straight face, that eventually there will be no reason to write anything in not-Rust. Are you serious? The hubris is off the charts.

If your language doesn't have a REPL, your language is less productive. Deal with it.

That said, the engineering tradeoffs are often a win. I love Rust; borrow checking is frankly incredible. But it's important to keep perspective.

Post reply on HN