Hi burntsushi - sorry you did not like it. I spent months before this article asking Rust developers about their experiences where I concentrated on people actually shipping code. I found a lot of frustration among the production programmers, less so among the people who enjoy challenging puzzles. They mostly like the constraints and in fact find it rewarding to fit their code within them. I did not write this sentence without making sure it at least reflected the experience of a lot of people.

I agree wholeheartedly. Not sure who the target survey group was for Rust but I’d be interested to better understand the questions posed.

Having written a pretty large amount of Rust that now runs in production on some pretty big systems, I don’t find I’m “fighting” the compiler. You might fight it a bit at the beginning in the sense that you’re learning a new language and a new way of thinking. This is much like learning to use Haskell. It isn’t a good or bad thing, it’s simply a different thing.

For context for the author - I’ve got 10 years of professional C++ experience at a large software engineering company. Unless you have a considerable amount of legacy C++ to integrate with or an esoteric platform to support, I really don’t see a reason to start a new project in C++. The number of times Rust has saved my bacon in catching a subtle cross-thread variable sharing issue or enforcing some strong requirements around the borrow checker have saved me many hours of debugging.

It is strange, taste in fonts. I’ve searched for a different programming/terminal font a few times but Terminus looks best to me.

It’s pretty much the difference between dot-matrix printing and laser printing.

All the bitmap fonts become either ugly or unreadable on a true retina screen.

We expect people to be competent enough to not crash their cars, but we still put seatbelts in.

That’s perhaps a bad analogy, because most people would say that there are scenarios where you being involved in a car crash wasn’t your fault. (My former driver’s ed teacher would disagree, but that’s another post.) However, the point remains that mistakes happen, and can remain undiscovered for a disturbingly long period of time. Putting it all down to competence is counter to what we’ve learned about what happens with software projects, whether we want it to happen or not.

I wish more languages had patterns. Haskell example:

data Named = Named {Name :: Text} deriving Show

greeting :: Maybe Named -> Text
greeting (Just thing) = "Hello " + (Name thing)
greeting _ = ""

You still have to implement each pattern, but it’s so much easier, especially since the compiler will warn you when you miss one.

Hey, I’m the author of the post. And indeed that does work, which is why I’m doing that currently. However, like I try to explain further in the post this has quite some downsides. The main one is that it can be easily forgotten. The worst part of which is that if you did forget, you will likely find out only by a runtime panic. Which if you have some bad luck will occur in production. The point I try to make is that it would be nice to have this be a compile time failure.

Finishing the Aubrey-Maturin series I started reading during my batch at Recurse Center. I’ve really enjoyed the period language, manners, and plotting and am sad to have reached the end.

Those truly are great books. Did you read the last (incomplete) one? I didn’t think it’d be worth it.

Have you tried listening to ‘pink noise’? I don’t use it all that often as I prefer silence, but it does help me concentrate sometimes.

the author specifically calls out what the problem with QT is.

Native cross-platform solution like Qt tend to consider themselves more a library, less a platform, and have little to offer when it comes to creating auto-updating software, installers, and App Store packages.

Don’t be so dismissive of peoples choices with the ‘new hotness’ criticism.

This is an overly simplistic argument that misses the point. Desktop app development has not changed significantly in the past five years, and without Electron we would simply not have many of the Electron-powered cross-platform apps that are popular and used by many today. You can’t talk about “not optimizing for user happiness” when the alternative is these apps just not existing.

I don’t like the Slack app, it’s bloated and slow. I wouldn’t call myself a JavaScript developer, and I think a lot of stuff in that world is too ruled by fashion. But this posturing and whining by people who are “too cool for Electron” is just downright silly.

Make a better alternative. It’s not like making an Electron app is morally worse than making a desktop app. When you say “we need to make desktop app development better” you can’t impose an obligation on anyone but yourself.

forget that a user want’s to do things other than constantly interact with that one single application for their entire computing existence.

Quoted for truth.

Always assume that your software is sitting between your user and what they actually want to do. Write interactions accordingly.

We don’t pay for software because we like doing the things it does, we pay so we don’t have to keep doing those things.

perhaps because of the licensing model

