Hacker News new | past | comments | ask | show | jobs | submit login
Jodd – The Unbearable Lightness of Java (jodd.org)
219 points by tilt on Mar 27, 2015 | hide | past | web | favorite | 108 comments

I think there is a huge need for these kind of frameworks. They combine the convention over configuration productivity and tooling that rails and its clones provide, while letting users tap into the massive java ecosystem. Others like this include dropwizard and spring boot, but there's always room for more.

Java ain't perfect, but a lot of hard problems have been solved for the ecosystem and building on top of those solutions will save teams time and money.

Java's enterprise system has actually trended towards the convention-over-configuration of RoR since it was heavily revamped as JavaEE 5 (and obviously renamed). JavaEE today is heavily dependent on meta-programming and containers like TomEE and JBoss can be built in minimal configurations.

I think Jodd is interesting in the same way NodeJS is interesting. If you're more comfortable building your framework from the ground up, you end up adding only those pieces you require. If you're happier having an entire application server at your beck-and-call, start with a full application server and (if necessary) remove what you don't need.

That's the same reason I use JRuby so heavily - I can use the entire Java ecosystem, while claiming the productivity benefits of Ruby.

Same for myself and Clojure. Better coding productivity, easy Java interop for more libraries, and the deployment story is a no-brainer.

Me too. What I like about Clojure (and other JVM languages) is that I can choose how much I want to take part in the JVM ecosystem. There is usually a spectrum from pure-clojure <---> clojure-wrapping-java <--> pure java and I get to choose where on that spectrum I want to or need to be based on the needs of my project.

Since the Java ecosystem is huge, this gives me a lot of confidence that most of my needs will be met by existing tools.

I haven't done much with the other JVM languages except play around with them (did work with a small jython project about 10 years ago...). Have you encountered any impedance mismatch? Or weird cross language bugs?

JRuby converts values (Java primitives <-> ruby Numeric, java.lang.String <-> ruby String, etc.) sometimes with unexpected results.

JRuby does not wrap primitive values, or provide values that behave like primitives, but you can add that: https://rubygems.org/gems/infraruby-java

I'm not sure why I would need this when Java EE does most of this already. The Enterprise Edition has made a lot of progress with version 6 and 7 and greatly cleaned up the XML descriptor nonsense and instead relies on convention over configuration and annotations where necessary. Things like CDI for DI, JAX-RS for webservices and JPA for persistence just work out of the box with minimal configuration. As far as web pages go, JSF works well and is nicely integrated with the other technologies. But server-side web applications are obviously outdated in 2015, you could easily get something like Angular to work with the Java backend and ditch JSF.

Your comment should have been the first one of the discussion page! because it's nice that there's a default standard like Java EE.

However... What's painful with Java EE is the time it takes to understand it. Please correct me if I'm wrong, because I've never got around it, but it takes 5 years of experience to build an app using CDI, JAX-RS, JPA, JSF, JNDI. For each of them you need to choose the implementation provider (Hibernate, Jersey if I'm correct?) and configure it, then you get bugs like the application isn't aware of your JPA and you don't know why, because the spec is circonvoluted enough to be powerful but then takes months to understand. Whereas some frameworks like Play Framework can be learnt in 2-5 months.

This is my feeling about Java EE, but have I been in bad luck with my experience? Is it supposed to be quick to get a canonical-JEE app running?

To understand JEE you first need to align with the motivation for the platform: distributed component oriented systems for an heterogenous enterprise environment. The second preliminary is to fully grok why indirection is necessary for loosely coupled component systems. JEE is built on a set of canonical indirection layers.

The rest is simply a set of orthogonal specs -- none in anyway intellectually or technically challenging. Building a tutorial full stack JEE app should let you see and touch most of these layers from client to backend.

It is a good thing that the new hotness in coding is ignoring JEE ..

> For each of them you need to choose the implementation provider

... or simply use those that come with your certified application server.

> I'm not sure why I would need this when Java EE does most of this already.

Exactly. Many people simply don't know what they can get out of the EE box. Even self-proclaimed EE experts never heard of e.g. Web Profile.

