Hacker News Reader

Intellectual is the wrong target, just as much as easy. Humans have a limited capacity to understand complex systems, and once they grow to a certan point, your ability to integrate and innovate on them is limited due to overhead of the layers of incedental complexity. Easy is just shoving complexity under the rug. Simplicity, and building systems meant for our meager human intelligences is better.

I am not terribly fond of Go, but it has a decent answer in auto-implemented interfaces and duck typing. It's not about dumbing down, it's just different, and easier on the compiler, which is a significant advantage.

And as for async in java... ugh, how awful. We finally got something like promises and lambdas, but most APIs are still trapped in synchronous calls and using the JPA is a disaster of hidden thread-local state. What kind of stack are you using to make java async work? Maybe I'm just missing something.

The thing is, the modern systems are often less complex. SQL databases are generally far simpler than MongoDB - you just need to learn relational algebra rather than blindly shoveling whatever JSON you got into the DB.

As for Java + async + threads, I use Akka and it's basically seamless. But Netty + core Java Executors is fine too, just more verbose.

> you just need to learn relational algebra rather than blindly shoveling whatever JSON you got into the DB.

No

SQL per se is not hard.

But the whole data modeling, creating tables, picking types is just needless bureaucracy

Yes, I want to save a json snippet and be done with it. I don't want to create another table because I have a 1-N relationship. And while ORMs make this easier it is still not painless

Schema-less data always sounds good in the beginning until you actually try to use that data. Then you end up encoding all the validation and data munging logic into whatever process reads from it.

An internally-schema'd database just recognizes that this is absurd and lets you put the bottom three layers of validation logic inside the database, where you only have to do it once.

> Then you end up encoding all the validation and data munging logic into whatever process reads from it.

Do you think that doesn't happen in regular DBs or that schemas don't evolve?

Love for static typing is basically Stockholm's syndrome

Your system will eventually end up with a fixed schema, but until you get to that place you don't need to "stop the world" to change it. "But Postgresql can add columns without downtime" yes it can, but what about your system?

> Love for static typing is basically Stockholm's syndrome

Funny, that's sort of how I feel about my (long) time "loving" dynamic typing. Now I find it is such a relief to validate data once on the way in and completely trust it to be what it says it is thereafter. I found dynamic types required more bureaucracy (if I wanted to sleep at night) in the form of unit tests and precondition checks everywhere.

YMMV I suppose.

> I found dynamic types required more bureaucracy (if I wanted to sleep at night) in the form of unit tests and precondition checks everywhere.

This merits clarification

Most of programming in dynamic typing should be implicitly statically typed. Know what you're passing. Obey the implicit (duck-typed) interfaces

Basically, don't just check "if it's a list do that, if it's one element do something else, if it's a number do another thing" - this is a beginner's mistake (and I did those)

