Hacker News Reader

Rust isn't going to replace Python because it isn't an interactive language that can be used for adhoc analysis, but it will be used to write the libraries that python imports when the existing ones are no longer sufficient for people's needs.

Python isn't criticized as much as it is recognized as the lesser tool for certain categories of development. That's fine because it is a general purpose language with many great uses.

What do you mean? There's an RFC for a proper REPL in Rust and a bunch of good-enough hacks in the meanwhile, there just isn't that much demand for one. You can absolutely write ad-hoc scripts in Rust if you want to

Hobby project at best-- doing it because one can rather than because one should. That in itself is worthwhile to those involved, yet it doesn't mean it will disrupt Python.

You ask me as if I don't know what I'm talking about-- as if I am not well acquainted with the rust-analyzer grinding away compilation in the background, slowing down the machine and interrupting workflow?

Rust's Achilles heel is compilation. It is a hard enough problem to solve that it won't ever reach a level that it can successfully run in the background of a REPL workflow and offer a user experience comparable to that of Python. The user experience is the reason that Rust will not ever present a viable alternative. Just as with Python, this is also fine. Rust isn't the right tool for every job.

I have a question for you or anyone else who might know the answer: both Haskell and Rust have long compilation times for large systems, so why is the Haskell repl so fast and agile for interactive development? Is it just because Haskell has been around for so long that partial compilation is more refined?

Haskell has multiple implementations, including an interpreter.

GHCi uses an interpreter, with ability to load already compiled code into the REPL.

When doing an ad-hoc analysis along the lines of e.g. jupyter notebook, I imagine have to bother with types (let alone the borrow checker) just really gets in the way.

For Swift to be taken seriously, it needs to be actually usable across macOS, GNU/Linux and Windows, and not be something that still resembles the heyday of GNUStep experience.

Hacker News always has been driven by fashion and novelty. It's a news site after all.

The main innovation of recent programming languages is the use of social media for marketing and PR by their companies to promote them.

> The main innovation of recent programming languages is the use of social media for marketing and PR by their companies to promote them.

For some languages I think yes, others no. Rust in particular has a memory management philosophy which was basically novel when it came out; it existed in research papers and such but not very many people were using those languages to do mainstream software engineering. It’s a big deal.

It is not a big deal, It is good marketing.

I follow a lot of Rust programmers on Twitter. Here's my understanding, they are busy writing Rust code. Their tweets are about the code. Their bio points out that they are fortunate to write Rust for a living. They focus on how it was _done_.

Meanwhile, the other programmers I follow share what they've built as in what their code _does_ and why that makes them giddy. (C#, Python, JS,...)

Just like C++ conferences vs other languages. :)

In C++ conferences, the talks are about how to do data structure X in C++, on to do certain algorithms in C++, build systems, meta-programming tricks, and so forth.

In other languages, the talks are about how product X was built in language Y.

I worry that I may regret asking, but what qualifies as a big deal?

It's a subjective matter of course but for example a feature that Go and Rust have is type checking across module boundaries which is a big deal for me but it's not something very interesting to make marketing with.

Why isn’t it a big deal?

> It’s a big deal.

Only time will tell, right now don’t see any real benefits. I do agree though rust is a good attempt to try. Right now majority of the rust libraries depend on underlying C/C++ with unsafe code. Will watch how it will slowly replace Firefox use of C++.

Will wait and watch when rust will replace LLVM written in C++ with something completely written in rust. Although they replaced OCaml part with rust already so need to see when they can replace C++ dependency which is LLVM.

(My opinion might be biased as rust code reminds me of 1990’s and doesn’t look any different than C++, I like Swift syntax more)

I'm sorry (genuinely, especially in light of your self-aware end comment), but I don't believe that this is a well-informed comment. Yes, there are Rust crates that are written as bindings to C++ libraries, where there isn't drop-in available Rust code available to use, or either a de-facto standard API and well-tested C++ codebase allow for this. Examples of this can be found in relatively niche, code-heavy areas like machine learning, with OpenCV and Tensorflow libraries available in Rust just calling to existing system installation.

However, I think it's disingenuous to claim that either "a majority of the rust libraries" use bindings like that, or to suggest that Firefox is the primary project worth watching that uses Rust. As mentioned elsewhere in this thread, Rust articles and code examples fairly routinely show up here on HN. It's surely not complete, and any programming language or framework is an exercise in trade-offs, but from hacking on bare-metal or microcontrollers[1] to web GUIs with interactive physical simulations[2], Rust-only or Rust component code is showing up in a number of domains and production environments[3]. A lot of this is really seems to stem from a safety-by-overall-design rather than safety-by-specific-implementation approach, which seems to resonate well with both experienced developers and newcomers alike.

[1] https://rust-embedded.github.io/book/

[2] https://nphysics.org/demo_all_examples3/

[3] https://news.ycombinator.com/item?id=22238335

Edited for spelling/grammar

I really like the development happening in rust to write some core libraries, but given most hardware still use C for development, I doubt rust will be able to escape the fact that it will have to be a wrapper around C with rust api layer on top of it.

