You can still start Redis as a Service companies. I was shocked at first because I thought this concerned Redis and their aim was to kill all of the Redis as a Service providers which already exist. But it turns out Redis Core is unaffected by this, only some modules are.

I don’t really know what they intend to achieve with this, except having people avoid using their modules…

Which doesn’t seem worthwhile, as the big players are the ones most likely to be able to market and monetise a service based on core Redis plus their own proprietary add-ons. It’s pretty difficult to compete with AWS on any front at this stage, given their massive resources and the “nobody ever gets fired for buying X” safety of big brands.

Boxing out only the small players doesn’t really feel like it’s going to preserve a whole bunch of market or mindshare for the Redis company.

http://softwearautomation.com/li-fung-announce-partnership-softwear-automation/

Softwear’s revolutionary digital t-shirt SEWBOT® Workline is fully autonomous and requires a single operator, producing one complete t-shirt every 22 seconds…

Ha, there’s actually some work on this, I think there’s a DARPA project as well, robotic garment assembly. I’ve given this topic a lot of thought myself. Robots can wield, why not sew?

A lot of businesses nowadays claim to be work agile, so in most places I worked at there is some implementation of Scrum. What I usually tend to set straight when I start in an org is to emphasize the pull-principle, i.e. prioritized backlog, people pull the items from the top. There is a certain magic to it. Devs get more relaxed and leave the office at 5, team leads – not without struggle – learn that not everything can be highest priority, that friction of pushing work items into people’s schedule is replaced by a certain flow.

Unfortunately, this usually involves refuting a lot of strange interpretations of agile / scrum that (I think) often stem from the consultants hired by the orgs to introduce agile methodologies or give management trainings on it.

…it doesn’t hide anything, there’s no magic behind any line of Go…

Go is a fine and relatively simple language, but I would argue there’s plenty of magic in the M:N threading, GC, structural typing, and runtime reflection.

I certianly won’t argue against any of your other reasons, though.

Thank you for linking that! I love the point at the end about languages being toolboxes and some are more suited for certain tasks than others:

But all languages have some problem domains in which they shine. I think that compiler implementation is one of those areas for ML. You’re writing a compiler and in middle of a function you need a 9mm crescent wrench with a box on the other end. You open up your toolkit and … there it is, in the top drawer, bright and shiny and strong. You use it, and then a few minutes later you need a small phillips screwdriver with a clip and a magnet … and there it is, bright and shiny and strong.

It’s not that there are an extraordinary number of tools in the toolbox. (No; in fact, the toolbox is much smaller than the usual toolboxes, the ones used by your friends that contain everything but the sink.) It’s that the toolbox was carefully and very thoughtfully assembled by some very bright toolsmiths, distilling their many decades of experience, and designed, as all good toolkits are, for a very specific purpose: building fast, safe and solid programs that are oriented around separate compilation of functions that primarily do recursive manipulation of very complex data structures.

This is a very important point and I’m glad that you wrote it out.

Would you say that the Scala ecosystem has a continuity problem because businesses and academia are focused primarily on the now and not necessarily building the road ahead for the community and then maintaining those roads once built?

Thanks for asking. I based my decision mostly on architectural analysis with a healthy dose of personal experience. We’re building a new product with cloud and on-premises components. Originally, I’d intended to build everything from scratch but my team identified some OSS that did 100% of we needed with some extra complexity in managing it. The trade-off was a much faster time to delivery in exchange for playing in someone else’s sandbox and by their rules. That aspect was worth it but I lament not being able to write it all in Scala!

However, our cloud services are written mostly in Scala. We have a few stateless microservices for which Scala was a great fit: high-performance OOTB for what within six months will be ~500 req/s and within two will likely exceed 4,000 req/s for one component with another being far more I/O bound. We’re integrating heavily with ecosystems that have Java libraries and we’ve found decent Scala wrappers that give us idiomaticity without building and maintaining them ourselves. We could have used just about any stack for these couple of services but Scala’s enabled us to express ourselves in types and exploit the advantages of functional programming. I’m chasing the holy grail of “it’s valid because it compiles” but we’ve got enough unit tests to complement our design that I’m pretty sure we’re on the right track.