Big kudos to whoever is behind this framework for the excellent documentation and the funky site.

Still, I doubt I would use Jodd in a new project. The core components (MVC and data access framework) are completely new to me. It seems that they are developed by the same people behind Jodd. I don't particularly like Spring MVC or Hibernate, but Jodd libraries don't seem to be widely used (only 22 questions on SO and no forum or mailing list).

Beside the poor adoption, from a cursory look at the documentation, I couldn't find any striking feature. Actually the DB mapping module seems quite convoluted.

Also, I don't get this strong emphasis on the framework being "lightweight". Who cares if my project uses 3MB or 20MB of libraries?

As others pointed out, also take a look at Dropwizard and Ninjaframework.

> that they are developed by the same people behind Jodd

Same person:


Mr Spasic seems to be something of a virtuoso!

I love this. Java may be verbose at times but it's still very easy to understand, fast and stable.

Java is verbose for a reason. It is easier to modify and run code that is written decades ago. It still works.

Being concise is good for the first time. If someone needs to fix the "concise" code years later, the only option may be to throw it away and write it again.

This is not about conciseness, it is more about lack of language evolution. Older, purely functional haskell ocaml or scheme is quite readable and quite concise.

The main place where older code in readable languages (e.g. not J, common lisp, Perl) becomes hard to read is when new language conventions have replaced the old.

You should temper that first sentence with an 'only'.

I completely agree that much of the verbosity allows the language to express more, e.g. looking at a method signature in Java I know its visibility, what (if anything) it will return, what types I can/should pass it, and what exceptions it can throw...compare that to Ruby where the signature alone doesn't tell me any of that.

But there's also a lot of verbosity that adds no (or very little) value, e.g. System.out.println() instead of something like just println() or the several lines of boilerplate needed to run something in a new thread.

Java desperately needs more of this. It's a good language and a great platform. A lot of people don't want to look at it because they've heard (or experienced) horror stories about the huge frameworks. Enterprise development doesn't have to be that way!

I've long thought the same about C#. I haven't worked with in years now but I loved it when I did, and thought the reputation given to it by horrific enterprise development was never deserved. You can be amazingly concise with that langauge.

I just got use it on Linux via Mono and gotta say, it is a pretty nice language. I used to dismiss it because of Microsoft's influence and its being tied to thier .NET. But recently due to Microsoft open sourcing part of it, hopefully Mono will pick up some more change, and I think there is some space for server side C# on Linux.

We're bringing CoreCLR to Linux/Mac (in the open) as we speak so hopefully you won't have to worry about ever being a second class citizen.

We, another team not related to Locke1689, are bringing the CoreCLR to FreeBSD. 'Gotta prevent linuxims like #!/usr/bin/bash from infiltrating the codebase.

Discussion and project planning is happening here:


If you want to help out make sure you stop by and say hi :-)

What happens to Mono then, are you talking to them?

The .NET team has always been on friendly terms with the Mono team. I'd imagine the Mono devs will either keep doing their thing or will merge into the mainline at some point. There's Java VMs that are even commercial, as in people pay for them. I'd imagine that there's certainly enough space for a couple competing CLR platforms.

Merge - Xamarin are getting out of the language game and instead focusing purely on mobile. As much as possible the new MIT licensed .NET will replace pretty much all of Mono that isn't Mobile (iOS/Android/Mac) related.



mono + .net are merging, see the following Trello board to track the status https://trello.com/b/vRPTMfdz/net-framework-integration-into...

If you ever come back to C#, make sure to check out http://reactiveui.net ;-)

if you ignore webforms C# doesn't have the "bloat load" Java has really.

Yeah but no. You know those fancy FRP frameworks, ever wonder where they got their inspiration from?


Such as...?

Oh I agree with you, C# is definitely a nice language as well.

I don't know about that.

Bloat bothers me, but it has benefits too.

Why is C++ so successful? Because it contains a lot of features. Ask random C++ developers what their favorite feature of C++ is and you will get a very wide spectrum of answers.