I also think so. It’s fine for open source applications, but the licensing situation for proprietary applications is tricky. Everyone who says you can use Qt under LGPL and just have to dynamically link to Qt, also says “but I’m not a lawyer so please consult one”. As a solo developer working on building something that may or may not sell at some point, it’s not an ideal situation to be in.

The situation is more nuanced than that. Because Electron provides developers with a better workflow and a lower barrier to entry that results in applications and features that simply wouldn’t exist otherwise. The apps built with Electron might not be as nice as native ones, but they often solve real problems as indicated by the vast amount of people using them. This is especially important if you’re running Linux where apps like Slack likely wouldn’t even exist in the first place, and then you’d be stuck having to try running them via Wine hoping for the best.

While Qt is probably one of the better alternatives, it breaks down if you need to have a web UI. I’d also argue that the workflow you get with Electron is far superior.

I really don’t see any viable alternatives to Electron at the moment, and it’s like here to stay for the foreseeable future. It would be far more productive to focus on how Electron could be improved in terms of performance and resource usage than to keep complaining about it.

but I shouldn’t have to be killing slack and zoom every time I unplug my laptop

Yes, you shouldn’t. But that is not Electron’s fault.

I’ve worked on pgManage, and even though ii is based on Electron for the front-end, we managed to get it work just fine and use very little CPU/Memory*. Granted, that’s not a chat application, but I also run Riot.im all day everyday and it show 0% CPU and 114M of memory (about twice as much as pgManage).

Slack is the worst offender that I know of, but it’s because the people who developed it were obviously used to “memory safe” programming. We had memory issues in the beginning with the GC not knowing what to do when we were doing perfectly reason able things. But we put the effort in and made it better.

We have a strong background in fast C programs, and we applied that knowledge to the JS portion of pgManage and cut down the idle memory usage to 58M. For this reason, I’m convinced that C must never die.

* https://github.com/pgManage/pgManage/blob/master/Facts_About_Electron_Performance.md (Note: the version numbers referred to in this article are for Postage, which was later re-branded pgManage)

*Edit for spelling*

In our buzzwords-driven field?

Probably people considered API access “a good thing” just because “Facebook/Google is doing this too!”

But the problem was not the technology back then, just like AI is not the solution right now.

It’s the business model.

I remember a younger Zuckerberg explaining the world how privacy had no value for modern people.

He meant it!

back in those days, the tech ecosystem was definitely pushing for this openness.

I would hardly call 2015 “those days”.

If the cars are all on the same network

Any company that is connecting these cars to the Internet is being criminally negligent.

I say that as an infosec person who worked on self-driving cars.

The other major issue we’re not addressing is that these cars cannot be closed source like they are now.

I strongly agree with this. I believe autonomous vehicles are the most important advancement in automotive safety since the seatbelt. Can you imagine if Volvo had kept a patent on the seatbelt?

The autonomous vehicle business shouldn’t be about whose car drives the best, it should be about who makes the better vehicles. Can you imagine the ads otherwise? “Our vehicles kill 10% fewer people than our competitors!” Ew.

I don’t buy your initial claims.

When you said “we’re 15 years away from autonomous vehicles”, what do you mean exactly? That it’ll be at least 15 years before the general public can ride in them? Waymo claims this will happen in Pheonix this year: https://amp.azcentral.com/amp/1078466001 That the majority of vehicles on US roads will be autonomous? Yeah, that’ll definitely take over 15 years!

We can have a common/standard set of rigorous tests that all companies need to pass but we don’t need them to literally all use the same exact code. We don’t do that for aeroplanes or elevators either. And the vanguard of autonomous vehicles are large corporations that aren’t being funded by tax dollars.

That said, I agree that it would be better to have more streetcars and other light rail in urban areas.

The solution to this is having scripts that continually go through your projects and show you outdated jars. It should be part of the CI. Trouble is you don’t often know if a jar update is security related or not like with traditional package management. But still on production projects, you really shouldn’t let your dependencies rot either.

I mean, the alternative is to write the code and security holes yourself. You’ll have the same security issues either way :P

I wouldn’t say exactly. Part of the problem is allowing unvetted randos to publish to the repository, but that’s not a necessary part of package manager design.

