Live data from Hacker News

Four Years of Rust

blog.rust-lang.org

121–130 of 203 posts

Re: Four Years of Rust

#121
post #23

Earlier quoted context omitted.

Curious: if you rip out the js runtime in favor of pure webassembly, does that have a significant impact on electron viability? Obviously only once webassembly can do the full job

WebAssembly can't touch the DOM without JavaScript. Does that change your question?

WebAssembly can't touch the DOM without JavaScript.

There's still hope for ad-blocking, then.

Re: Four Years of Rust

#122

Earlier quoted context omitted.

Before Vim I had to look for an editor every time I learned a new language. Now I just use Vim. For everything.

Try :q! On a more serious note: I have a long-term goal to learn either Vim or Emacs for various reasons, the above mentioned being one of them. It's hard to feel so spectacularly unproductive as I do when I try them out though, so it's easy to give up. What's there best way to go about learning Vim or Emacs?

Maybe try out my vi quickstart tutorial:

https://gumroad.com/l/vi_quick/

vi is the predecessor of, and a subset of, vim, and is probably available on even more platforms than vim is. So knowledge of that single editor (vi) enables you to work on any of those platforms. And you can always progress to (and through - it is big) vim later, at your own pace.

I wrote it at the request of two Windows system administrator friends who were given additional charge of some Unix systems. They later told me that it helped them to quickly start using vi to edit text files on Unix.

Re: Four Years of Rust

#123
post #94

Earlier quoted context omitted.

Try :q! On a more serious note: I have a long-term goal to learn either Vim or Emacs for various reasons, the above mentioned being one of them. It's hard to feel so spectacularly unproductive as I do when I try them out though, so it's easy to give up. What's there best way to go about learning Vim or Emacs?

Not sure about emacs but vim basically requires a period of fighting through how horribly unproductive you will initially be, give it a week or two and you'll be ok.

Doesn't have to be so. See my other comment in this thread:

https://news.ycombinator.com/item?id=19923720

Re: Four Years of Rust

#124
post #104
post #76

Earlier quoted context omitted.

There are already several decent GC languages. If Rust was just another GC language, I don't think it would have attracted such a strong community required to develop all of these things and break out of obscurity. It'd be another Go with generics, or Elixir-native, or Swift with uglier syntax. In the no-GC no-runtime niche for a very long time there was nothing viable besides C and C++. For programmers who want C-li…

I don't really understand why people would want a GC over deterministic destruction like in Rust. GC is [neither necessary nor sufficient]( https://ruudvanasseldonk.com/2015/10/06/neither-necessary-no... ). Ownership model in practice is much more convenient precisely because objects can act like resources and implement their cleanup logic, and the business logic can rely on it. It's a great improvement in any impera…

As pjmlp said below, GC doesn't preclude deterministic destruction, so it isn't about resources in general; it is largely about memory. Also typical programs in any language have quite a bit of stack-allocatable data and C/C++/D/Go/Rust do support stack-allocatation, so the memory heap isn't involved everywhere.

Wherever the memory heap is involved, if the system isn't memory-starved, it can be argued that deterministic free-ing is a step too far; maybe you don't want time to be spent putting that long-ish list of heap-allocated values on the free list when exiting a function on the critical path. There is something to be said for lazy operations in such contexts, which the GC can provide (off the critical path - using GC.disable() in D) - a lot easier than a "region-based" memory management solution in C/C++/Rust. I don't know of a synthetic benchmark result to tilt the argument either way.

At a system level, it is slightly dismaying that the "back-pressure" required to trigger lazy operations is only present for memory, and only within a Unix process; when it comes to limits on open file handles or sockets or overall OS memory usage, there is no back-pressure to reclaim them - indeed no mechanism to lazily schedule files/sockets for closure.

Re: Four Years of Rust

#125
post #122

Earlier quoted context omitted.

Try :q! On a more serious note: I have a long-term goal to learn either Vim or Emacs for various reasons, the above mentioned being one of them. It's hard to feel so spectacularly unproductive as I do when I try them out though, so it's easy to give up. What's there best way to go about learning Vim or Emacs?