I see Java libraries a bit like this: they are not liked because of the number of features they have but because I definitely need some of these features, and as long as I can use them without having to understand the rest of the library, I'm good.

Guava is a very good example of this: an assortment of convenience functions from a very wide range of domains that you can use without ever having to read or understand the entire Guava documentation.

Having small libraries is pretty much a guarantee for subtle bugs because the author went for the 80%/20% approach and then moved on to the next project. Joda is a good example of that: time libraries are extremely difficult to get right, and yet getting them right is absolutely critical. I will gladly pay the price of including the entire Joda library in my application even if I use 10% of it just for the certainty that it's battle tested, something I very much doubt the collection of libraries presented here does.

Ask random C++ developers what their favorite feature of C++ is and you will get a very wide spectrum of answers.

That's what is always said, but is it actually true? I think a couple of answers will be prevalent and at the top of the list:

- Deterministic destruction

- Manual memory management / no GC

- Templates

- C interoperability

Would be fun to actually do such a survey and see if there is more spread than other languages.

I'd also add operator overloading, though that tends to go hand in hand with templates. The fact that I can write numerical code that works for say, any type that implements addition and scalar multiplication, is wonderful.

In Java, as far as I know, this would be utterly impossible, because implementation of interfaces must be explicitly mentioned. Even though Double implements addition and scalar multiplication, it could not be used in such a function because it doesn't explicitly state that it implements such an interface.

If I wanted to learn more about web development in Java, what's a good starting point? Something that can give me a high-level overview, current best practices, and perhaps a simple "Hello World" example.

I currently work with Django and Wordpress, so I'm not totally new here. But last time I dived into this world, I could not make heads or tails of it.

Java seems like a powerful tool to have in your toolbox, but from what I've found it does not lend itself to be easily picked up.

One word. Dropwizard.

edavis asked about web development. Dropwizard was built for web services. There is a bit of a difference - user-facing web apps need to do templating, authentication, session management, etc.

I see that there is a Dropwizard module for templated views, which looks reasonably nice:


I'm not sure how well it supports the other aspects of a web application.

Spring boot.

Spring Boot certainly makes it very easy to get started, and to grow your system in the way that Spring envisions. For getting started, there's even the Initializr:


However, as soon as you want to go off the beaten path (eg to have two databases), Spring starts to become an obstacle rather than an assistance. In this respect, it's similar to Rails or any other large, opinionated framework.

I love spring boot. I use two databases and solr. It's easy. And fun.

Definitely Dropwizard or Ninjaframework

Spark java is a good Sinatra-like framework.

Do you want powerful jvm environment and exceptional java ecosystem? Do you want a java-like language (easy learning curve) but want to write less and in a more elegant way? Do you want a powerful scripting language? Do you want to work with consolidated technologies like hibernate and spring but in a more comfortable way? So why don't you choose Groovy and Grails?! I've been working with it for the last 2 years after many years as a J2EE developer and now i can't think to start a J2EE project without it!

Because it's slow. Even slower than Scala - esp. on the build side.

I generally choose Grails (although the move to 3 is going to be a bit bumpy without all the plugins from the 2 field).

The primary deficiency I've found is startup time - when I move to other systems, I remember - oh yeah, projects can start up immediately, or in < 3 seconds, not 50. I know 3 is better in this regard, and I'm looking to migrate one project to it next month.

Grails never got the mindshare because it was jumping in to a full ecosystem. Rails, by comparison, was essentially the only game in town if you wanted to do Ruby - there weren't any other major competing frameworks.

The other big strike against Grails is... "it's different!". Most shops that are large enough to see big benefit from Grails and similar frameworks also tend to be rather stodgy and slow to change (perhaps with good reasons, but slow anyway). The sort of people who champion 'new' tech largely migrated away to completely other ecosystems (rails, node, etc). Grails/Groovy are 'different' in a scary way for "slow to change" shops, and "not different enough" for the folks who are always looking for "new/shiny" stuff to dig in to and promote. It was/is too "middle of the road", I think, to benefit from the advocacy often required for adoption. And in a crowded JVM-tech field, that hurts.

