I think the equivalent would be if New York Times is somehow owned by Tencent and given that the Chinese government uses golden shares to control private companies. In that case, I think it's fair game to force NYT to divest or force them to shutdown.
It's wonderful the world is big enough to celebrate whether you run a $45k/mo company solo, or find joy in nature walks, rock climbing, reading or raised VC to go big.
I have a MBA 16GB and everything is fine until I use Docker. It's under constant memory pressure and I was looking into getting a 32/64GB Macbook Pro 14 M1 Pro max. But really dreaded the additional weight/size of the laptop + 96W power brick which is an additional of ~2 lb
Specifically Clerk wants to address the following problems:
- Less helpful than my editor
- Notebook code being hard to reuse
- Reproduction problems coming from out-of-order execution
- Problems with archival and putting notebooks in source control
I encounter these problems every time I interact with a Juypter notebook and think about a Clojure style notebook environment :)
I have heard this many times from many different people that I respect. However, I'm just not experiencing "the joy" after several attempts. Maybe it's just not how my brain is wired.
It's probably not helping that I'm not starting from a greenfield project. Needing to go through and understand other people's code with an out of date Rails and its dependencies have made me spent most of the time on infrastructure. The entire test suite takes 50-60 minutes to complete with a lot of integration tests hitting the database.
Do people allocate a certain amount of time just to upgrade Rails?
It seems like there's an expectation that Rails is
1) used to start quickly with scaffolding (great for hackathons)
2) constantly running app and cared for to not diverge from the latest version
At this point, it's one of those love-hate dysfunctional relationship with Rails for me
> Do people allocate a certain amount of time just to upgrade Rails? It seems like there's an expectation that Rails is 1) used to start quickly with scaffolding (great for hackathons) 2) constantly running app and cared for to not diverge from the latest version
I once started an interview with the question... "So, what version of Rails are you stuck on?"
Rails is the only framework I've used much that's made me feel like regular upgrades are plausible/possible - things spit deprecation warnings, there are reasonable release notes, and most apps have decent test coverage so you can tell what breaks quickly and often fix it with little effort.
>Do people allocate a certain amount of time just to upgrade Rails?
Is there a framework or technology that doesn't need constant maintenance?
I feel like Rails is actually quite low maintenance. Major version changes are rare - Rails 6 was released in 2019.
Typed languages and explicit-over-implicit frameworks are much easier to upgrade. I worked on a large project based on Wicket and we would curse the library developers for making their classes "final" so we had to copy-paste rather than subclassing, but the result was that even major version upgrades were completely routine and painless.
The blockers tend to be the parts of "Java" that aren't actually Java and aren't typed, such as Spring or Hibernate. Blaming Java for that is correct - there's no point having a typed language if it's so inexpressive that people layer untyped hacks on top of it in order to be able to actually do anything - but blaming types is a mistake; if you use a language that is properly typed without compromising expressiveness (i.e. an ML-family language in the broad sense) then you can genuinely get that ease of upgrade because you don't have to step outside the language to get things done.
Moving from Java 8 to Java 11 or even Java 17 is surprisingly simple. Most of the work is just upgrading libraries which use internal JDK features or rely on brittle reflection/bytecode hacks.
Java is a specifically strange beast here. With many modern typed languages, a major version upgrade will require you to modify small parts of your code, as the compiler becomes stricter or small parts of the syntax change.
Java is more like C and C++, in that it tries very hard to maintain language level compatibility. On the other, library compatibility is a bigger mess in Java, because the language was pretty stagnant for such a long time, and library authors got used to a very slow upgrade pace. This meant many libraries and tools chose to rely on internal JDK implementation details or perform bytecode wizardry which stopped working with new versions. Java 9 also moved a lot of interfaces which were not an official part of the Java SE spec (like all of Java EE) to external artifacts which you needed to add as dependencies.
Another extreme point of incompatibility was very silly: libraries were making assumptions parsing the Java version string: up until Java 8, the version string had the format "1.x", where x is the major version (Java 8 was "1.8"). Starting from Java 9, there was no phantom "1." prefix coming before the major version anymore, so Java 9 was just "9". This broke a lot of libraries which would have been compatible otherwise.
Library maintainers were unprepared for the rather small changes Java 9 has made, and took quite some time to upgrade, especially huge frameworks like Spring. It took Spring 6 months to support Java 9 after it became GA, but Java 17 was fully supported 3 months before it was released![1]
If you have to upgrade from Java 8 to Java 17 now, there is nearly zero friction if your libraries support it and upgrading the libraries is easy. You'd barely need to touch your own code. If any changes are forced on you, that's usually the libraries, but then neither Java nor static typing is to blame.
And honestly I think it's quite easy to upgrade. In my experience, Java shops just tend to be more conservative than the industry average.
> using mostly the standard library without any framework
I don't think that's totally true. Without any framework, maybe, but mostly the standard library? I'm not sure. People use a lot of libraries, and these may not have the same guarantees as Go itself.
> Do people allocate a certain amount of time just to upgrade Rails?
Rails spits a bunch of deprecation warnings when stuff is changing. Usually it's just a matter of playing whack-a-mole with the deprecation warnings and walking through the upgrade instructions. It's a chore but it's not especially difficult, even if you're multiple versions behind (in which case you go should upgrade through the intermediate versions one at a time).
The thing that will save your bacon here is having decent test coverage, so you actually see those deprecation warnings :)
> I have heard this many times from many different people that I respect. However, I'm just not experiencing "the joy" after several attempts. Maybe it's just not how my brain is wired.
This has been my exact experience too. My current theory as to why it doesn't click for me is that it tries to be too much like English. Sure it's fun writing poems all day but try refactoring a poem someone else wrote with any kind of confidence.
That said I love that ruby and rails exist, it seems to unlock creativity in some people and that's awesome.
I think it would be useful to generate a regex - which would then get written down in the code to ensure it doesn't change? You could test it, ensure it works, then just use the output of the neural net...
https://en.wikipedia.org/wiki/Golden_share