Live data from Hacker News

Two years of Rust

blog.rust-lang.org

261–270 of 312 posts

Re: Two years of Rust

#261
post #137

Earlier quoted context omitted.

> What's your experience level with other languages? ~15 years experience across C, ARM assembler, Javascript, Lua, Ruby, Python, Erlang, Go, and Rust. Mostly doing Elixir these days. Admittedly, I've never used an IDE; I write all my C in vim. > ...you write compiled unit tests and/or test programs to poke around at the API. That assumes you can get your tests to compile; or that the compilation errors are at-all he…

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

C has had REPLs since the 90's, one just needs to search for them, and eventually buy them.

They were quite common advertising in The C User's Journal and Dr. Dobbs.

Re: Two years of Rust

#262
post #227

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.

That is how I once developed a B+ Tree library for low level disk blocks back in 1996, it was quite helpful tracking down how the nodes were being used.

Re: Two years of Rust

#263
post #65

Earlier quoted context omitted.

> 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. So a few considerations here: (1) I really have no connection with the Rust community aside from curiosity, so it's quite dishonest to project my opinion onto a…

But do you think the Go community agrees with this, just to name one of the popular newer languages? It's nice that Rust is doing well, and more power to the community. But there is an entire world of programming language communities out there that might not agree with the assessment that Rust is the future for them. Anyway, I was around for this kind of talk when Java was new and shiny, and there were people in the…

Java and its counterpart .NET did indeed replace C and C++ in 80% of enterprise applications.

The remaining 20% are stuff like device drivers or high performance libraries that are easier to write in C or C++, or legacy MFC applications.

Also if you look at operating systems like Android, Google makes it very explicit that you need a very good reason to down into the NDK dungeons, to the point that the set of allowed libraries only cover the use cases of 3D graphics and bringing native libraries into Android.

Likewise when Android Things was still called Brillo, the plan was to re-write the Android Framework in C++, instead they ended up bringing ART into Brillo.

Re: Two years of Rust

#264
post #256

Earlier quoted context omitted.

Cargo is a development and build tool, and it's quite possibly the best I've ever used. I don't know of any specific reason it's "fuck the package manager". Cargo does it's own dependency management, so I assume you mean to say that because of this, it makes it difficult to integrate into standard methods package managers use. After reading some of the email threads with OpenBSD, I do get the sense that it's complex…

> 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 believe it's doing it wrong, but every package manager for every OS out there does things differently, Rust can not fix this.

> That's a recipe for dll hell if I've ever heard one.

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 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, with the cargo manifest used to generate the various package managers dependency graphs as necessary. This would probably look a lot like, or actually be an integration with, FPM.

Re: Two years of Rust

#265

Earlier quoted context omitted.

Your site does not works with Firefox ESR.

That's because ESR is a very ancient version of Firefox. Many things don't work on ESR. You need at least Firefox 52.

Enterprises, those companies that you want to eventually adopt Rust, usually use ESR.

Re: Two years of Rust

#266
post #255

Earlier quoted context omitted.

I don't know... I really think it depends on the audience you're catering to. As someone who only ever deals with compiled languages, this has never seemed to be a problem. Now, viewing this as someone coming from Python, Ruby, Node, etc., I can see compilation as being annoying. Is it really the only reason that they are disliking the language or is that just a strawman? I wonder if too much attention is being paid…

Turbo Pascal 5.5 was compiling 34,000 lines/minute. https://edn.embarcadero.com/article/20803 And even today Delphi 10 is quite fast. Same applies to many other compiled languages with modules.

I haven't worked with Pascal since 1999, I remember it being a much simpler language.

And no where near as fun. Hilarity ensued when I didn't realize there was no garbage collector.

Re: Two years of Rust

#267
post #255

Earlier quoted context omitted.

Turbo Pascal 5.5 was compiling 34,000 lines/minute. https://edn.embarcadero.com/article/20803 And even today Delphi 10 is quite fast. Same applies to many other compiled languages with modules.

I haven't worked with Pascal since 1999, I remember it being a much simpler language. And no where near as fun. Hilarity ensued when I didn't realize there was no garbage collector.

Pascal and Turbo Pascal aren't the same thing.

Turbo Pascal was more a kind of simplified Ada than a pure Pascal, which made me look down on C when checking down the laundry list of language features of Turbo Pascal 6.0 versus ANSI C89 in 1993.

Also by 1999 no one was doing anything serious in Turbo Pascal with the last version being targeted at Windows 3.1.

Delphi 1.0 was released for Windows 95, and it did at least have some kind of GC for COM based classes.

Also Delphi 10 might not have every Rust feature, but it surely has it own set of complex language features.

Or if you prefer Ada, C#, D are also possible sources of information regarding performance of compilation toolchains, with relatively complex languages.

Re: Two years of Rust

#268
Congratulations to the Rust team for the great work!

The impact of Rust on the programming safety community has grown so big that even hardcore Ada developers are getting really nervous about Rust's powerful competition.

https://groups.google.com/forum/#!topic/comp.lang.ada/H35QcY...

Although Nim and Lisp are still more productive than Rust for my use cases -- Rust really needs a convenient edit-compile-debug cycle, and also an easy bootstrap from source mechanism -- I am watching Rust's development with pleasure.

I am pretty convinced that within the next ten years Rust will not only cause a serious decline of C++ but also eat a big portion from Ada's lunch in safety critical applications.

Re: Two years of Rust

#269

Earlier quoted context omitted.

Async/await is commonly suggested as a lighter-weight syntax.

Well, isn't async/await complementary to futures?

Oh, it is, it just makes them a lot easier to use. The compiler does method restructuring magic behind the scenes to build the necessary state machines. Everything gets a lot easier to understand.

Re: Two years of Rust

#270
post #11
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

Have only checked Rust out a bit, but you mention C#. Does Rust have functionality similar to, and as easy to use, as Linq?

Yes, it does. Also a C# programmer. I really like Rust. About as easy to use to transform, filter, group etc, but considerably faster.
Post reply on HN