That said, it's still a great stack, and I still recommend it for many situations.

Groovy is much slower than Java, dynamically typed (even with optional typing), with spotty IDE support and with Thoughtworks recently dropping its support of the entire project, the future of the language is quite uncertain, even though it was picked up by Apache.

I would feel more comfortable picking Kotlin despite its newness: it has everything Groovy offers but it also fixes all the problems I listed above.

Some people like java.

BTW, J2EE was replaced with Java EE in 2006.

Groovy and Grails have lost their reason for existence years ago, and without the sponsoring they are both dead.

What reason is that?

They're an Apache supported project now. http://adtmag.com/articles/2015/03/04/groovy-joins-apache-fo...

The Codehaus implementation of Groovy was only voted into Apache a week ago, and still needs to complete the infrastructure conversions which could take months, or longer if problems surface. Its project manager Guillaume Laforge has been making fraudulent claims about the consensus of the "Groovy Community" on joining [1]. He's redefining "Groovy" to be whatever's in their particular codebase, instead of a reference implementation of a spec as its creator James Strachan asserted right up to his last ever posting on the Groovy mailing list [2]. From there, Laforge is redefining the "Groovy Community" to be whoever's committed to that codebase, instead of whoever's contributed in any way to Groovy, including people who've haphazardly worked on other implementations of Groovy and those who've mainly written documentation. To further support his new narrative, he recently withdrew from the expert group and lead role on the JSR-241 [3] that defines a spec for the JVM version of the Groovy Language. I suspect the Apache mentors of Groovy such as Roman Shaposhnik, Bertrand Delacretaz, and Emmanuel Lecharny might not fully realize the fabrications they're dealing with.

[1] http://thread.gmane.org/gmane.comp.apache.incubator.general/...

[2] http://groovy.329449.n5.nabble.com/Paris-write-up-tt395560.h...

[3] https://jcp.org/en/jsr/detail?id=241

there is one thing you can be very happy about... there is no Project Lead in Apache Projects, right?

Whether someone's called a Pivotal Project Manager, an Apache P.M. Committee Chair, a Codehaus despot, a JSR lead, or whatever, if their skills are managerial rather than technical then they generally end up relying on having the best title and position rather than what they actually do to make the product be the best possible.

As for being happy about something, if Groovy development is being effectively led by its technical people as well as not being dictated to by the applications using it, then I'd be optimistic for its future (the Codehaus-cum-Apache implementation of it anyway).

> What reason is that?

Groovy made Java slightly less painful too use, but added its own warts.

Today we have languages which are better than Java without adding all of Groovy's mistakes.

> They're an Apache supported project now.

You mean the place where software projects go to die?

< Groovy's mistakes

Care to elaborate?

People interested in 'lightweight' Java EE should check out Adam Bien's web site: http://www.adam-bien.com/roller/abien/ . He energetically promotes modern lightweight EE (especially for startups). He overshoots the target sometimes (being too simple) but it's always interesting and entertaining.

The premise of "micro" anything in Java sounds attractive. I think the JVM is awesome, but often times I go back and forth on my enthusiasm about it because my recollection is that most things implemented for it end up being bloatware (think Eclipse). In the back of my mind I can't stop thinking any given Java app may be using n times more memory than necessary [1].

By the way, I think they went overboard with the marketing. Jodd libraries are all of: efficient - elegant - fast - lightweight - micro - powerful - slick - super - tiny - versatile. It is almost like they picked a random superlative for each piece. I get the point! I see lots of projects going this route on their marketing materials and it ends up being a bit annoying.

1: http://stackoverflow.com/a/632525/855105

I don't think Java lends itself very well to doing anything light or micro by design. However, it's perfectly possible to have lightweight stuff on the JVM, Luminus http://www.luminusweb.net/ is a good example for Clojure.

Cool, Luminus is micro, lightweight, robust, and scalable.

Sorry, I could not help myself :-).

I think it would help if people backed their claims with some actual data: a memory/CPU/lines-of-code comparison against mainstream alternatives or standard libraries.

Well, the docs do start with a walkthrough of a simple application: http://www.luminusweb.net/docs