Besides that, unit tests are a good idea, and if you want "compile type checking" in Python use Pylint (it's a good idea to use it regardless of your situation).

Though it's not so much static typing that sucks, it's its implementation in the Java/C++ way. Go and Rust make it better.

> Most of programming in dynamic typing should be implicitly statically typed. Know what you're passing. Obey the implicit (duck-typed) interfaces

Yeah, I thought that too. After years of persistently seeing stupid (sometimes critical) bugs due to assuming the correct thing was being passed, I concluded that 1. the only sane thing to do is add explicit precondition checks that raise meaningful exceptions when assumptions are broken, and make sure those paths are exercised by unit tests, and that 2. I would much rather have that done statically and automatically by a compiler.

> Basically, don't just check "if it's a list do that, if it's one element do something else, if it's a number do another thing" - this is a beginner's mistake (and I did those)

I think this may be a misunderstanding of what I meant by "precondition checks" - I meant explicitly checking the assumptions being made by a method, most of which are type checks (foo.kind_of?) or (more commonly) interface checks (foo.respond_to?).

> Though it's not so much static typing that sucks, it's its implementation in the Java/C++ way. Go and Rust make it better.

I don't have much problem with Java's implementation of static typing at all, and I don't think C++'s problem is its static typing implementation. I find Go's implementation a bit inflexible and hard to work with though.

Again, YMMV!

Akka doesn't solve missing asynchronous libraries. You still have to wrap JDBC requests in a threadpool, and are limited in how many database requests you can serve by pool size.

I'm going to fundamentally disagree with at least the target of Go. Go introduced a series of concurrency primitives with syntax that's made writing and reasoning about concurrent code a joy, something that's not the case in Java/C++/C/Python (maybe up till the late 3.X in the case of Python), and it did that with a language paradigm (interface driven) that's vastly different from Python's mixture of OOP and duck-typing.

And sorry, but "I wonder how much the industry could advance if we could simply persuade every developer to learn Java Postgres."?

Plenty of other people would say "I wonder how far along the industry would be if you people would actually learn how to manage your memory and write C".

Plenty of other people would say "I wonder how far the industry would have progressed if we let go of the harmful and outdated concept of imperative programming and embraced functional paradigms."

... and on it goes.

-----------------

Additionally, you say "I do find it truly sad how anti-intellectualism is pervading our industry" only to end your post with "why can't we abandon all our experimenting and learning and just stick to good old Java which obviously would solve all our problems", which is itself MASSIVELY anti-intellectual.

> "why can't we abandon all our experimenting and learning and just stick to good old Java which obviously would solve all our problems", which is itself MASSIVELY anti-intellectual.

That's a mis-characterization. There is a difference between experimenting and learning and pushing all sorts of questionable fashion trends into production.

While true, the "pushing" being done is a very small compared to only the "development" of said technologies. The exact words of the parent where:

> I wonder how much the industry could advance if we could simply persuade every developer to learn Java Postgres.

And that is preceded by what I can only described as a bunch of undue mischaracterization of several languages and technologies, all of which definitely seems to imply that "yeah, all that other stuff is just a bunch of fads, why don't we stick to the real deal and all write Java."

Now, I don't want to be unkind to Java here. It's true that Java is an incredibly powerful language and there are a wide variety of technologies and tools that are absolutely incredible that you can only get via the Java ecosystem. But that can be said of many languages, e.g. C++/C.

I think what the GP may have meant, and which I do agree with, is that our industry would progress if we as developers spent a bit more time learning about the context and history of current and past solutions. We'd probably re-invent the wheel a bit less often.

But I don't want to limit that recommendation to "learn Java Postgres". I think Java developers might benefit from examining the benefits of a language like Haskell, Python programmers may benefit from a language with strong typing, such as C++/Rust/Go, that Unix lovers might learn a lot from examining the Windows NT kernel API's, and so on. If we examine the things that aren't close to us, the things with which we're the least familiar, that's when I believe the most fruitful learning can occur.

I took the GP in a very figurative way as well. A lot of the learning being done at the moment though is simply framework churn, there are developers out their familiar with a million web and client side frameworks that would have been much better served learning SQL. Our apps would be better if we focused more and learning about usability and our users than on CSS compilers. As an industry I think we're under serving everyone right now, people have machines a thousand times more powerful than a couple of decades ago but what they can do with them is almost identical.

Go didn't "introduce" CSP or actor like primitives. Scala had actors in 2006, I think Clojure has for a similar amount of time as well. There have been libraries for it in Java and C++ also since the early 2000's and probably earlier.

Plenty of other people would say "I wonder how far along the industry would be if you people would actually learn how to manage your memory and write C".

I don't see the industry gravitating towards bad re-implementations of C with less functionality and a flatter learning curve. The only "replacement" for C that I'm aware of is Rust, and Rust is most definitely not anti-intellectual in the same way I criticize Go.

Rust actually requires the developer to learn new concepts (borrow checker) which are not found in C, Python, Java, etc.

"why can't we abandon all our experimenting and learning and just stick to good old Java which obviously would solve all our problems", which is itself MASSIVELY anti-intellectual.

I didn't say to end experiments. I said everyone should actually learn some fundamentals before jumping on low-learning curve bandwagons which offer nothing new.

> Rust actually requires the developer to learn new concepts (borrow checker)

Well they do not want GC for their language hence borrow checker while Go already has an excellent GC.

As opposed to learning new things we need useful new things which couldn't be done before fancy new language.

So what can you do in Go that you couldn't do (without a lot more difficulty) in Java or Haskell?

I just want to nitpick about Node a little bit--as a Java developer and Postgres user myself--because there is more to Node than just async JavaScript and I think it gets a bad rap a little bit because of that. Async is one good quality of Node, but it also has this really great debugging integration with Chrome DevTools. And even really huge Node programs start fast--usually in less than a second--so you get this really tight development feedback loop. So you have this overall pleasant experience of a great module system where mostly everything out there is already going to be async (less likely in Java), a REPL, a fantastic debugger and profiler via the Chrome DevTools, and extremely quick process restarts. I think for some people these qualities outweigh the lack of static typing and JavaScript language quirks (which a lot have been ironed out in ES6 and ES7 anyway).

Don't forget the proliferation of electron so no one has to learn a new language and desktop toolsets.

Just for kicks I wrote a desktop todo list in GTK and C, not tools I had extensive knowledge of ever and nothing recently. It was a breath of fresh air how simple it was compared to doing the same in modern frameworks. A single ~30 line function to create the gui and the rest held together with a couple of function pointers. It was faster (to write and run) and simpler than anything I'd written in years. More responsive than the most responsive web framework too.

But is it cross-platform (Win32, Windows UWP, OS X, multiple linuxes, iOS, Android) and most of that same code works on the web?

It's okay to bemoan Electron for being bloated but multiple balls have been dropped by OS and platform makers, GUI toolkit makers, language runtime makers, and that giant amount of missing glue inbetween, to get to where we are.

It's rather sad that Electron, out of all things, is the first thing to fulfill the holy grail of write-once, run anywhere, in a way that's good enough and palatable to the plurality of users' and devs' satisfaction.

Electron certainly isn't the first thing to give "write once, run anywhere", let alone good enough to satisfy users. I groan every time I download an app only to discover it's Electron based.

Java beat Electron to write-once-run-anywhere by a couple of decades, and still does in the sense that Electron requires you to make platform-specific builds of your app even if the core code is the same (Java gives you that option but doesn't require it, you can still distribute a jar or web start file).

Meanwhile, Electron has managed the feat of being even bloatier than Java is. The DOM was never designed for GUIs and the terrible performance of web and Electron based apps is a testament to that. At least Java apps tend to have meaningful menu bars and context menus.

Electron satisfies web devs who have either never written desktop apps in other frameworks, or did decades ago and think nothing improved there. They "satisfy" users in the sense that users are rarely offered any alternative so have to suck it up and tend to judge web apps against each other vs a well coded, tightly written desktop app (office suites being a notable exception).

> Java beat Electron to write-once-run-anywhere No , not on web.

You can run electron apps on the web? How do you deal with things like file system access?

There is local storage. There is Server side.

Yes, I used GTK2 which is cross platform (GTK3 isn't). Would work fine on Win32 (the only windows worth supporting), OSX and multiple linuxes. Won't work on android or iOS, but IME that usually sacrifices the dektop app anyway. This case would have been fine though if it were possible, the app was responsive enough to work on a nokia 6110.

The biggest takeaway though is how simple it was to build. If all platforms where that simple then having seperate UI code for each platform really wouldn't be that big a deal.

At the moment I'm somewhat hopefully the libui project (https://github.com/andlabs/libui) will be successful though. It's learned the lessons from previous attempts.

Did you blog/gist that example, by any chance?

I half wrote a blog post/angry rant over Christmas. I'd post the draft/source here, but my c is very rusty and I want to at least check for memory leaks first (no valgrind on cygwin) ;)

> Go's entire selling point is "faster than python, no need to learn anything new".

To me, Go's selling points have been numerous:

- Faster than python

- Statically typed/no runtime bundling requirements

- Easy access to concurrency/multicore scaling

- Excellent tooling and integration with programming text editors

- Great documentation

- Excellent standard library which you can treat as a continuation of your own program

- Great design with pragmatic choices (this one is subjective, I agree)

In short, there's nothing else like that out there. Without Go, I'd have been stuck with JVM, Haskell or Erlang for most of my projects. And I dislike all of them, so Go has been a godsend.

Incindentally, I also happen to enjoy working with Postgres and prefer it to any other database I've worked with (SQL or not).

You haven't laid out any concrete selling points for Go over Haskell or Java beyond "I dislike all of them".

Can you come up with any intellectual rather than emotional reason for preferring Go?

I can open a standard library definition and quickly understand what it does. If I try to do that with Scala or Java, my eyes just glaze over. With Go I often don't notice when I venture outside of my own program and into 3rd party library code.

It sounds like you just didn't out in the work to learn Haskell. The docs are fantastic, but they do assume you are willing to get over the learning curve.

I don't think you are really disagreeing with me - go does nothing new, just lower learning curve.

That's the problem, there's no getting over the learning curve when it comes to languages like Scala or Haskell. While you do get more proficient with time, you never get to the state where the language gets out of the way and becomes your friend instead of something you have to wrestle most of the time to enjoy the benefits it offers (which are also offered by Go, BTW).

I was disagreeing with your original statement, Go is not just a faster python.

> That's the problem, there's no getting over the learning curve when it comes to languages like Scala or Haskell.

How did you come to this conclusion? Based on your own experiences? If so, why do you find it reasonable to assert your anecdotal truth generally?

> enjoy the benefits it offers (which are also offered by Go, BTW).

Are you seriously saying Go offers the entirety of features that Haskell offers. So what, you think people are just using Haskell for no real reason?

> That's the problem, there's no getting over the learning curve when it comes to languages like Scala or Haskell

For you, maybe. For plenty of others, that's clearly not true.

> While you do get more proficient with time, you never get to the state where the language gets out of the way and becomes your friend instead of something you have to wrestle most of the time to enjoy the benefits it offers (which are also offered by Go, BTW)

Go offers weaker type-safety benefits that Java (with the benefit of less type-safety ceremony), much less Scala or Haskell (against which it has less ceremony benefit, because Haskell and Scala have reduced ceremony with stronger type systems).

Go doesn't offer the benefits Haskell or Scala (or Rust) do. OTOH, some people find it more intuitive, and it does offer different benefits which may be more relevant to some use cases. The sweet spot for Go seems to be the place where, before Go, you might use Python but be upset about performance and might use C but be upset about boilerplate; Go improves over the weaknesses of either on that border, while preserving most (but not necessarily all) of their strengths.

> Go isn't just a faster Python.

Faster (and more parallel) Python, less obtrusive C, lower ceremony and more native Java -- it's not just any of these, but they sort of capture its primary strengths.

Thanks for providing an anecdote which 100% supports the claim I made: that all Go provides is an inferior language that appeals to people who don't wish to learn new things.

I agree for most part but what is important is productivity.

Java ecosystem is just toxic waste full of abandoned projects, over engineering everything, crashing build because everyone use arbitrary versioning schemes, ring-fences code with licenses/patents and developers with C++ mindset.

Node.js is maybe build on top hack on top of hack. With some ugly code, lack of any abstraction, lack of sensible std library, debugging capabilities, minimal editors support and finally with package manager that cannot be trusted.

But I can build CRUD API working with any database under 1h in node.js. Where In Java I need to start with learning all maven quirks, write pointless JSON mappers and learn stupid annotations that every library introduce.

It's not anti-intellectualism -- it's complete and utter lack of knowledge transfer, coupled with young people's spirit being dampened by established practices that are 50% reasonable, 50% bullshit.

This, piled on with subtle ageism, ensures that any useful lessons learned will only be learned by the time it's too late, and there's a new group of can-do people who feel stifled by the combined wisdom of the ages, so they break off and do their own thing.

I wrote about this here [1] with nicer language.

[1] https://news.ycombinator.com/item?id=13022926

    Go's entire selling point is "faster than python, no need to learn anything new". In terms of language features it's again living in the 80's - Java got generics in 2004 and Java was way behind the times. In terms of speed it's worse than Java and Rust, maybe comparable to Haskell.

This is not true, go is generally slightly faster than java (while using less memory_ and slightly slower than rust. The garbage collector is slower than java's default collector but has better latency but java's gc can be tuned and go gives you better tools to bypass gc partially or entirelly.

Interesting idea, but perhaps it's also possible to look at it as the industry broadening. 40 years ago, you had to be pretty knowledgeable to get anything at all done with computers. These days, it's possible for more people to do things, and yet there's still a market for people who are deeply knowledgeable.

A lot of people don't care much about the tech, and just want to build something. If easier (for them) tech lets them, that's a win, no?

Of course... that's easy to say but harder to swallow when they end up building something, making some money, and then hiring a developer to clean up their hideous mess. I've been there too.

NoSQL's only selling point is you don't need to learn SQL? Hardly true.

Major Oracle shops aren't dumping them for Mongo/Couchbase/... because they're trying to avoid SQL. They do it for scalability, availability, performance, flexibility and more.

I don't see that the facts in the real world back you up here.

Not claiming NoSQL is a panacea. You're definitely making some trade-offs, and in many cases it's just the wrong tech. But it's absurd to say it's happening to avoid a learning curve.

I didn't say that was NoSQL's only selling point. I said that was MongoDB's only selling point.

> Isomorphism simply didn't work.

Care to elaborate? I'd really like to know your opinion as this is an important aspect of my developer-life.