One notable failure was on service that is primarily a user-interactive web app. We had two false starts with Scalatra, which we’re using for the other services, and Play! before switching to Ruby on Rails (temporarily) out of frustration with documentation, lack of examples, lack of drop-ins like what are commonly available in the Rails ecosystem, from whence I came many moons ago. We chose Rails because of the component owner’s experience with it as well as my experience with it and JRuby, knowing that if we started to implement any shareable logic, we could do so in a way that all of our apps could consume. We learned about Lift too late and http4s and some others didn’t give us the right impression for a web app. I just learned about Udash last week and it may be a candidate for replacement. However, it’ll be several months: even uttering R-E-W-R-I-T-E would be kiboshed from on high at the moment as the component does what we need right now.

Moving forward, we’ll be looking at moving some of these services to http4s, etc. once more of my team is comfortable with more hardcore Scala FP. Writing AWS Lambda functions in Rust is also on my radar, as a part of our on-prem product is written in Rust.

At least from my perspective it seems that:

• Typelevel is more busy in dealing with US politics than writing software,
• Monix is largely a one-man show,
• Scalaz is one of the main departure points for many people that move to Haskell,
• Sbt is so great that everyone is trying to replace it, and
• Ensime …? You just literally read the article by the Ensime creator.

I do think there are relatively few well maintained libraries outside of that core

The Scala community does have a solid core and near-core extension community. I consider libraries like Monix, Cats, and Scalaz to be nearly a part of the standard library because of how often they are used. sbt and ensime are important but they’re not exceptional: every stack needs a build tool and editor integration. These are solid now, and I appreciate the work that goes into them. Frankly, it wasn’t until sbt hit 1.0.0 that I considered it ready for widespread use because of its obtuseness/unergonomic interface prior to then. I’m eager to see what Li Haoyi’s mill will become.

Things I’ve noted in the past that I’ve found in a less-than-desirable state compared to other stacks:

• Internationalization - fragmented ecosystem, sbt plugins outdated
• Authentication & Authorization - no nearly drop-in solution like Devise in the RoR ecosystem
• Project websites being down for weeks because someone forgot to re-up the TLS cert, even in a LetsEncrypt automation world
• Out of date documentation to the point of being dangerous practices with little more than a “someone submit a PR to fix that”. I get that maintainers get busy but when safety is the topic, is it acceptable to wait for a drive-by contributor to get it right and contribute the correction? What if they do that and then no maintainer merges it for years?

The Scala Center has the promise of addressing much of it but I speculate that it’s insufficiently funded to be the ecosystem plumbers and teachers it aspires to be. I’ve been impressed with its work so far, though.

That’s good to know. It might be a bit more convincing then.

That’s great, apparently they did learn from Microsoft!

What’s the point of a “minimalist Unix for enthusiast desktop” if you’re not going to run it on metal? Doesn’t the presence of a hypervisor ruin the whole minimal feel?

I don’t know about Dell, but my 2016 MacBook Pro was hit pretty hard after the Specter/Meltdown fix came out. I used to go 5 or 6 hours before I was down to 35-40%. Now I’m down to %20-25% after about 4 hours.

Yeah I get 4-6 hours with the Dell, and I was literally getting about 2-3 hours on the Mac with the same usage patterns and apps running. I think the fact that you can be a lot more granular regarding what’s running on Linux really helps in that regard.

Yes but IMO in that case I would always choose the [][] because they make it utterly clear what you are trying to do, whereas general pointer dereferencing could be anything.

Yes, it does illustrate brilliantly why things in tech are the way they are.

In fact, why many things in our economy are the way they are.

Their solution to the PC losering problem is to transfer the complexity from the OS to the user.

ie. Every author of a program, that invokes almost any system call, must on every invocation, remember to correctly handle, the possibility of it returning EINTR.

Conversely, setting up a good test that proves that your code handles EINTR correctly, every time, is hard and you receive no help from the OS in doing so.