You can really judge for yourself how it compares to the alternatives you're familiar with.

In terms of memory/CPU there are plenty benchmarks out there such as the benchmarks game site http://benchmarksgame.alioth.debian.org/

A small Luminus app will take around 100megs https://groups.google.com/forum/#!topic/clojure/mQbcz82I7iI so that's pretty lightweight by most standards.

In general though while people seem to be obsessed with benchmarks of all kinds, performance is simply not going to be an issue for the vast majority of sites out there. The real question is how productive your stack is and how easy it is to work with.

How can someone can claim something written for JVM such as clojure is lightweight? At the same time saying java itself is not-weight?

Clojure lets you write code that's much closer to the problem domain, with a lot less boilerplate.

The JVM doesn't automatically mean something has to be bloated. A small Clojure web app will compile to a roughly 30 meg runnable standalone jar. That's pretty light in my book. On top of that, you get excellent performance.

I would still recommend going with http://www.ninjaframework.org as it is a lot more complete

Full ACK!

How does JDateTime compare with Joda Time? Date and time classes are extremely tricky to get right, and Joda has been working on it for a long time.

JDateTime appears to be very minimal:


And to repeat some of the mistakes of the past, such as having the classes be mutable, and not separating zoned and unzoned times. It also contains some novel wackiness of its own: new instances of JDateTime take default values for some settings (time zone, whether date arithmetic should be clamped to valid dates, etc) from fields in the class JDateTimeDefault; but these fields are static, not final, and public, so any code in the JVM can change them, thus changing the behaviour of JDateTime objects created by completely unrelated code!

As of Java 8, there is a pretty comprehensive and well-designed date-time package in the JDK:


That package was designed primarily by Stephen Colebourne, who designed Joda Time, and essentially constitutes the Joda Time: The Next Generation. I don't see any reason to use JDateTime over this.

It's only the third date library in the standard java runtime, maybe they will get it right this time :P

> Jodd is set of Java micro frameworks, tools and utilities, under 1.5 MB.

Curious, what do they mean by 'micro'?

"Doesn't have all the features that I think are unimportant."

I think the basis for comparison is spring, which has a sprawling API. That is the 800lb gorilla of java frameworks.

And as always when someone posts this - we are at Spring 4 now, update your funny bookmarks.

Here you go: http://docs.spring.io/spring/docs/4.1.6.RELEASE/javadoc-api/... http://docs.spring.io/spring/docs/4.1.6.RELEASE/javadoc-api/...

These are framework classes that you will never have to see or use when building a Spring application.

Spring is surely not perfect, most people don't have the slightest clue what a modern Spring Application (read into Spring Boot) looks like.

This is what happens when you take something good (patterns) too far, and then keep going.

Modern spring is amazing. Look into it. It's no longer the configuration hell it was 10 years ago. Everything is convention Over configuration. It's easy to run and configure.

I've started using java just recently, spent years in C/C++/etc... So is spring the java equivalent of boost?

Not quite. Although i don't know C++ well enough to be sure.

Spring started life as a dependency injection framework, and that still constitutes the central part of it. Dependency injection is the mechanism by which components of an application are created and assembled, and so there was a natural expansion of Spring into providing those components. Spring now provides a web framework, plumbing for database persistence, batch processing, and all sorts of other things:


AIUI, Boost is a collection of libraries. Spring is much more frameworky than that. The general approach with Spring is to add a particular module to your project, sprinkle a few magic annotations on your code, then watch in wonder as lots of sophisticated stuff happens, exactly as Spring's designers foresaw. Usually.

There are two main alternatives to Spring. Firstly, Java EE, which is similar in spirit, smaller in extent, and the product of a decades-long standards process involving some of the world's most ponderous companies, but really not as bad as that might suggest:


And in fact, i'd describe Spring as an alternative to Java EE, rather than vice versa.

Secondly, not using a framework at all, and just putting everything together yourself. To a large extent, Dropwizard etc are the result of people doing this, then posting the reusable bits of their application to GitHub.

Java's equivalent of Boost is probably some combination of Apache Commons:


