Hacker News Reader

Comment by cm2187 | Hacker News Reader

So basically we will now need to write more efficient software. A novel idea to many!

Reality: we get Electron but this time using Servo

Yeah this is the most uncomfortable opinion I see with rust. In general rust doesn't seem terribly well suited to existing toolkits (as most make heavy use of the OO paradigm). What's left is often very immature (e.g. cursive) and so there tends to be a knee-jerk reaction of: let's build a GUI toolkit on top of Servo. Electron isn't just bad because it's all a mess of javascript, it's bad because it's not portable, because the resulting apps are bloated and non-performant, and because they never quite work like native apps.

For all the people who wave the "one true Scotsman" flag at people whinging about the non-native feel of Electron I'd just like to point at Visual Studio Code. Opening a file vs directory on Windows is a hilarious exercise in fermented emacs-like keystrokes. On a Mac, try using the "Window" menu (it doesn't list the children) or try using the minimized window icons (they all have the very useful title "Code").

Yeah this is the most uncomfortable opinion I see with rust. In general rust doesn't seem terribly well suited to existing toolkits (as most make heavy use of the OO paradigm).

The Gtk+ bindings are pretty good. Of course, this is not surprising, because Gtk+ was doing OO on top of C.

Gtk+ is not the native widget set on macOS or Windows, but neither is Electron nor 'Servotron' ;).

Yeah I forgot (intentionally?) about the Gtk bindings. I've never been much a fan of Gtk (OO on C seems... wrong among other quibbles), but yeah the Gtk bindings occupy that better-than-nothing space but aren't something I'm hugely enthuastic about. They're not a multi-process client-server mess like Electron but they're also just wrappers around a big C library.

> Electron isn't just bad because it's all a mess of javascript, it's bad because it's not portable

Electron runs on (at least) Linux, Windows, and Mac OS. That may not be perfect, but, I think its hard to brand that as "not portable".

> Electron runs on (at least) Linux, Windows, and Mac OS.

Take a look at the issues opened for porting Visual Studio Code to not-Linux/not-MacOS/not-Windows. It's non-trivial in large part because Electron is a mess and not officially supported beyond Linux/Mac/Windows.

Are other toolkits easier to port to unsupported platforms?

I'd assume so based on both Gtk, Qt, WxWidgets, and Curses supporting more platforms (e.g. BSDs). Certainly qmake is leagues ahead of the messes that Electron and VS Code use.

Edit: None of this is helped with the absolutely shittacular support that Node has for non-Linux unicies. Multi-platform support is one of those things that Rust really gets right.

I think a better analogy would be something backend. Front ends may have gotten slow but that has been exacerbated by intel sitting on 4 core consumer chips for a decade now. However, AMD finally came along and shook that up with threadripper and now you can get 8 times the number of cores from AMD, or 50% more from intel. I think we still have quite a ways to go on the consumer side.

I feel like I could do essentially all computing that I do now, except surfing the Internet at broadband speeds, on a machine with 64MB RAM and a Pentium II. IO has gotten a lot faster and hard disks are a lot bigger, but the things I do still work at about the same speed most of the time.

Rust came just in time. A low-level language like those of old, but without the undefined behaviour and terrible tooling.

Without undefined behavior, the compiler had to be really conservative and for some platform it is going to be really slow.

For example, if you force C to have defined overflow semantics, the code you'll get for a CPU which does not behave in the same way will use an order of magnitude more instructions for that purpose.

I am no expert on Rust, but I think targeted optimized algorithms are what the unsafe trait is for. That way you can profile and choose when programming and debugging.

Rust actually gives you access to all overflow behaviors that you could want. So if you know that your target CPU has saturating overflow you use https://doc.rust-lang.org/std/primitive.i32.html#method.satu... or wrapping_add, or overflowing_add, or checked_add. The syntax isn't as nice as for normal + though.

Is there a way to specify that I don't care? That's exactly what C undefined behavior is for.

I'd take predictable slow software on some platforms over unpredictable fast software any day.

In rust, integer overflows are defined to be wrapping, which is how it works automatically on essentially every architecture Rust supports.

Say what you will about the undefined behavior, but C has great tooling :-).

There is in fact so much tooling for C that every project can use a different tool for managing dependencies.

Specially sanitizers for handling memory corruption like no other one.

Data scientist and lover of Python & Julia here. I'm looking forward to learning Rust.

Having come from Julia - I rather like elixir. Rust seems like it's great if you need control over everthing at a low level (great for browsers, operating systems). If you want a high level, but still very performant[0], FP language with very nice guardrails... I wrote a complete scheduler for data science tasks, from nothing, in 3 months.

[0] a lot of people seem to think that performance is everything but actually uptime and reliability are often more important.

With Elixir, can I set up a queue of separate programs written in other languages (Python/TensorFlow) such that when one task is finished, another can be started right away, or have a programmatic schedule? Essentially, can Elixir act as the scheduler for various tasks, or even spin up AWS instances through its scheduling?

not out of the box, but that's basically what I wrote.

How does one connect Elixir to the various other programs? I'm not too familiar with it, just curious.

I use singularity containers! So that lets me define and use a "unified shell out" protocol. It's pretty sweet. If you have any questions drop a line.

I came the other way around and tried some Erlang before settling on Julia, but if I your focus is on scheduling of data science tasks I know why you used elixir.

you definitely don't want to be using a BEAM language for numeric computation. On the other hand, if you try to write a web application in Julia, you have no uptime guarantees. I think that Elixir/Julia would make a really sweet combination for certain things, if Julia could easily talk to BEAM instances by presenting itself as BEAM node (to do RPCs from Elixir to Julia).

Yeah, I can imagine. That would maybe also not be too difficult as Julia apparently could ccall the erl_interface c-library http://erlang.org/doc/apps/erl_interface/ei_users_guide.html

You should ask the poster above me.

Indeed I shall

> but without the undefined behaviour

This line of comments is rather silly, as it tries to compare implementations with a language specification described through international standards. Apples and oranges. Mozilla's rust implementation has no undefined behavior because it isn't even defined in any standard document nor are there many competing commercial teams developing rust implementations independently of each other. Complaining that C has undefined behavior but rust hasn't makes as much sense as complaining that C has undefined behavior but MS Visual C 2015 doesn't.

> Mozilla's rust implementation has no undefined behavior because it isn't even defined in any standard document nor are there many competing commercial teams developing rust implementations independently of each other.

This is not true. “No UB in safe Rust” is a guiding principle of the language design.

(And there is a second implementation of everything but the borrow checker.)

MS Visual C absolutely has UB.

Reply on news.ycombinator.com