Extremely exciting, in that there was a lot of demand for tech. However the hype was much like the hype around crypto or now AI. A lot of grifters and people who had no business being in the industry. However because the barrier to entry was a bit higher, there wasn't such widespread madness that is observable with the crypto and AI hypetrains. It was definitely a period where if you had an idea, there were a lot fewer people in that space, and both tech and business were less developed in the industry. So there was a lot more space to shine, but you'd have to do a lot more legwork.
I use the heuristic that if there are loads of billboards everywhere advertising stuff that should be incomprehensible to the layman, then things have got too frothy.
Big plug for logseq here. After trying Evernote, Apple Notes, Roam Research, Obsidian, and Logseq, I'm finally happy.
Obsidian has got strangely popular... but for me Logseq wins because of the block-based way of working (which Roam also has) is much more flexible. Instead of just making monolithic notes, you can measure data points, reproduce blocks, query data, etc. You are crafting from much more flexible clay.
I can interlink all around my knowledge base. I can, in my daily journey, add points under tags or headings, that I can then query in reverse. I can make pages from blocks on other pages. I can keep track of meeting types, specific meetings, individuals at them, topics, etc. It is flexible enough to be very powerful but also doesn't need me to make upfront decisions. I can just build things out day by day.
Has logseq changed recently? When I tried it, I really disliked the very rigidly based list style / bullet point architecture for notes. It works great for todo lists, but for longform journalism and notetaking was deeply unsatisfying.
I don't think obsidian popularity is very strange. It's got a very clean look to it, the search is very fast, it's very easy to interlink all of your notes together, it's got a graph builder, and it's trivial to write plug-ins in JavaScript and extend its capability.
I do wish it was open source – that's the only drawback to it for me.
By the sound of it, you'll still dislike it. It uses the bullet outlining, so definitely won't be good for longform journalism. Organising notes and research around that journalism yes, but not for the output.
Guess differences in approach make the world richer :)
Depends what you’re really paying for. If it’s about the IP, the market access, or a particular individual (seen this myself) then the rest of the org might be dead weight.
When I've been a hiring manager I have both used it and not used it.
It depends on what sources you have for your candidates; if you are doing your own outreach then it is invaluable and you'd be hobbled without it.
However doing your own outreach won't scale (i.e. if you need to hire a lot) and may not be a good match if you have other time-consuming aspects to your role.
Wow this kind of hit home! A lot of familiar ground. When I was 12 and living in San Diego I started a BBS, also using WWIV. Called Xcellent! BBS. When we moved back to the UK I tried to keep it going, but the BBS scene in the UK was a lot further back. I believe I had a connection through a friend to WWIVNET or something similar but I had to do that through a call to the US from the UK which in 1992 was ridiculously expensive so I stopped.
The only things those frameworks offered were compile-time dependency injection (Spring injects at runtime, and can make startup slower)... and support for building AOT native executables with GraalVM (Spring couldn't do that before because Graal has poor support for its reflection-based dependency injection).
Within a few months of Micronaut and Quarkus emerging, Spring started working on the "Spring Boot Native" project. Allowing you to build AOT compiled native executables with GraalVM. That’s now fully released for production if you want it.
Ironically, aside from perhaps some "serverless" applications where startup time is more important, the traditional JIT applications typically outperform AOT native executables. Especially in the kind of long-running server tasks that Java is mostly used for in the enterprise. This is mostly about marketing and appearances, because newbies see the eye-popping AOT startup times (for "Hello World" demo apps), and Spring has to keep up with those bullshit examples.
But the point is that Spring DOES keep up. The Java enterprise ecosystem is at a point where occasionally something new gets introduced, but then Spring adds support for the same thing within a year or two. Since "a year or two" is a snap of the fingers in the enterprise world, there's just little incentive to migrate just because a new thing is "cooler" on Reddit. Especially when the new things have a minuscule fraction of the community, working out the bugs and producing the blog posts and StackOverflow answers that you rely on.
Apparantly with the enterprise version of GraalVM which enables PGO, there's no longer any significant performance penalty, with GraalVM running at 97% of regular JVM throughput: https://www.infoq.com/articles/native-java-graalvm/ (section "Peak performance On Par with JVM")
The point is that most newbies don't understand the ramifications of JIT and AOT.
And assume that AOT is dramatically BETTER performing, based on overhyped startup time benchmarks.
You try to explain to people that once an application has been running for 30 seconds (or whatever), AOT will never be as good as JIT let alone better. And half the time, you just draw blank stares like the "But this goes up to eleven!" scene from "Spinal Tap".
Java (and to a somewhat lesser extent .NET) exist in a totally different social bubble. Because most of the students and early stage startup workers on Reddit and HN simply don't know what they're talking about most of the time.
I feel you about that startup time garbage. I did end up working on a GraalVM based Spring Boot app that was super cool as part of our business requirements were taking in user provided Python and Javascript code for execution and executing that code on incoming events, sort of like a rules engine.
Quarkus had a really annoying static only DB layer which turned me off.
Spring Data was way better with the interfaces.
I don't know if Quarkus changes recently (well, in 2-3 years) in that regard.
And 3 years ago it didn't support newer JDK versions, it supported up to JDK 11 AFAIR, while there was already JDK 13 or something like that. It was a bummer for a framework that advertised as hipster-new. AFAIK they migrated out of jboss library that was holding them back in newer JDK support but I was burned twice already and didn't want to give another try.
I really like a lot of the ideas in Quarkus. They also pushed for Spring Native which is an interesting new direction. But to me one of the biggest values is sheer traction. Spring controls the market completely. You have so many engineers with deep real world experience with Spring. So many books, blogs etc. When you run into a problem there's someone. When you need to hire, it's easy.
My biggest beefs with Spring is its use of Hibernate being a solution for late 90's EJB apps not well suited for shorter transaction scopes used today.
Sadly most Quarkus references seem to use Hibernate as default. Micronaut seems to be showing more choices, but then still Hibernate comes up more than others. Leaving Spring/Boot and keeping Hibernate isn't much of a change other than perhaps some possibly efficiency (e.g. startup time or infrastructure cost).
Quarkus just moves the problem IMHO. I find it similarly convoluted to use as normal Spring. I had to deal with that a few months ago on a project. Honestly, it actually feels a lot like spring used to be; and not in a good way. Lots of annotation magic all over the place.
I use Spring Boot by default. But I aggressively limit the use of annotation magic. I've never liked the byte code hacks people do to make annotations inject magical behavior. Hard to debug and painful when it does not work as expected.
I don't think either of these frameworks have an edge over each other. You end up using a lot of the same underlying library ecosystem.
I do like the annotation less direction that Spring has been taking since they started adding Kotlin support 4-5 years ago. If you want to, you can get rid of most annotations for things like dependency injection, defining controllers, transactions etc.
Especially with Kotlin, this makes a lot of sense. With Java, dealing with builders is just a lot more painful without kotlin's DSL support. You basically end up with a lot of verbosity, method chaining, etc. But it's possible if you want to. It's a big reason, I prefer using Kotlin with Spring Boot. Makes the whole thing feel like a modern framework. The hard part with Spring Boot is being able to tell apart all the legacy and backwards compatible stuff from the actual current and proper way of doing things.
There's a project that they've been pushing to get rid of all annotations: https://github.com/spring-projects-experimental/spring-fu/tr.... I suspect a lot of that stuff might be part of spring boot 3.x later this year. And quite a bit of it is actually already part of the current version of Spring.
This makes spring boot very similar to what you'd do with ktor. All you do is call kotlin functions. No annotations. No reflection. No magic. Very little verbosity. It's all declarative. And a nice side effect is also that it makes things like spring-native easier, which they started supporting recently.
It's very similar to using ktor with koin (for dependency injection). That combination is worth a try if you are looking for something lightweight and easy to use. Spring Boot has more features and complexity but it can be as simple to use as that if you know what you are doing.
Mostly, keeping things simple is a good thing with Spring. Also, I don't tend to do everything the spring way. Spring integration is a bit of a double edged sword for example. It offers a subset of the features of the libraries that it integrates. If you want the full feature set, you end up working around that. IMHO, you should do that by default. I've removed spring integration from several projects.
One of the things I believe the author is missing is flow efficiency vs resource efficiency. To reduce handoff and waste, sometimes the utilisation of a single resource may go down.