Whenever I set up a new OpenBSD system, I run “pkg_add chrome” which always fails, because the package is actually called chromium (although the binary in the package is called chrome, hence the confusion). It would probably be bad for somebody to come along and squat on the chrome name, but I don’t worry about this.

Yup, remember when this happened? https://gist.github.com/titanous/3e4829f79dbd1be11295

This is interesting, because it is one of the numerous protections Nix and packaging software with Nix protects against.

Gnome makes it’s return in Ubuntu 18.04 LTS.

Well Unity is a Gnome shell so I’m not sure KDE was ever even on the table.

From the Ars article at https://arstechnica.com/information-technology/2017/04/ubuntu-unity-is-dead-desktop-will-switch-back-to-gnome-next-year/:

By switching to GNOME, Canonical is also giving up on Mir and moving to the Wayland display server, another contender for replacing the X window system.

It’s also interesting what will happen to Snap packages.

They already dumped upstart and now Unity, why not Mir? If there are advantages of Mir in contrast to Wayland please let me know because I know very little about the differences of both display servers (protocols).

I am also pretty happy about the anouncement because it looks like canonical won’t continue with developing an alternative solution for everything in house, instead they will take the effort to improve an already existing solution which will hopefully be advantageous for anyone using Gnome and not running Ubuntu. With other words, this decision is good news for the Linux desktop.

I have a related but somewhat OT question. In one of the articles linked to by the article [1], they say this:

32 bytes of entropy from /dev/urandom hashed with sha256 is sufficient for generating session identifiers.

What purpose does the hash serve here besides transforming the original random number into a different random number? Surely the only reason to use hashing in session ID generation is if there’s no good RNG available in which case one might do something like hash(IP, username, user_agent, server_secret) to generate a unique token? (And in the presence of server-side session storage there’d be no point to including the secret in the hash because its presence in the session table would prove its validity.)

[1] https://paragonie.com/blog/2015/04/fast-track-safe-and-secure-php-sessions

Thanks for that very thorough dissection of JWT. Are there web app frameworks/stacks that do have helpfully secure and well-engineered defaults that you’d recommend?

And comments on https://datatracker.ietf.org/wg/cose/documents/ ?

No, modern C++ isn’t safe. Dangling references are still possible. Using an object after you have std::move()d it is still possible. Mutating a shared object without coordinating with other threads is still possible. Using uninitialized memory is still possible.

I share your enthusiasm for C++ but Rust’s promises WRT performant memory safety are next-level. That said, I will be waiting for indisputable signs of maturity from Rust before I even look at it. I am thinking another 5 years at least. It takes much more than memory safety to make a language usable in practice. Just imagine how much work needs to be done for a 7-year-old language (which has been stable (v1.0) for only a little more than 1.5 years!) to catch up to one which is 34 years old and has been in heavy use for most of that time.

I also wonder how long it will be before the various sanitizer tools (address, memory, undefined behaviour, integer, etc.) in clang and gcc are able to catch the same errors that the Rust compiler can. Are they even that far off today? Surely there’s no reason they won’t get there? If that happens in the near future it could hurt Rust badly.

Edit: I guess the sanitizers will never be able to do what Rust can because safety is designed into the language.

Edit2: But then again, many of the sanitizer checks are done at runtime which probably opens many language-independent possibilities, although it’s obviously inferior to having it all done at compile time and requires excellent test coverage to be effective.

Buy your computer from System76. Don’t even bother with anyone else. System 76 is the only company I trust to provide real, long-term support for computers with Ubuntu pre-installed.

You get rebranded Clevo machines, sometimes not ideal for Linux. You’re also limited by the selection of Clevo machines they have, and they don’t have a good thin and light.

This will go away in maybe 5 years (Snap packages and the Ubuntu Software Centre), but mixing libraries is still an issue on Linux. You may be surprised to know that by downloading a single application you may also be downloading all of KDE and some weirdness can happen with that.

Perhaps I am missing something fundamental, but if anything snap will make the problem worse because every application bundles its dependencies so you’ll be downloading “all of KDE” every time instead of once. If a package is currently erroneously pulling in too many dependencies then the package maintainer simply made a mistake and would’ve made the same mistake with a snap package.