Maybe try out my vi quickstart tutorial: https://gumroad.com/l/vi_quick/ vi is the predecessor of, and a subset of, vim, and is probably available on even more platforms than vim is. So knowledge of that single editor (vi) enables you to work on any of those platforms. And you can always progress to (and through - it is big) vim later, at your own pace. I wrote it at the request of two Windows system administrator fr…

Another nice thing about learning Vi first: no plugins. There are so many plugins that make Vim _worse_. In my experience most novice vimmers end up with a huge vimrc, which overtime is pared down to something pretty small as they learn how vim actually works.

Re: Four Years of Rust

#126
post #45

Earlier quoted context omitted.

Are you describing the D language? https://dlang.org C-like syntax and execution speed with high-level scripting-language-like conveniences, close to Lisp-level ability to generate code at compile time, an active user-base ( https://forum.dlang.org ) that continuously strives to get the language improved. Its (thread-local) memory heap is GC'd by default. They also have an LLVM back-end if that is pertinent. Recently…

What do you mean by: > Its (thread-local) memory heap is GC'd by default. What happens to objects that are allocated in one thread, and then have their reference passed to another thread?

In D the GC heap is shared across registered threads, so it supports values allocated in one thread and passed to another. This particular passage from one thread to the other is guarded by a "shared" type constructor, so as to have a type system guarantee.

Re: Four Years of Rust

#127
post #11

I wonder how many Rust users really want linear types and borrow checking, instead of the other stuff Rust brings to the table: modern language design, large and friendly community, nice type system, native compilation, good package ecosystem. Personally I would prefer a well-designed GC'd language with a strong type system and native compilation over Rust, unless I was doing something with specific demands on parall…

If you don't want the borrow checker, why are you even using Rust? The borrow checker is the foundation of the zero-cost safety guarantees that make Rust such an incredible language to work with.

Re: Four Years of Rust

#128
post #76

Earlier quoted context omitted.

There are already several decent GC languages. If Rust was just another GC language, I don't think it would have attracted such a strong community required to develop all of these things and break out of obscurity. It'd be another Go with generics, or Elixir-native, or Swift with uglier syntax. In the no-GC no-runtime niche for a very long time there was nothing viable besides C and C++. For programmers who want C-li…

Taking nothing away from the Rust community that has managed such a complex language so well so long, I have to say that there never was anything viable in the no-GC no-runtime niche (that is why it is a niche - otherwise why would anybody be using GC'd languages). We were/are just gritting and bearing C++. If it is a typical program, i.e. not a device driver or OS kernel running on low-memory hardware, having a GC +…

> Of course, for short-running programs, just malloc, don't free, is the fastest.

A custom malloc that knew free would never be called would be faster still. I wonder if any short-running utilities do this?

Re: Four Years of Rust

#129
post #111

Earlier quoted context omitted.

It's not 100% for sure, but it's 99% for sure that async/await will be stable in August. The decision to stabilize is being made in seven days, and if it's decided, it will take that long to make it into its first stable release.

We have the whole team waiting for this to land. We're probably going with nightly already due to the problems fitting Futures 0.1 model to our codebase. Very nice to hear.

The proposed syntax has already landed in nightly, so you could use it right now if you wanted, by the way.

Re: Four Years of Rust

#130
post #113
post #80

Earlier quoted context omitted.

D excluded itself from being C/C++ killer by having a GC. I know they've backtracked on that, and the -betterC subset of D looks interesting, but it's a bit late for that.

Only to the GC hating crowd. Unreal and UWP/COM developers are perfectly fine with writing C++ code with a GC around.

If GC & runtime is on the table, then there are many nicer languages you can use (Go, D, Swift, Kotlin). I assume that the C and C++ users who haven't switched yet are largely the "GC-hating" crowd that can't.

COM and other refcounted ones get a pass. But I'm surprised that Unreal gets away with a mark-and-sweep GC. Perhaps because it's only required for UObjects, and the rest of the codebase can still easily avoid using the GC? You can even cause use-after-free bugs on UObjects, if you want to.

Post reply on HN