Hacker News .hnnew | past | comments | ask | show | jobs | submit | lateefj's commentslogin

Most ORM's are evil. sqlachemy being the only one that I can think of that is not evil (assuming you don't use the object mapping feature). I have found time and again that ORM's create unintended consequences in productions. Generation after generation of ORM's I have dealt with always have the same problem the create N+1, bad queries, memory bloat and are horrible to deal with in production. Once almost all the database operations are replaces with hand writing queries the application performance as expected. It is amazing to me that even though experiences engineers who have had ORM failures continue to use them. Some of have found that the cost of ORM is greater than the benefit and prefer simple libraries.


I think the real reason is that if you are using an ORM, then you should have probably used a non-relational database.


Author here. I was comparing things that I have developed software in. It would seem unfair to compare things that I have not actively contributed production code and deploy. I mainly write web applications (services) of which C++, Rust, Haskell or Lisp/Scheme are not languages I find compelling to write web applications with. Would love to hear if you find this otherwise.


No, I honestly know next to nothing about web apps programming. I do know there exists decent-looking support for web apps for Rust, Haskell, and Scheme (Racket, but Racket isn't compiled to a binary), but I don't have the knowledge base to assess how good web programming is in these languages, if it's even good at all. I know this website is written in Arc (a Lisp). https://github.com/wting/hackernews


There are some nice things about writing web apps in Lisps, since one can represent HTML as s-expressions, e.g. (:html (:body ((:p (:class "main")) "Foo bar baz."))). And of course macros mean that one can create nice abstractions quite difficult or impossible in other languages.


Sorry for the confusion JVM = Java Virtual Machine, RVM = Ruby Virtual Machine, PVM = Python Virtual Machine. What I was trying to point out the layers of vitalization just to run an application. Docker is yet another layer on top of the operating system (a virtual machine running inside an operating system inside an operating system possible ect).


Ah, ok. I can see where you're coming from, but I don't really think of Docker as being an extra layer on top. It's more a way of rearranging the OS layer itself along a certain axis. The cognitive overhead is similar to a virtualisation layer though, so that point stands.


Not sure I follow? With Go we develop on Mac and deploy on Linux. Just change the environment variable. Linux has some great built in tools for "security management".


You have to recompile for another platform. There may also be subtle differences in the platforms.


There are some subtle differences.... but these would likely be exposed in almost any language with or without a VM. For example, when porting some of our Linux Go code to Windows, we realized we were renaming a file while we held the file handle open. That works fine on Linux, and blows up on Windows. That's not really something a VM can manage for you. Similar things like "what's the canonical directory for storing your ssh configuration" is different per OS, and again, is not likely to be something that the VM will sort out for you.

I'm in the middle of porting Juju, a pretty huge Go program, from linux to linux and windows, and almost all the changes necessary are not things that a VM can help with, like "cloud init doesn't exist on windows" and "unix pipes don't exist on windows" etc.

For everything else, the Go runtime really does a pretty good job of abstracting away the differences.


Python and Go are my languages of choice. I have found both share a the philosophy of less typing is more and more standard library is more. For web apps I have found Python has everything I can think of and more as far as third party libraries. Go package management and deployment once I got it I wondered how I could ever live without it. 1 - SQL is supported by Go specifically MySQL has a couple of drivers to choose from. After using sqlalchemy [1] everything else I have ever used just seemed like the dark ages. 2 - Go logging is standard and has been a couple third party options depending on your tastes. Tracing I think you mean stack is pretty amazing when my app crashes it is as easy to debug as any VM (JVM, Python VM or Ruby VM).

Python gives me a lot of choices based on the type of application I am building monolithic (DJango) or light (Bottle) and many package management and environment setup tasks (as with Rails, Java nightmares ect). Go on the other hand takes care of all the package management and environment setup almost non existent. YMMV good luck. [1] http://www.sqlalchemy.org/


I created a project for compression doing automatically doing compression and supporting a simple proxy system [1]. It is a pretty simple system but allow for dynamically doing proxy stuff and the compression is amazingly fast. I have found Go amazingly fast and stable. It being fun is just a bonus to code in.

[1] https://bitbucket.org/lateefj/httphacks


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

Search: