Four Years of Rust

Re:Four Years of Rust by wyatwerp on Wednesday May 15, 2019 @11:37AM (#19920455)

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, it even became another supported front-end in GCC, alongside Go, Ada, etc.

[ Parent | on HN ]

Re:Four Years of Rust by thrower123 on Wednesday May 15, 2019 @11:46AM (#19920547)

D is a weird one, because it has been lurking around for at least a decade and a half without really picking up the kind of steam and hype that later entrants have. I remember dabbling with D for game development way back in high school, as a friendlier alternative to C++.

[ Parent | on HN ]

Re:Four Years of Rust by wyatwerp on Wednesday May 15, 2019 @11:53AM (#19920625)

Well, Standard ML is a weird one too in that sense (lurking around for a couple of decades without picking up steam (outside academia?)). Languages having type inference and modules designed into them seems to have a good chance to live long.

[ Parent | on HN ]

Re:Four Years of Rust by pornel on Wednesday May 15, 2019 @01:54PM (#19921968)

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.

[ Parent | on HN ]

Re:Four Years of Rust by pjmlp on Wednesday May 15, 2019 @04:26PM (#19923390)

Only to the GC hating crowd.

Unreal and UWP/COM developers are perfectly fine with writing C++ code with a GC around.

[ Parent | on HN ]

Re:Four Years of Rust by pornel on Wednesday May 15, 2019 @05:31PM (#19923973)

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.

[ Parent | on HN ]

Re:Four Years of Rust by sanxiyn on Wednesday May 15, 2019 @11:56PM (#19926010)

Isn't Swift also refcounted?

[ Parent | on HN ]

Re:Four Years of Rust by pjmlp on Thursday May 16, 2019 @12:32AM (#19926137)

Reference counting is a GC algorithm, as per CS curriculum.

[ Parent | on HN ]

Re:Four Years of Rust by renox on Wednesday May 15, 2019 @06:11PM (#19924282)

Try to broaden your horizons.. I work in telecoms only one step away from a FPGA, a 1ms pause would be a critical bug report..

[ Parent | on HN ]

Re:Four Years of Rust by pjmlp on Thursday May 16, 2019 @12:25AM (#19926105)

My horizons are already broaden.

https://atlas.cern/discover/detector/trigger-daq

You can also try to broaden yours.

https://www.ptc.com/en/products/developer-tools/perc

Will this work for you? I guess most likely not, and you really cannot afford any kind of delay, where even a C++ virtual call would be considered a bug, given the 1ms delay.

The point being that only a very tiny population has such requirements, just like barely anyone writes applications 100% fully in Assembly.

[ Parent | on HN ]

Re:Four Years of Rust by renox on Sunday May 19, 2019 @01:19PM (#19954322)

I'll look at your links but to answer to your question: yes virtual functions are not accepted in the code.

[ Parent | on HN ]

Re:Four Years of Rust by adamnemecek on Wednesday May 15, 2019 @11:50AM (#19920602)

I think that part of the reason it didn't pick up is because it was made during an era when talking about the problems of C++ was brushed aside with "learn to program kiddo".

[ Parent | on HN ]

Re:Four Years of Rust by catach on Thursday May 16, 2019 @03:45AM (#19926969)

I suspect we are at least partially still in that era.

[ Parent | on HN ]

Re:Four Years of Rust by agumonkey on Wednesday May 15, 2019 @03:29PM (#19922868)

Success is often a matter of time. A good idea too early is the wrong idea kind of thinking.

[ Parent | on HN ]

Re:Four Years of Rust by amelius on Wednesday May 15, 2019 @12:15PM (#19920870)

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?

[ Parent | on HN ]

Re:Four Years of Rust by wyatwerp on Wednesday May 15, 2019 @01:43PM (#19921862)

Do you mean "thread local passed to another thread by mistake"? There is an option to make data global instead. Unless it is a Unix pipeline kind of design, independent threads can populate their working set (from file/socket/whatever) into thread-local memory.

It depends on whether shared-memory is a design requirement or an implementation artifact (Erlang does just fine with a largely shared-nothing model).

It also depends on whether a program runs for a short time, or for a long time. If you are running for a short time, why not just avoid the GC entirely; "manage" memory manually by malloc-ing and never free-ing (free-ing too takes time, and doesn't make memory available to other processes anyway).

[ Parent | on HN ]

Re:Four Years of Rust by bitwalker on Wednesday May 15, 2019 @01:03PM (#19921448)

The typical approach here as far as I'm aware is to use a deallocation queue - frees of an object that was allocated on another thread are freed by putting that object in the original thread's deallocation queue. When that thread gets an opportunity, it frees everything in its deallocation queue to reclaim that memory.

[ Parent | on HN ]

Re:Four Years of Rust by pcwalton on Wednesday May 15, 2019 @01:16PM (#19921597)

Manually, or automatically?

[ Parent | on HN ]

Re:Four Years of Rust by p0nce on Wednesday May 15, 2019 @05:16PM (#19923852)

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.

[ Parent | on HN ]