And Google Guava:


The difference is that if you're using Spring, then you are writing a Spring application. Every part of your code will be pervaded by Spring, and you will have to do things in the way Spring prescribes. If you're using Commons or Guava, your application is your own, and those libraries will crop up here and there, where you choose to use them.

These things actually exist?!

They do, and I think more unsettling is the fact that they are completely serious about doing these things. The widespread use of IDEs that autocomplete probably leads to a feeling of indifference ("I don't have to type it all anyway.")

Also related is the forced convention of requiring one directory nesting level per package name component, resulting in deeply-nested mostly-empty directories that have a tendency to easily exceed filesystem limits.

Here's another ridiculous class name found in different project (AspectJ):


Really accurate methods names are a Good Thing, because you are less likely to be surprised at what they do.

AbstractProxyFactoryBeanInstanceSingletonCommand is not, because it is too abstract. Typing the name is not so bad though.

Words cannot describe...

I am a Java programmer and I consider Jodd micro. YMMW.

that's exactly what I thought. What I would like is something like those JS frameworks where you can choose what you want and generate the lib that suits your needs.

Customisation over configuration.

> Customisation over configuration.

Composition over Inheritance.


When using maven you can pick and choose the modules you want.

I know, I was talking about having a simple ui where you check check check and "pom" you have the libraries that you want.

Edit: The ui generates the dependencies for your pom. I know how maven works, and it's a pain to copy all those xml snippets in your pom.

But... that's the point of Maven and other package managers. Why does it need a UI like that? Unlike JS, the tradition in Java development is to use managed dependencies rather than download JARs for everything and throw them in /lib.

Maven needs a UI because of its pathologically-verbose XML syntax. Compare a pom.xml with its Gradle equivalent...only one is designed with humans in mind.

Which is why I said "and other package managers." My point was that a UI like the one to build a custom Bootstrap download doesn't make sense in the Java world because we have package managers, unmanaged dependencies are not the norm in most projects.

Most IDEs will let you search Maven Central in a UI and add those pesky snippets to your pom for you.

Cool, how does this compare to DropWizard?

I know DropWizard is like a distro of select "best" projects out there, glued together with some configuration and instrumentation code. That makes them easier to use while leveraging the battle-tested-ness of established libraries like say Jackson for JSON.

Is this more of a "built from scratch" set of frameworks? How battle-tested are they?

DropWizard is mostly meant for creating a set of conventions to production-ready applications with operations-friendly things like instrumentation hooks. Jodd is oriented more around simpler libraries for doing what people have oftentimes used heavyweight frameworks for (not in terms of performance though necessarily but in terms of mental efforts and scaffolding required to get a MVP out the door). You could use both frameworks together because they have almost orthogonal concerns and both being minimal don't step on each other's toes.

Jodd in itself could work for not needing an app container by using something like Winstone (Jenkins is built with it) for deployment models closer to systems like node.js or Flask and Sinatra that emphasize minimal scaffolding to make it easier to horizontally scale a system by just deploying more dumb nodes.

I've seen Jodd used in production systems and just never seen a stacktrace fail to that point so far. I've only ever seen application code fail in itself or fail due to a side effect or misunderstanding of the underlying libraries. I've seen FAR more bugs due to the ugliness of the old Java dateutil libraries than Jodatime, for example, but would we argue Jodatime is more or less mature?

Maybe I didn't answer your question but I'd say if you're looking for super stable libraries I'd argue on a time basis alone to just use core Java then. The very point of minimalism from a reliability perspective is to reduce points of failure in code with simply less parts. And really, with the number of deployment headaches I've had resolving random classes across an app container, I could take one less transient dependency in my project.

> I'd say if you're looking for super stable libraries I'd argue on a time basis alone to just use core Java then.

Thanks for your reply but I didn't understand this part of it. Core Java doesn't have a lot of this functionality. Are you proposing it would be better to write your own JSON serializer in core Java, for example, than using a battle-tested library like Jackson?

