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

Four Years of Rust

blog.rust-lang.org

Post reply on HN
Print view View original

131–140 of 203 posts

Re: Four Years of Rust

#131

Post by njepa »

wyatwerp wrote: post #115
njepa wrote: post #108

Earlier quoted context omitted.

I think mainly because mastering new concepts increases the barrier to entry, overhead and scope. Which in turn affects creativity. There are many brilliant programming languages, used by brilliant programmers, yet, most really useful software tends to be produced by whatever. It would be awesome if Rust could overcome that, but I don't really see how currently.

In the no-GC no-runtime niche, you probably need brilliant programmers anyway. Most of them are banging their heads against the C++ wall right now; they would love to get back some of their lost creativity via mastering of new concepts (Rust borrow checker, or Pony's deny capabilities - https://pony-lang.io ).

In my experience C++ programmers aren't necessarily great programmers as such. Because low levels things usually requires domain knowledge and experience more so than programming brilliance.

Re: Four Years of Rust

#132

Post by dpc_pw »

pjmlp wrote: post #112
dpc_pw wrote: post #104

Earlier quoted context omitted.

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…

Because having a GC doesn't mean throwing away deterministic destruction. Many GC enabled system languages do offer both mechanisms. It is a matter of enjoying productivity it offers, while having the tools to fine tune performance when it actually matters.

> Many GC enabled system languages do offer both mechanisms.

?

Can you give me an example? Java's `finalize` is not deterministic destruction. D's scope guards (or Go's `defer`) are also not like destructors, because a calling code has to take care of them.

> It is a matter of enjoying productivity it offers,

There's hardly any productivity gain, and it is being offset by productivity gained by a reliable and hassle-free resource management.

Re: Four Years of Rust

#133

Post by oselhn »

Waterluvian wrote: post #5

I love watching Rust progress. But the #1 thing I'm watching is the RLS and vscode plugin. Maybe I'm weird but I work with so many languages that having to manage multiple editors is a non-start. So any time I have a little personal project that could be done in Rust (for learning) I end up using Go or Python instead because the vscode support is still quite buggy. Naturally others will say you don't need IDE-like su…

I do not understand what people like about vscode. If I ignore insane resource consumption this is at most average IDE (the only real benefit over sublime "text editor" is integrated debugger). This is most preferred editor at work so I am forced to work with it and there are some of the most serious issues I have:

1. Only one side panel, so I can't see outline, test results and project files at the same time as I am used to see on widescreen monitors in other IDEs.

2. Language servers are still not comparable to solutions offered by java IDEs and in case of C++ they are worse than anything else I used.

3. Python extension constantly forgets and founds unit test. There is little support for unit test in other languages.

4. Official C++ extension despite being completely useless consumes several gigabytes of space for "indexed" files (I wonder if it is so bad to not hurt sales of Visual Studio). I also tried to use clangd which is better but there is still a lot of work to be done before it is useful.

I like sublime rust support for really small projects and eclipse support for larger projects (which is not ideal) but I have not coded anything serious in rust yet, so I do not know if there is some good IDE.

Re: Four Years of Rust

#134

Post by wyatwerp »

jandrewrogers wrote: post #107
wyatwerp wrote: post #85

Earlier quoted context omitted.

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 +…

The use case for non-GC languages go significantly beyond low-level OS kernel type code. Most of our backend infrastructure software and servers (e.g. database engines) are also poor fits for a GC languages, and this is what Rust is targeting. For this type of software, a GC has a large negative performance impact, so it isn't really an option. Operational cost efficiency is often a key factor in platform selection -…

Off-hand, Mirage OS comes to mind - it completely upends how you would "build" and "run" back-end services, and it is written solely in a GC'ed language - OCaml. And all GC'ed languages are not equal; see https://roscidus.com/blog about a Linux package manager ported from Python to OCaml for performance reasons (followed by an OCaml reimplementation of a component in a virtualized OS).

Some infrastructure, e.g. database engines, is ubiquitous, but all instances are of the same few software products written in C/C++/Java. Those ubiquitous instances have banged most bugs out of those codebases, so it is an uphill battle there to convince incumbents and upstarts alike, of the value of a new implementation. But Rust & Pony are marvelously positioned to march up that hill, especially if you throw in multi-threading.

My impression is that only a minority of widely-programmed back-end infrastructure that suits Rust is written in C/C++ (say, map-reduce kernels). The code-base size & the data flow complexity inside those components is pretty limited, and Rust should be tractable at that scale.

Most widely-programmed infrastructure software - in the back-end and on cell phone OS'es - have been merrily using Java/Python/Ruby/Erlang. OCaml is quoted as being used in the management component of VMware. These are much larger applications; is there any evidence or hint that Rust isn't onerous to develop larger systems in? Without that evidence, I feel (not think) that a disciplined GC'ed language (D? Pony?) has a better chance there.

Re: Four Years of Rust

#135

Post by vram22 »

Skunkleton wrote: post #125
vram22 wrote: post #122

Earlier quoted context omitted.

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.

Yes, good point. That's partly why I mentioned that vim is big, above. And there is tendency of some devs (not just beginners) to load many plugins (for any tool, not just vim), before learning the base tool well. Counterproductive, IMO, plus leads to cognitive overload. And at least in the case of vi/vim, you can compose commands, so, even without using things like macros or plugins, you can achieve a lot. So master that first. It will take you a long way.

Re: Four Years of Rust

#136

Post by [deleted] »

dpc_pw wrote: post #132
pjmlp wrote: post #112

Earlier quoted context omitted.

Because having a GC doesn't mean throwing away deterministic destruction. Many GC enabled system languages do offer both mechanisms. It is a matter of enjoying productivity it offers, while having the tools to fine tune performance when it actually matters.

> Many GC enabled system languages do offer both mechanisms. ? Can you give me an example? Java's `finalize` is not deterministic destruction. D's scope guards (or Go's `defer`) are also not like destructors, because a calling code has to take care of them. > It is a matter of enjoying productivity it offers, There's hardly any productivity gain, and it is being offset by productivity gained by a reliable and hassle-…

[deleted]

Re: Four Years of Rust

#137

Post by dpc_pw »

wyatwerp wrote: post #124
dpc_pw wrote: post #104

Earlier quoted context omitted.

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 determinis…

> indeed no mechanism to lazily schedule files/sockets for closure.

It's not only about file sockets. It's about your core abstractions. Thread-pools, channels, flushing streams, events and other stuff, unlocking Mutexes, auto-validating guards etc...

I have production or semi-production experience with code written in C, D, C++, Python, Go, Java, Node, Scala, Rust and others (please excuse argument from authority, but that's all I have right now) so I can tell the difference and I think ...

... people that haven't worked with Rust long enough greatly under-appreciate number of stuff that benefit from deterministic resource-like management - not only on system resource usage / performance side, but simply the day to day reliability and writing simple bug-free code with ease.

Re: Four Years of Rust

#138

Post by wyatwerp »

njepa wrote: post #131
wyatwerp wrote: post #115

Earlier quoted context omitted.

In the no-GC no-runtime niche, you probably need brilliant programmers anyway. Most of them are banging their heads against the C++ wall right now; they would love to get back some of their lost creativity via mastering of new concepts (Rust borrow checker, or Pony's deny capabilities - https://pony-lang.io ).

In my experience C++ programmers aren't necessarily great programmers as such. Because low levels things usually requires domain knowledge and experience more so than programming brilliance.

The topic was the no-GC no-runtime niche, which necessarily requires brilliant programmers, and they are stuck with C++. They would welcome tools to represent their resource control well, borrow checking or deny capabilities.

As a current C++ programmer who remembers what GCC 2.95's error messages looked like for even simple templates, I second you - it is less about the intellect, and more about experience and enough domain knowledge. But quite a few like me work on large C++ software that is not in the no-GC no-runtime niche; modules, good abstractions and native compilation would be enough to match or likely beat whatever we are putting together in C++, which doesn't even have modules yet - and the GC-based conveniences would be a big icing on the cake, so D, Nim, Pony all look interesting. (side note ... https://ponylang.io and not https://pony-lang.io as stated earlier)

Re: Four Years of Rust

#139

Post by renox »

pjmlp wrote: post #113
pornel wrote: 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.

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

Re: Four Years of Rust

#140

Post by renox »

Hermitian909 wrote: post #34
lmm wrote: post #20

Earlier quoted context omitted.

What is it you don't like about OCaml, or similar ML-family languages (e.g. F#)? Most of "modern language design" seems to amount to the ML featureset.

As someone who really enjoys OCAML, it has a variety of issues that prevent it from becoming popular (though I'm hopeful for reasonML). No multicore Standard library has... issues No community consensus on a common base setup, questions about which library to use for a task often get answers like "well, do you want to use functors or monads? because that will change the library we recommend" which is really not what…

Honest question: what is so bad about having to create one process per core? If you have lots of data you can use shared memory, so the performance should be similar no?
Post reply on HN