royjacobs

Tom Scott did an interesting video on the topic recently: https://youtu.be/mOy8Xjaa_o8

The design looks quite similar to Flyway[0]. I can confirm that this design has been working quite well for us in a large-scale production environment.

[0] https://flywaydb.org/

This looks really interesting! I'm wondering how they integrate with existing tools though, because I can imagine companies are not going to shift all of their existing tooling to Space in one go.

The best way to penetrate it is to just write a demo! It's fairly certain that it will be terrible, but the point is you tried and you will improve. Hopefully you'll get some pats on the back along the way, inviting you to try again with a second demo, and so it begins...

In my experience DOS/4GW was pretty stable. The only times it used to spam my mode13h screen full of registers was when I did something wrong myself.

Since when is urban planning cheating? :)

I don't mean just the river walk though, the leafy streets a bit farther around it are quite lovely.

Just as an anecdote, but as a Dutchman visiting the US on a few occasions I was pleasantly surprised to find that San Antonio's center was actually quite pleasant to walk around in. Get anywhere away from the center and just crossing the street became impossible again, though.

At a previous job I worked with someone who didn't see a buzzword they didn't like. Since nobody was stopping them, they designed an incredibly convoluted system using all the latest tech. In the end we replaced it with a JVM server and a Postgres database.

I occasionally check their LinkedIn and they're still spending 12-15 months every time at companies, being CTO or Big Data Strategist or whatever.

I would argue that in a sufficiently large organization you're better off using plain Java or perhaps Kotlin. The latter hits the sweet spot between 'expressive' and 'unreadable' whereas Scala can miss the mark.

I'm sure if you are very disciplined when writing Scala then this will not happen, etc etc. But the fact that people need to decide upfront which parts of Scala to use and which ones to avoid seem like red flags to me (and in fact were red flags, in my experience).

>Just wanted to point out that this system is also written in Haskell. We didn't really switch bandwagons.

Fair enough! In the end it's great that you've been able to take a step back and look at your ultimate goal (i.e. the customer problem solving). That doesn't always happen enough, and it's a good sign for your IT teams :) Also the fact that you were able to get the time to actually do this.

Reading this article it seems like yet another example of "you don't have big data". Most of the features that are unique to Spark (or Spark-like setups) were not needed, so in the end it's mostly...just an app talking to Postgres?

I'm not sure, but reading other articles[0] on the blog seems like they've been jumping on bandwagons before, so it's probably good to come back on those decisions every now and again.

Edit: Not trying to come off as too snarky, though I've found that this type of thing is pretty common in startups where everyone from the CTO on down has some experience but not a lot of experience. I've fallen into that trap too, at some point saying "Sure, Scala will work great! It's future-proof and everyone will love it!" cue crickets

[0] https://tech.channable.com/posts/2017-02-24-how-we-secretly-...

Is there a guide somewhere on how to set this up as a Pageant replacement for git purposes?

In the JVM land you can check out Kotlin, which does this.

It's a fun read. The interviews are decent, the technical background writing contains a bunch of errors.

No, but you can either spend a ton of effort trying to convince meat eaters that "this other thing is also delicious", but they'll just ignore it. Instead, just replace their burgers/nuggets with something else that also looks like burgers/nuggets yet pretty much tastes the same, and you don't need to convince them.

No, they're certainly not just chat applications, but if you think that Photoshop is an image editor that is somehow at the same level of complexity as Slack I'm not sure what to tell you. We'll have to agree to disagree!

I'm comparing it to applications that may have somewhat more reasons for slow startup times, like mentioned below in the thread (think: Photoshop, Maya, Unreal Engine, etc). Not a chat application.

I'm not saying Slack is not full-featured, but it's definitely not on the same scale as some of these other applications.

It seems to me that the reason this architecture is needed is because the original choice of technology necessitates it.

I mean, it's not that a C++ application wouldn't need a rearchitecting for startup performance, but it would likely not be needed for an application as simple as Slack.

So, on the one hand we've had this discussion here a ton of times: People are using Electron because it means faster shipping, easier cross-platform development, and so on. But on the other hand, the amount of hackery in Slack[1] that needs to happen just to get a level of performance and memory usage that comes within the ballpark of a native application is so high that it begs the question: At what point does the amount of work needed to get basic levels of performance negate the initial gains of building the application using a tool like Electron?

I'm not trying to troll and say "Electron bad" btw, I'm genuinely curious.

[1] See also: Optimizing VSCode, for instance: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...

The free version of GitLab has very limited support for issues, though. Things like 'related issues' are only available in the paid offerings.

Was FreeBSD really a requirement? I used to have a Sony Net Yaroze that allowed me to build PSX executables on my PC, using Sony's custom GCC-based toolchain. It didn't require FreeBSD.

Indeed, there's no reason this can't be extended in the future (and indeed content negiotated through regular HTTP).

You're right, I stand corrected.

I'm curious to see how this will pan out. I think the Matrix trilogy is a good example of a movie franchise that probably should've ended after the first movie, but perhaps the Wachowskis can pull a (white) rabbit out of their hat.

This is fantastic. It's been a promise for a long time that computers would become ubiquitous, open source software would be able to allow people to do (semi-)professional looking things for free, having access to the internet would be a great enabler, etc.

This is just proof that it's happening! It's genuinely inspiring to see this.

I don't think you'd be able to evaluate your expression without some kind of runtime reflection. Specifically, how is a standard library method supposed to interpolate {l}? It doesn't have any information about which variables are present in some kind of format string.

It looks exactly like it would in the latest version of Chrome and is not dependent on Qt's Webkit version.

Isn't the argument that there is nothing inherently wrong with OOP but like all things, it shouldn't be used exclusively?

For instance, working with language like Kotlin or C# it's fairly straightforward to get the best of both worlds: Use inheritance where appropriate, favor composition in all other cases.

IMO being dogmatic about not wanting inheritance altogether will result in friction as well: The fact that Rust eschews inheritance altogether will increase boilerplate whenever you want to do something that is 'inheritance-like'. Sure, people will argue that in 90% of the cases this is bad design, but for the cases where it IS the best approach it's a shame it's not part of your toolbox.

You don't mind drivers being half as performant as they were before, with the only benefit being they're easier to distribute? Why? How is that beneficial to anyone except the person packaging the driver?

Yes, except taking up much less space.