Firefox which is the reason for origin of rust, cannot yet be completely written in rust and will continue to be dependent on C++ for sometime. I feel like Python, Rust might become more popular once enough hardware and core libraries move away from C/C++ to Rust. It is still a decade or two away.

Firefox isn’t dependent on C++ because Rust is insufficient, it’s because porting (IIRC) fifteen MILLION lines of code just doesn’t happen overnight, and isn’t a direct focus.

That’s precisely the issue, until and unless enough libraries are created in Rust with little to no dependency on C/C++, it won’t be a significant language but will just be something similar to Haskell may be bit larger.

So I still feel Rust needs another decade or two to be able to claim as C/C++ replacement, not at present.

This is exactly the problem Swift faced to replace Objective-c, in Apple eco-system where everything controlled by Apple. Rust has much bigger hill to climb to be really useful systems programming language.

It is a big deal, however for many scenarios (like GUIs and game engines like Unreal/Unity) GCs are much better from productivity and tooling point of view, so it remains to be seen how much piece of the pie will be taken there.

And thanks to Rust, the designers of Swift, D, Chapel, C++, Ada, OCaml, Haskell, and maybe even C# and Java, are now taking linear types into consideration.

So for many deployment scenarios, GC + a linear types subset might be good enough, still one can thank Rust for those improvements even if indirectly.

As a programmer of Rust, Swift, OCaml, Haskell, C#, and Java, I’m well aware of these developments :). I definitely still strongly advocate for GC and prefer it when I don’t need the memory performance of linear types.

> Can solve it with Matlab or GNU octave, but couldn’t have developed easily the whole system with user interface in them.

This is a very key point. I still find that Matlab often has a larger set of features and better efficiency for linear algebra. But thanks to Scipy, you really can expand your mind about what kinds of systems to interface with.

GNU Octave is indeed faster than numpy. This may be because GNU Octave uses highly optimized solvers (like the famous modified Cholesky method). Due to scipy's license fundamentalism, they refuse to use many of these solvers because they are GPL-licensed. It is a bit sad to see how these ridiculous ideological constraints taint an otherwise excellent software package.

Much as I'm personally very pro-GPL, I think there are good reasons to avoid licensing fundamental parts of the SciPy stack under a copyleft license, since anything built on top would also need to be GPLed.

A scipy-copyleft for such GPLed components would be nice though.

I agree this is a great philosophy. I have to point out as well, though, that one of the major objections to C++ is that it is "too big" and has too many "dangerous" constructs, both of which are a consequence of this approach.

As a developer using the language this is great: I can write using clean modern approaches* and still use older packages. (Making this all continue to work is a burden on the implementation developers of course.)

* not to argue which modern features are clean or not -- this is about SciPy.

> Probably in time to come Rust will be used for some core library development which brings substantial benefits like scipy, not something rewritten as wrapper around C library with unsafe code which can be done with Python much better.

I think a nice situation would be to have all the core scientific libraries and tools written in rust with clean APIs, independent of any particular scripting language but with the clear goal of providing a clean API to wrapper languages. Then any scripting language can wrap these libs and go - essentially something like a universal numpy/scipy/scikit, etc. This would mean Ruby/Python/JavaScript/Julia, etc. would all be able to get to state of the art immediately while minimizing the duplication of effort across languages and creating a standard "ML" or "Scientific" API.

You mean like currently BLAS/LAPACK? Written in FORTRAN, wrapped by any scripting language, e.g. Python's NumPy/SciPy, Julia's LinearAlgebra (part of stdlib, https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/), R, Octave, Javascript (BLASjs etc.). That's the standard API for now.

I recall a couple of efforts to write a BLAS in pure Julia. https://discourse.julialang.org/t/we-can-write-an-optimized-...

That discrete traveling salesman problem of seating arrangements ... how did you model that? I have a similar problem with organizing committees where committees have members that are in other committees and so committees with overlapping members can’t meet together etc etc.

Not exactly TSP, but something similar on solving seating arrangements: it’s with simulated annealing; it might help with formulating your optimization problem.

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

Danke!!!

I think you could also see this as a graph coloring problem https://en.m.wikipedia.org/wiki/Graph_coloring#Scheduling

Edit: to elaborate, each committee would be a vertex and a committee-vertex is connected to another vertex if one or more of their members overlap. Once you’ve got such a graph you simply have to a assign a color (or number/letter/anything) to every vertex in the graph, with the requirement that no neighboring (as defined by being connected by an edge) vertexes are allowed to have the same color. You also try to use the minimum amount of colors needed. Then you can safely schedule the committees with the same colors for the same timeslots, and be sure that everybody will be able to attend.

Thank you! I can run with this.

Very cool. So what are your go-to tools for putting a front end on top of your models?

For the seating arrangement problem in conference everything is in Python and used flask with simple bootstrap and jinja templates.

Qt is cross-platform, very stable, and has sane Python bindings. No other reasonable choice (imo).