Now if the effort that has now been deployed on literally tens of thousands of packages on fixing obscure sporadic EINTR related bugs….. had been expended on solving the PC losering problem correctly…

We would all be much much better off.

ie. The cost of solving the PC losering problem has been externalised to all users of syscalls. This enabled the “Worse is Better” solution to win in the market place by winning the “time to market” race.

Alas, as is the case with very very many parts of our economic system, we reward via perverse incentives the “cheats” that externalize their costs…. but in the long run our entire civilization pays and pays and pays.

I’d be interested in talking to your company about their work, for sure. I’m capable as a data scientist, engineer, and manager. I’m in the DC area and can’t move (my wife’s job is here). And I can only work 9–5 (that is, not insane startup hours) because of my writing schedule.

I’ll reach out privately about the book. I’m going to recruit beta readers (between 10 and 20 is ideal) between now and September (with the book ready by then but a full read “due” in January). The time commitment at an average reading speed is about 1.5 hours per week (it’s a big book; projected WC is 220k, which is the main reason I’ve decided to self-publish it) over 16 weeks.

Is this brightwheel? The ios app is entirely too chatty, shouldn’t req/resp on every user action.

You might compare it to gentrification. You cater to the middle ground, the cool stuff around the edges is pushed out, the really creative people abandon the platform, you’re left with the most generic content. Blender is just the latest victim of a broad trend.

Most people may not “care” about Blender specifically, but they should care about an opaque platform that caters to the IP needs of multinationals in overly broad ways and incentivizes some really messed up behavior.

I was checking peertube yesterday and it’s a huge change from youtube user experience. A lot more involved, and a lot less intuitive. I have hard time imagining mass adoption with what I saw. Are there any good beginner friendly tutorials/intros to peertube out there?

I’m not saying to write one sentence to define all that you need to do to build a general ledger program. Defining what you need to do could be a series of conversations with stakeholders, team brainstorms, requirements gathering - getting an shared understanding of the problem in whatever way works best for the project team. My point is that you don’t need to proscribe how that task definition is reached (appreciate the irony of me proscribing it :) You don’t need a mental model to follow for every project.

Regarding estimation, this falls out of defining the problem as a series of discrete capabilities of the system. In your example, an accountant could help define what the acceptance criteria for the simplest possible application that could be considered a general ledger. From that a team that understands the domain should be able to break it down to features or capabilities that can be easily described. That may result in more than 1 iterations worth of work, but some experienced heads should be able to give estimates within 20% accuracy for each capability.

Of course, I’m also not implying that everything is simple. I threw out that 1-6 cycle only as a argument against process-heavy methodologies. In a complex system, that cycle could be very short and only cover a fraction of the final product.

Hell, much of what I’m rabbiting on about is agile stuff, my only point is that I think agile is only useful as a starting point for a team to find their optimal way of working together. As far as success goes, I’d say it’s far more important to have the right people and attitudes within a team than following the 10 Commandments of Agile. A human project team isn’t a machine to be oiled.

Yeah, Rust is my weapon of choice for new projects. Compile times are pretty bad on my old T420, but is slowly improving. I am eagerly looking forward to possible alternative backends for debug builds.

I keep using C++ for two reasons. One, Bjarne is the greatest language designer because he never gave up and created a language that is only becoming more relevant over time. Other designers give up and end up making new languages, one after another. Two, it turns out the world is a messy place and C++ has lots of symmetry breaking features. “Clean elegant” languages fail to make programming for humans as easy.

There are any number of workarounds, that obfuscate the code to varying degrees. This same situation arose with Optional in java 8, it’s there, but not really, so a lot of places you’d like to use it you have to go through similar contortions. The other problem is if interacting with different teams writing different parts of the app; everyone has to be on the same page or you’ll end up wrapping/unwrapping optional all over. And libraries. In the end I found optionals were a lot of trouble for very little gain.

I did wonder about that. However, blindly catching all different exceptions and effectively discarding the information about which exception it was seems unwise. Of course you could keep the information while still using sum types, but then you don’t really want std::optional, you want an either type which can hold either a valid value or an error code. I’m not sure whether the standard library has one of these or whether you’d have to roll your own.