I'm arguing the opposite - if you want stability and time-proven code, you will find the most boring, standard library possible. So, you'd pick Jackson for JSON serialization over, say, GSON. But taken further why not just go back to C... Or COBOL? We have to trade off some stability through age for some newer code that's got better potential. Reinventing the wheel should be discouraged only on the basis of it not being tested as well in the fires of production use, not so much for being actually redundant. How many of us would write exactly the same hashing library if we were told to do it repeatedly?

So in a scenario like being stuck with Java 6 I'd say you could use libraries like Jodatime and Jodd to make up for certain inconveniences, but it's up to you to decide if your application is fine with the AOP in Jodd v. Guice v. Spring v. whatever J2EE standard is trying to catch up after the fact.

> Designed with common sense

Disclaimer: I have nothing to do with this project.

It looks interesting though.

> Proxetta - the fastest proxy creator with new, unique approach for making pointcuts and different type of advices.

Man, this just sounds so lightweight!

I used Jerry at work and it's really one fine HTML parser. I like it better than JSoup, although it works a little bit weirder. :D

Are all the libraries together, combined, under 1.5MB? Or is each one under 1.5MB?

All together :)

Some day, in the distant future, 2015, development of all new startup projects' descriptions, documentation, websites and source code will be automated using Markov chains. The projects' half-life will be a strong function of its position on the Hacker News Front Page. After dropping out of the top 30, the project immediately decays into an EOL abandoned repo in an archive no one will ever look at.

The conspiracy, what most people know is true yet are afraid to admit, is that the Markov chains are trained entirely on past failed code projects. Like cows chewing their own cud, like dogs lapping up their own vomit. Soylent Green is People and Libraries are Pure Virtual.

____ is set of ____ micro frameworks, tools and utilities, under ____ MB. Designed with common sense to make things simple, but not simpler. Get things done! Build your Beautiful Ideas! Kickstart your Startup! And enjoy the _____.

is this the future of technology, or has the future already arrived

I have some free time today (kids stayed over at Grandma & Grandpa's last night, and wife is at an event all day), so I decided to have some fun, running with your idea to create a Twitter bot that generates “Show HN”-style headlines:


I decided to do a more rigid Madlib-style generator. Perhaps someone wants to use Markov chains to generate the page bodies for these headlines.

A shame that you didn't decided to make this very insightful comment on one of the "Library ___ in [Rust|Go]" threads. I'm not trying to bag on anyone, just want us to maybe consider that there is some sort of "underlying" malaise that is causing us to invent, and reinvent constantly. Is it due to us simply wanting to reinvent things, or perhaps due to libraries/frameworks eventually becoming too big that we need to reinvent it in smaller forms and new languages? I don't know, but it needs to be discussed...

People are building those things in Go and Rust because they're currently implemented in unsafe languages like C/C++ and are therefore riddled with undiscovered memory management bugs, overflow bugs, undefined behavior etc, which are often security vulnerabilities waiting to be exploited. I don't think it's reinvention for reinvention's sake, I think they're genuinely trying to fix some of the horrible historical mistakes of C.

"Is it due to us simply wanting to reinvent things"

After observing myself and a couple of developer friends over the last few years, i can most definitely say yes. We are addicted to building our own things, creating layers after layers of abstraction, frameworks, tools, because it makes us feel like we're creating something.

What saves some of us, is to have a greater satisfaction seing someone else actually use our things, than creating that thing. And so the goal becomes more "what do people need" rather than "what would i have fun building today".

To be fair, the Java ecosystem is quite mature, whereas Go and Rust are relatively young languages, and we still need people to develop all the amenities of modern programming for those languages. Yet Another Java(Script) Framework is more deserving of that sort of comment than The First Couple of Rust|Go Frameworks of Their Kind are.

I think I can attach another insight into this. The underlying malaise is probably related to the human condition. Humans are fundamentally a medium for our collaborative works (in this context) and two factors causes these rebuilds.

1. A need to cut your teeth on a solved problem when diving in to a new category of thinking.

2. The high cost of transferring a model of thinking between two humans, especially over a vast amount of time. I think 3 years is vast compared to maybe 100 work hours to model and implement the core of a problem.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact