natbobc's comments

If this has a wifi antenna port would be very useful for marina wifi if you’re sailing around.

The article is comparing 2 scenarios that have other explanations: a fire sale of a large fleet and Tesla which has an image problem because of its leadership.

I’m not saying the article is wrong I’d just like to see broader representation (Chevy bolt, lucid air, etc).

A vocal minority are freedom loving. A significant number are hooked on consumer debt. I feel like any sweeping generalization is going to be wrong… especially when referencing the USA which is basically 50 countries and has a population exceeding all of Western Europe.

> I am a backend developer using Spring Boot and Java.

If your goal is speed to market use what you know which is Spring Boot and Java.

If your aim is to learn something new then go with Django or sprinkle in some Kotlin incrementally (eg tests). I don’t think it’ll matter in the long run which you choose.

Conflating I want to learn something new with I want to deliver quickly will give you a suboptimal outcome for both.

Feels like a bad point in the curve to try and sell them. “Oh our internal hypecycle is done… we’ll put them in the market now that they’re all worn out.

Probably that’s the scenario. You want something simple and narrowly focused. Advanced and infinitely configurable isn’t always a virtue.

Looks like a release about 2 weeks ago but otherwise not sure.

I find it mildly devious when numbers are inflated by changing the period from seconds to days.

Aeron and NSQ have slightly different design principles. Which can easily be identified in their feature list. Aeron’s origins are exchanges for fintechs and focus on predictable low latency with a tight standard deviation. NSQ puts heavy emphasis on being a distributed broker less message queue. Performance alone probably isn’t a good basis to measure their utility.

It’s all swings and roundabouts has been since the broad adoption of computers. I expect in a few years time when everyone’s forgotten the pain points that drove them to decentralize there’ll be a big move to centralize again. Someone will get a gold star for coming up with the idea and being able to demonstrate the “cost savings”. Of course it’ll completely ignore the general disruption to all of the product teams as they adapt to the new world order but what’s a company without a little busy work.

Everything’s benefits and tradeoffs. With this model there’s a clear ownership model. I’m not suggesting it’s right for everyone but it is a trend we’ve noticed with a number of clients over the last 2-3 years.

we have hundreds of clients most on k8s or openshift. Many of them are shifting to smaller team or division oriented clusters so that they can move at their own pace in consuming capabilities, tools, security practises, etc. It also simplifies distribution of operational expenses, yea there’s tools out there to help with that but it’s a whole lot easier to hand someone a sub-account in AWS and call it a day. Additionally it reduces your fault boundary. It isn’t as sexy as saying you have a 5000 node cluster with 100k+ pods running but it can make life a whole lot less stressful when it comes to upgrades and changes.

Phone autocorrect… thanks!

Comparing a single function to an entire ecosystem is crazy. Making an LTS imposes a skew of compatibility and support to all downstream vendors as well as the core team. The core team has done a great job on keeping GAed resources stable across releases. Understand there’s more to it than that but you should be regularly upgrading your dependencies as par-four the course not swallowing an elephant every 2 years or whenever a CVE forces your hand. The book Accelerate highlights this quite succinctly.

I would even go so far as to say free users aren’t customers in a platform like this. There’s no revenue model and if it’s “run without constraint” you get some fun scaling problems but those types of issues can sometimes lead to optimizations that keep the system online in the face of many small apps but doesn’t necessarily cover the case of a large resource app.

Thanks! Was faffing with it... the "help" isn't very helpful on how it formats. Sadly can't edit now. :/

It doesn't sound like a great situation to be in. It sounds like the founder has strong opinions. I suspect he subscribes to Trunk Based Development[1] and Continuous Delivery[2]. He also likely wants to follow the practises that "leading organisations" follow in "Accelerate: State of DevOps Report"[3]. You might find it beneficial to research those subjects prior to discussions with him.

  1 - https://trunkbaseddevelopment.com/
  2 - https://continuousdelivery.com/
  3 - https://cloudplatformonline.com/2018-state-of-devops.html

Agree in many cases you can do this however with point 2 the removal of a function(s) is literally the aim. The accretion of functions benefits legacy systems however its tradeoff is potential harm to users new and unfamiliar with the library. Accretion creates a cognitive overhead (even if only minor) for both the maintainer and new users. Maintainers when they return to code to update and modify behaviour. New users when they seek to understand the library through documentation, examples, and usage. I don't think it's coincidence that a number of languages and libraries acknowledge this by having "one correct way to do X".

Using a concrete example relating to security; libressl maintained much of the API surface that OpenSSL provides. In essence they aimed to provide a "drop-in" replacement. However there were whole families of algorithms and functions which they deemed "unsafe/unfit" for purpose (e.g. FIPS algorithms). I think that's a perfectly valid exception to the rule. It acts as a canary in the coal mine and you have options; fix your code or defer upgrading.

I would advocate for thoughtful deprecation cycles over ossification of poor APIs and algorithms.

I think the reference might be more in relation to OSS tooling such as docker, kubernetes, and a lot of the other stuff in the CNCF project catalogue which is often VC backed start-ups with OSS codebases.

To be fair I think most of the OSS languages are Cathedrals. Golang recently had an uproar over dep (community lead initiative) vs vgo (core committer). Ruby seems similar. With the recent departure of Guido as BDFL I think Python is the exception.

The low number of commits is somewhat intentional in that they actively avoid providing too much functionality in core and relative to Go which has the might of Google backing it there's fewer people with hands on who are incentivised based on innovation. It would be nice to see more frequent integration of commits from the community but ¯\_(ツ)_/¯.

there was freedom I feel Ruby had that Python didn't which allowed Ruby to successfully go from 1.8 to 1.9;

* Ruby had better dependency management. Python's only recently introduced Pipenv which provides a standard approach for managing development and prod dependencies. VirtualEnv's been around for a while but didn't handle scope.

* Ruby wasn't used as extensively as Python in stuff like system libs and start-up scripts so system packages weren't constrained in the same way.

* Ruby's ecosystem was more focused around web development. Rails in particular was fairly early in adopting new versions of Ruby within about 1 year of the release of Ruby 1.9. Django on the other hand was about 5 years before it had it's first Python 3 compatible release.

* "microbenchmarks" generally got better with Ruby releases whereas Python 3 seemed to have gotten worse from what I remember. I don't think microbenchmarks are terribly useful out of the context of an actual application but many people use them as indicators.

* subjectively I think the Ruby community was more committed to unit testing which made "fearless upgrades" a little more palatable.