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

271–280 of 312 posts

Re: Two years of Rust

#271

Post by xorxornop »

zlynx wrote: post #13
jabits wrote: post #11

Earlier quoted context omitted.

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.

Re: Two years of Rust

#272

Post by flukus »

bluejekyll wrote: post #264
flukus wrote: post #256

Earlier quoted context omitted.

> Cargo does it's own dependency management Exactly, that's why it's a "fuck the package manager" approach, it ignores the package manager. > If you're pre-building something and pushing a package for say dpkg or rpm The problem is multi copies of the same dependencies everywhere adding all sorts of bloat and security issues. Not to mention introducing it's own incompatibilities. > Should an OS want to bless crates,…

> The problem is multi copies of the same dependencies everywhere most binaries would be statically linked and compiled, so there wouldn't be copies, but you do have a valid point of an issue with needing to upgrade an tool that was build with a static dependency that has an issue. If I understand you, you're saying Rust, a general purpose language, with it's own build tool should do what exactly? I see that you beli…

> but every package manager for every OS out there does things differently, Rust can not fix this.

Exactly, it can't fix it but it tries to cover over this fact by bundling dependencies with every app.

> I think what you want is every crate on crates.io to be packaged as an installable rlib and dylib for every package manager out there

Basically, but more to the point, when a bug or security issue is fixed I don't want to rely on individual programs updating their dependencies. Let's say 10 years from now the rust version of gstreamer is widely used and a security issue is discovered, I want to be able to "apt-get upgrade" and know that it's patched. This is how things work now with the c version, but this can't be done with cargo, every app using the library has to update it's dependencies and many (particularly any corporate ones) will never update. Rust might be a boon for security but cargo could undermine the effort.

Aside from that, static linking creates a tonne of bloat, memory and disk. There is a reason windows apps are often so bloated compared to their linux counterparts.

> The package managers can be configured to work with Rust, and likewise Cargo can be configured to work with the various package managers, but it takes work.

I don't think that's good enough, if rust wants to be a systems language then it has to work with the system, not be a layer on top of it like java/.net/node. It can do this technically, but culturally it's looking more like node and less like c.

Re: Two years of Rust

#273

Post by cytzol »

amorphid wrote: post #213
vvanders wrote: post #71

Earlier quoted context omitted.

Oh please, it's plenty fast, at least on par with javac. There's also 'cargo check' which is blazing fast. If you're seeing very large compile time then it's a good sign that you probably want to break things into smaller crates anyway. I've been working on some pretty large stuff and compile speeds haven't been an issue(aside from the Emscripten linker, but that's not Rust's fault).

When you compile Java from the command line, is the compiler smart enough to not recompile files that haven't changed? Or is that an IDE feature?

javac itself doesn't do any incremental compilation and will happily compile over your .class each time (though you can tell it not to; see http://stackoverflow.com/q/8271282)

Build tools like Maven and Gradle, as well as IDEs' internal build tools, will be smart and compile only the changed files.

Re: Two years of Rust

#274

Post by jmcomets »

Kali909 wrote: post #202
arwhatever wrote: post #115

Earlier quoted context omitted.

Rust is a simple, intuitive language that just gets out of my way and lets me focus on solving the problem at hand.

I've only dabbled briefly in it and read various articles about the new features, but that hasn't been my very limited experience. The syntax and namespace constructs etc all look quite arcane to me, and then there's the borrow checker. Not sure I'd call it simple and intuitive (at least yet, for me).

Having written quite a bit of Rust, I agree with you that Rust is far from simple and not always as intuitive as say...Python or Ruby for example.

However, I do appreciate the syntax which IMO is in that sweet spot between conciseness and expressiveness. Finally, the borrow checker is quite the experience. Whenever I banged my head trying to get some snippet to pass BCK, there was always an OH moment where I realized something was terribly wrong with my design.

PS: Yes, there's still a few weird BCK false-positives. Hopefully we'll soon have non-lexical lifetimes[1] that should fix most issues.

[1]: https://github.com/rust-lang/rust-roadmap/issues/16

Re: Two years of Rust

#275

Post by RhysU »

yorwba wrote: post #227
photojosh wrote: post #182

Earlier quoted context omitted.

> then you'll really wish that you had a REPL Yes. I write roughly equal amounts of C (microcontroller firmware) and Python (overall system control, running on embedded Linux). I absolutely wish I had a REPL for C. When implementing with a new library in Python, I'll usually use iPython to explore it, and if I need to run a decent amount of data through, I'll use a Jupyter notebook. I'd put the difficulty of grokking…

I use gdb as a C REPL. You attach it to a binary that has the functions you need, then you can use them with the `p` (or `print`) command. Loops and new function definitions are not possible, but sometimes it's still good enough.

Gdb as REPL is a nice trick. Beaker Notebook might give the notebook parent wants for C work.

Re: Two years of Rust

#276

Post by pjmlp »

derefr wrote: post #209
zzalpha wrote: post #204

Earlier quoted context omitted.

or rather, a language runtime that enforced some level of introspect-ability on everything And now we get to the real meat of it. It's not a REPL you want. It's reflection. It just so happens that the latter is frequently paired with the former. And I agree, that feature, which separates C#, Java, Ruby, Perl, Python, etc, from legacy languages like C make them significantly easier to use as a developer as the compile…

Reflection isn't orthogonal to a REPL; it's synergistic with a REPL. When you have a static language, yes, REPLs don't add much; reflection by itself is all you need and an IDE will suit you fine. But when you are working in a language with runtime code generation —one where objects can build themselves new runtime-native function handles in response to messages—then a REPL will be able to do things for you that an I…

Lisp, Smalltalk and Mesa XDE at Xerox PARC are the genesis of what an IDE is supposed to be.

Two dynamic and one static languages.

Re: Two years of Rust

#277

Post by burntsushi »

dang wrote: post #236
zzalpha wrote: post #226

Earlier quoted context omitted.

No one can demonstrate productivity gains because productivity can't be measured. So then the OP shouldn't have made the claim. It ain't my job to prove it. :) That said, I fundamentally disagree with the idea that one can't measure developer productivity. I agree that there are many potential measures, all of which have the potential to be flawed or distorted. But the idea that the productivity of a developer can't…

The fact that no one has come up with any plausible way of doing this is so commonly observed as to be a cliché. See for example https://martinfowler.com/bliki/CannotMeasureProductivity.htm... . > So then the OP shouldn't have made the claim Come now, it was you who moved those goalposts and you moved them half a field or more. OP claimed REPLs "have benefits". Your response was (paraphrased) "demonstrable measuremen…

Not sure I buy that. I think you need to go further up the thread chain to see the OP on this[1], which, to be fair to your interpretation, wasn't written by dwaltrip:

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

That seems exactly like the kind of claim that everyone should view with a healthy dose of skepticism, and I think zzalpha's initial response[2] hit that right on the nose.

[1] - https://news.ycombinator.com/item?id=14344891

[2] - https://news.ycombinator.com/item?id=14344957

Re: Two years of Rust

#278

Post by AsyncAwait »

flukus wrote: post #244
jfoutz wrote: post #240

Earlier quoted context omitted.

But that's how languages do it. CPAN was my first experience with it. At development time, I need weird libraries.i hope they're ready by release time. Package managers are awesome, but sometimes, fuck them.

Higher level languages get away with it because they are platforms in their own right, rust is meant to be a systems level language. I expect a systems level language to work with the system, not against it.

True, but there's not a simple, unified way to maintain packages across all major platforms that does not involve having your own package manager like Cargo.

Re: Two years of Rust

#279

Post by 3pt14159 »

perfmode wrote: post #228
3pt14159 wrote: post #136

Earlier quoted context omitted.

I fully agree with you, but I still start projects in Ruby. Why? Because returns from startups are exponential and the interest rate is higher than the interest rate on the technical debt. It's why compiled is a great choice for an established corporation with a well defined need and a large user base, while interpreted is better for most other business contexts, especially with tools like Numpy.

Have you seen helix? Ruby-Rust interop: https://usehelix.com/

Yeah, but I've been doing this stuff for a while now. I used to do it in C and then in Nim (unlike Go until about a year or two ago, Nim could always compile shared objects, so using it through the ruby FFI was pretty straight forward. I've also done some stuff in Cython and just communicated through the database to my Rails app.

I'm still not sure what the best way of doing things is. I tend to think that Rust is going to be the programming language of tomorrows operating system, but I'm not sure if it is going to get the wide library support of something like Cython, since the scientific community isn't as fractured as the software community. Tools like graph-tool / scipy / etc are hard to live without.

Re: Two years of Rust

#280

Post by nickpsecurity »

int_19h wrote: post #239
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…

If I remember correctly, the only reason why Modula-3 is memory-safe is because it requires a GC. That right there is a no-go for a "C++ killer" system language.

Most C++ apps can be written in a GC'd language. It has UNSAFE/SYSTEM for when you want to take chances managing your own memory. A language like Ada or Rust would be better at unsafe stuff.
Post reply on HN