[HN Gopher] Clojure Isn't for Me
___________________________________________________________________
Clojure Isn't for Me
Author : capableweb
Score : 62 points
Date : 2022-04-14 07:44 UTC (1 days ago)
(HTM) web link (swlkr.com)
(TXT) w3m dump (swlkr.com)
| gtoast wrote:
| Janet vs Babashka vs Fennel - anyone have thoughts?
| casion wrote:
| This submission isn't titled correctly despite it being the title
| of the article. The author has an issue with the JVM, not
| Clojure, and then chooses a dialect of Clojure (I assume because
| they like Clojure and it is for them).
|
| It would be nice though to understand what the author believes
| the issues with the JVM are since they they aren't expounded upon
| in the article.
| swlkr wrote:
| I should have gone into more detail for sure.
|
| The problems with the JVM are more cultural or political and
| not necessarily technical, although at the time clojure on the
| jvm did require quite a bit of memory and the cold startup
| times weren't great for a simple, "watch this file in
| development and restart the server" workflow.
| capableweb wrote:
| > "watch this file in development and restart the server"
| workflow
|
| Fortunately, no one in the Clojure ecosystem works like that,
| thanks to the REPL :) You fire up the server, send code
| straight from the editor to the server and evaluate
| everything on the fly, no restarts needed.
| swlkr wrote:
| Yes the repl was one of clojure's strong points,
| definitely, but I would argue that a fast restart + logging
| + irb gets you most of the way there
| casion wrote:
| Why shoot for "most of the way there" when one of the
| core features of the language is "all the way there"?
| swlkr wrote:
| The downsides of clojure on the jvm which I had kind of
| forgotten about until today like long stack traces and
| using a lot of memory kind of outweigh the upside of the
| repl
| capableweb wrote:
| Hmm, not sure about that. Consider the following (very
| simplified) example: (defonce current-
| count (atom 0)) (defn handle-request
| [req] (swap! current-count inc) (str
| "Hello " (-> req :params :name) @current-count))
| (run-server handle-request :port 8080)
|
| If you do the whole "restart server" process every time
| you change `handle-request`, you lose the state of
| `current-count`, but if you instead just change the
| function and "send" the new one to a already running
| server, the state of `current-count` is still the same,
| even when the new function definition is being used.
|
| Now imagine it with more complex state, or with things
| that require multiple states to do something. Reloading
| the server each time would mean you have to manipulate
| the state into the right "shape" each time before you can
| test your change, while if you can retain your state even
| after changing the code, you'd avoid that.
|
| This is why I'm still stuck in Clojure and unable to go
| back to writing code in other languages. The productivity
| gain is simply too high to throw away by not using
| Clojure (or other languages that are driven by the same
| ideas).
| candiodari wrote:
| Both the .Net Runtime and the JVM provide this
| functionality for all the languages they support ... I
| mean it requires a bit of work for the languages to
| acctually enable this in a proper workflow, but C#, Java,
| Kotlin, Visual Basic, ... all support this (which I must
| say makes even testing a joy. Test not succeeding? Step
| through and if something goes wrong, just change the
| code, press F8 and it restarts at the function call or
| sometimes even the basic block you changed) I believe
| Visual Studio supports this even for a C++ without a .Net
| Runtime.
|
| Microsoft calls it "edit and continue". Not sure what
| Oracle/IBM calls it but it works.
|
| It's not guaranteed to work and there's edge cases where
| it silently corrupts stuff. Function pointers of course
| don't update, for example. The Clojure way is cleaner.
|
| https://docs.microsoft.com/en-
| us/visualstudio/debugger/how-t...
|
| https://dzone.com/articles/hot-swap-java-bytecode-on-
| runtime
|
| There have been tech demos showing that LLVM can do this
| for C++ compiled to machine code. I don't know if it's
| really working anywhere, but it certainly can be made to
| work if someone puts in enough effort.
|
| I once actually established a debugging connection from
| eclipse to a telephony server running on JVM that was
| actually serving calls and live-replaced the dialplan
| handling code, stopping a ddos without making things
| worse. It even works for that case. Not something I'd
| advise doing, but I love that this can actually work ...
| Jtsummers wrote:
| If your long term state depends upon ephemeral, non-
| persisted, data then you're hosed if you ever have to
| restart anyways. If _anything_ brings that server down,
| you lose _current-count_ as well, whether it 's to change
| out the definition of _handle-request_ or a power outage.
| So _current-count_ must not be a useful (long term) value
| worth persisting or the above program is broken from the
| start.
|
| In the former case (it's useless) the stop-the-world-and-
| restart approach doesn't hurt anything, in the latter you
| would need to fix the program anyways.
| capableweb wrote:
| Yeah, I mean, obviously atoms are not used for long term
| state storage, I'm not suggesting your replace your
| database with a atom. But it's useful for a lot of things
| that are not needed for long-term storage. And even more
| importantly, it demonstrates the example of how you can
| use the stateful repl to avoid restarting the full server
| on every change and still keep state around.
| swlkr wrote:
| That is true, getting back to the same state in other
| languages is usually done with unit/integration tests,
| definitely not as nice as the repl.
|
| Although it is nice to have them written down and more
| explicit
| Tainnor wrote:
| This article is incredibly light on specific details about what
| exactly about the JVM is problematic and just vaguely hints at it
| not being open-source enough (despite OpenJDK having been a thing
| for ages), something that I consider to be more ideological in
| nature than pragmatic.
|
| As someone who has written Ruby for years and more recently
| switched over to the JVM, I don't see the big deal. Both
| ecosystems have their advantages and disadvantages. The fact that
| so much of Ruby's ecosystem is built on C has its downsides too,
| e.g. compilation errors on "bundle install" because your version
| of nokogiri doesn't work with whatever C libraries are installed
| on your system anymore, or a frequent need to install new ruby
| versions which can be rather slow when you have to compile them
| from scratch.
| oriolid wrote:
| Back in the day when I wrote Java for living, it was too common
| pattern that development is done on OpenJDK until we hit some
| mysterious problem. The problem then disappeared when we
| switched to Oracle JDK. Other problems are that Java's
| "everything is an object" and "generics parameters are lost at
| run time" ideas poison every other language too, and garbage
| collection never works as intended.
| pkulak wrote:
| One of Java's weaknesses is that they _didn't_ move to
| everything is an object. Instead we still have all the
| primitive types (except unsigned, but that's another topic!)
| and they autobox to and from their object wrappers. I'm
| assuming moving to objects was considered and discarded for
| performance reasons. Now I guess we're getting inline classes
| soon? Which will solve the performance problem, but only
| decades later.
| voidhorse wrote:
| I used to have similar complaints about Java until I sat down
| and actually read the JVM and language specs and read some
| JEPs. The truth is, the Java maintainers have made a lot of
| good design decisions over the years and they've been
| incredibly careful when it comes to trade offs. Generic
| erasure for instance, was necessary to prevent major
| backwards compatibility and break the world problems with the
| massive existing ecosystem of running java programs. Also
| it's not an idea that "poisons" other languages. It'd be
| pretty uneconomical to preserve generics in the runtime
| representations of any language--c++ doesn't do this either
| and it heterogenous approach (opposed to java's homogenous
| approach) has its own set of drawbacks (bloated code size,
| for instance)
|
| In actuality, Java is pretty great and a lot of the pain I
| experienced using it was not because there was something
| inherently worse about Java's design decisions but rather
| because I had made the (very incorrect) assumption that one
| could simply port over a lot of the unstated assumptions we
| make about the semantics of other languages when coding in
| Java, which isn't true.
| oriolid wrote:
| I'm not sure what to answer, except that we live in
| different realities and in my reality Java is pretty
| terrible even if a lot of effort has been put into it.
| Tainnor wrote:
| Java != JVM.
|
| I feel that the two are being confused here (even though
| this post is literally about another language running on
| the JVM).
| sulam wrote:
| Saying garbage collection never works as intended somehow
| elides all the very large scale systems built on garbage
| collected languages including Java. GC is like most things,
| it has trade offs and you have to understand them to get the
| best out of it. It's not impossible to achieve, though.
| oriolid wrote:
| I have to admit that I have never built a large scale
| system, but with small to medium scale systems I have
| always ended up tuning GC parameters and looking for stray
| references. And of course there is always some piece of
| code that depends on finalizers to close some resource, so
| not doing enough GC a problem just as much as doing too
| much of it. In my current project (C#) there's the
| additional problem that there are situations where GC just
| isn't allowed but there are some language features that
| just create objects behind the scenes without any warning.
| So yes, it's not impossible to achieve but it's a lot more
| difficult than dealing with reference counting or C++ smart
| pointers.
| cogman10 wrote:
| > I have always ended up tuning GC parameters and looking
| for stray references.
|
| I've been doing java for years and the key I've learned
| about the JVM is to stop tuning GC parameters.
|
| The JVM has incredibly good heuristics provided you let
| them work. The most you should generally do is pick the
| algorithm and the heap size (maybe the pause time) doing
| more should only be done if you've got a large amount of
| evidence (GClogs) to support such changes. Way too many
| people shoot themselves in the foot trying to hand craft
| GC settings.
|
| Beyond that, I've found that application changes are
| almost always more effective than GC changes. Use the
| JVMs fantastic telemetry tools (Java flight recorder) and
| find out what's really going on with your application.
| Again, grab the data first, optimize, and then remeasure
| to see what's next.
|
| I've managed plenty of apps with 30+gb heaps and 0
| tuning.
| [deleted]
| oriolid wrote:
| I wish I could say the same. Most times it ended up one
| of two ways: Either the app is stuck doing GC, or it
| crashes with OutOfMemoryError: too many this or that
| handles, open pipes or something else.
| Tainnor wrote:
| I don't know what kinds of things you're doing on the
| JVM, but the only situations where I've seen these kinds
| of errors were either a) batch jobs on massive amounts of
| data (which yeah... it figures that they could OOM, not
| sure how you'd prevent that), or b) a serious error in
| application logic.
|
| In general, I don't really encounter these problems and
| neither do most other people who write for the JVM.
| Tainnor wrote:
| > And of course there is always some piece of code that
| depends on finalizers to close some resource [...]
|
| I don't think anyone should use finalizers in Java. It's
| been deprecated since Java 9 and even before that, it was
| widely considered a bad practice.
| oriolid wrote:
| I don't think anyone should use finalizers in Java
| either, but it hasn't stopped anyone from doing that.
| Tainnor wrote:
| There are footguns in every language. There are certainly
| more footguns in C, which you're trying to advocate for,
| if I understand correctly (although I'm really not sure
| what your point is).
|
| FWIW, I haven't ever seen anyone use finalize() in Java.
| I don't doubt that it happens occasionally, but you can't
| blame a language for some of its users being incompetent.
| Tainnor wrote:
| In Ruby, everything is an object too (actually even more so
| than in Java) and in dynamically typed languages, generic
| type parameters of course don't exist, so I don't understand
| how those things matter to Clojure or (J)Ruby. Garbage
| collection pauses may be slow on the JVM, but Java is still
| miles faster than Ruby (idk about clojure).
| oriolid wrote:
| To be honest, I don't really understand Ruby either. It's
| like combination of performance of Python, compatibility of
| C, transparency of any mystery dependency + build system
| and yet another syntax on top of it.
| cyberpunk wrote:
| Ruby is awesome, but it's _insanely_ powerful.
|
| For example: I mean, you can monkeypatch anything
| (including _Object_) at runtime. You can use this to make
| 1 + 1 = 3, if you desired, or to add a method to _all_
| instances of any class currently instantiated. Want your
| database to respond to .fuckoff(), no problem..
|
| This kind of stuff is also how rspec (used to?) actually
| run tests.
|
| It's cool, but also pretty insane.
| irb(main):001:0> class Object irb(main):002:1>
| def fuckoff irb(main):003:2> "lol"
| irb(main):004:2> end irb(main):005:1> end
| => :fuckoff irb(main):006:0> 5.fuckoff =>
| "lol" irb(main):007:0> "Hello World".fuckoff
| => "lol" irb(main):008:0>
| Tainnor wrote:
| Yes, the nice thing is that you can use metaprogramming
| to create really powerful and readable DSLs.
|
| The bad thing is that this is often abused horribly, I
| blame the Rails ecosystem with its "just add this gem to
| the Gemfile and it will magically change your
| application" attitude.
| oriolid wrote:
| "I have altered the API, pray that I don't alter it any
| further"?
| Tainnor wrote:
| I'm a static typing covert, but as far as dynamically
| typed languages go, I still prefer Ruby to Python.
| swlkr wrote:
| clojure on the jvm has much better performance than ruby,
| but for my small side projects, that doesn't matter.
|
| I guess I was trying to describe the frustration of
| switching languages and ecosystems while also trying to
| ship, thought I could do it, but I couldn't.
|
| I suppose I would have had a much better time and stayed in
| C-land (and gotten much better performance) if I had tried
| golang instead of clojure.
| Tainnor wrote:
| If you have deadlines and can't afford being "bad" at
| something for a while then, yes, learning new
| technologies or ecosystems might not be a wise choice. I
| think that's independent of what those technologies are.
|
| I switched to the JVM because I was annoyed enough at the
| things I had to deal with in Ruby that learning how to do
| things in a new way was worth it for me in the long run.
|
| > I suppose I would have had a much better time and
| stayed in C-land (and gotten much better performance) if
| I had tried golang instead of clojure.
|
| But Go is a completely different language than Clojure?
| By what criterion are you deciding which language to
| focus on? Mostly I'd think that people who choose Clojure
| do so because they want to use a homoiconic, dynamically
| typed, functional programming language and not something
| that looks a lot like a cleaned-up C.
| swlkr wrote:
| These days I care less about how the language looks and
| more about the development/deployment experience, and how
| much memory it's going to take on a VPS, since that's the
| primary thing driving VPS costs.
|
| Ruby (and rails) for web applications is very hard to
| beat ergonomically.
|
| Go also feels this way to me, the development experience
| is very simple, deployment is even easier than ruby/rack
| (assuming no docker), and you get the added bonus of
| using a lot less memory on the server.
| spacemanmatt wrote:
| If you want concurrency without trouble, it's hard to beat
| Clojure.
| swlkr wrote:
| I'm not quite sure why my stuff keeps hitting the front page, but
| I'm here for it.
|
| I've since abandoned janet for web app side projects and gone
| back to ruby entirely but yeah, I still love lisp but it makes
| more sense to align my work programming language with my side
| projects that way I can ship my side projects faster, at least
| that's the thought now.
| capableweb wrote:
| As the submitter of this story, I can tell you about why this
| one landed there. I found the link via the discussion on the
| previous one (https://news.ycombinator.com/item?id=30917772)
| and submitted it shortly afterwards
| (https://news.ycombinator.com/item?id=30929823). It didn't end
| up on the frontpage though, but I got invited to submit it to
| the "second chance pool" (https://news.ycombinator.com/invited)
| where submissions get exposed to the frontpage for X hours and
| if they manage to stay up, they stay there naturally. Seems
| like people enjoy your writing enough to make it stay for at
| least some moments :)
|
| As a Clojure fanatic, I too enjoy your writing and hoped to
| stir up some interesting discussions around Clojures weak-
| points by submitting this story.
| swlkr wrote:
| I'm not sure if it's about clojure's weak points or my own
| weak points haha
| delegate wrote:
| I think the article should be titled 'JVM isn't for me'.
|
| According to the article, the author moved to Janet, because it
| is Clojure-like without the JVM overhead.
| jmchuster wrote:
| How about Clojure on node? Starts and runs instantly
| https://planck-repl.org/
| crispyalmond wrote:
| I prefer to use nbb[0] for this, or babashka[1] when I need
| to use stuff specific to JVM.
|
| [0]: https://github.com/babashka/nbb [1]:
| https://babashka.org/
| swlkr wrote:
| Yes, the newer clojure runtimes like planck or native-image,
| or babashka definitely take away some of the jvm pain
| nesarkvechnep wrote:
| Why not Lisp on the BEAM - https://lfe.io/.
| swlkr wrote:
| Fair enough, I usually start with the title and try to let the
| rest flow from there, but it's definitely the JVM that was
| getting me down, not clojure specifically.
| jcadam wrote:
| I think the JVM route is smart for bootstrapping a new language
| since it gives you an existing ecosystem to leverage. However,
| at this point, I'd love to see a native Clojure.
| pjmlp wrote:
| There is already Common Lisp and Scheme for that.
| aidenn0 wrote:
| Rich Hickey was already using a native lisp; then he wrote a
| couple of bridges between it and JVM/CLR before deciding
| running a lisp directly on the runtime VM was the way to go.
| Gollapalli wrote:
| Increasingly, I don't see clojure as primarily a matter of the
| clojure-on-jvm implementation, but as a distinct and (generally)
| hosted dialect of lisp. Clojurescript is a clojure. Janet is a
| clojure. ClojureCLR is a clojure. Fennel is a clojure. Babashka
| is a clojure. Ferret is (kind of) a clojure. Maybe someday we'll
| have a bare-metal clojure. So far as I can tell, the lisp
| landscape (land of lisp?) has changed from common-lisps and
| schemes, to common-lisps, schemes, and clojures.
|
| IMHO. Maybe I overexaggerate. Anyway, the author, from my
| perspective has decided that clojure IS in fact for him, but
| clojure on the JVM is not, so he chooses to use a different one.
| fnordsensei wrote:
| No, I think you're right. Clojure is first and foremost a
| symbiote.
| valbaca wrote:
| OP doesn't need or want the JVM or Java libraries, and he wants
| to stay in the world of Free software that C and Ruby provide.
|
| He analyzed his needs and wants.
|
| This is a good example of what "right tool for the job" analysis
| looks like.
|
| Though honestly, if OP wasn't in "java land" (his phrase), I'm
| not sure why Clojure was even on his radar.
|
| I greatly respect people who reject the hype and just go with the
| language that fits their needs, even if it isn't hyped like C,
| Ruby or Python but provide plenty of what you'll need.
|
| https://boringtechnology.club/
| maydup-nem wrote:
| > https://boringtechnology.club/
|
| the pitfalls of old boring tech have known solutions, while the
| new tech may run you into trouble you don't know you can run
| into?
|
| well, gee, that was totally worth the 50 slides that i had to
| scroll through (and i don't know why the website was so slow)
|
| looks like a web-dev is coping with the realities of web-dev,
| nothing more
| pixelrevision wrote:
| > Though honestly, if OP wasn't in "java land" (his phrase),
| I'm not sure why Clojure was even on his radar
|
| Clojure is really appealing as a language and has enough of a
| following that it doesn't seem like a risky bet. It also looks
| pretty self contained. It's only when you need to push it that
| you find yourself with confusing JVM stack traces and all the
| nuances of that ecosystem. When you do you start to figure out
| the whole thing is not quite as elegant and simple as it first
| appeared.
| joshlemer wrote:
| I dunno, in my experience even something as simple as a tiny
| syntax error can already get you into pretty deep and
| inscrutable stack traces.
| capableweb wrote:
| Syntax errors like unbalanced brackets/parenthesis/curly
| braces? Those should definitely give you "pure-clojure"
| errors as the parsers can't even read the source at that
| point. Only time you should be getting JVM stack traces is
| runtime errors.
| swlkr wrote:
| This is exactly what I experienced too, the tidy clojure
| ecosystem can come undone pretty quickly
| swlkr wrote:
| Yes, this is pretty much it. It's funny the presentation
| specifically mentions clojure for the "new and shiny."
|
| Today it would be something else, like rust or zig or
| something.
|
| But yeah it's difficult for me to build my tools and ship
| finished web applications at the same time, it's compounded by
| learning a new language.
|
| This is something I've struggled with for a long time. I still
| struggle with this, the urge to create a new web framework when
| I would have shipped much faster if I had just used some boring
| old one for example.
| zem wrote:
| clojure in and of itself is a very pleasant language, and was
| an exciting new lisp when it came out. i remember going through
| the same journey as the author, venturing into jvm land just
| because i wanted to use clojure, and eventually deciding i
| preferred the unix/c ecosystem.
| mproud wrote:
| 2020?
| swlkr wrote:
| Oh yeah that's interesting, I wonder what the threshold for
| year timestamps is, I thought it was > 6 months after a new
| year
| flakiness wrote:
| The author's next choice is "Janet", which I haven't heard of:
| https://janet-lang.org/
|
| Not sure how it is better than Ruby. But maybe the author wants
| something fresh to play with - that I can totally relate to. Good
| luck with the new journey anyway!
| mjburgess wrote:
| I think the "C-derived open-source world" is a good way of
| putting it.
|
| The java-world is an inscrutable place of gigantic IDEs,
| maddening dependency graphs, perverse build systems. Everything
| is just-so-poorly-compiled _enough_ that it 's a nightmare to
| work with. It sucks all the joy out of programming in my
| experience.
| seertaak wrote:
| I mean, it's kind of farcical to complain about Java build
| systems _and compare that to C_ , which has literally the worst
| build system/dependency management tooling. Even with vcpkg and
| conan (which are infinitely better than what existed before),
| building projects with 4-5 dependencies (abseil, boost, folly,
| and range-v3, say) requires understanding why builds break
| complaining about iterator traits under C++20 on Clang 13. It's
| insane. How can Java possibly be worse than that? It may not be
| as nice as rust or python (even python can be pretty insane for
| dependency management, actually), but with Maven I could add
| 3/4 lines to my project, and in my IDE the dependency would
| "just work" and I could even navigate to the source code of the
| dependency.
|
| And it's not like this is a slow language, Java is like 80-90%
| as fast as C if you know what you're doing, and for most use-
| cases, and isn't brain-dead in its handling of threads.
|
| I'm a C++/Python developer, by the way, although I've had day
| jobs writing Java too. I honestly think this is way off base;
| it's a great language which has constantly evolved, and the JVM
| is a fantastic piece of technology. Rich Hickey was super smart
| in targeting the JVM, it was a great decision, and to my mind
| OP hasn't a clue of what he's talking about.
| swlkr wrote:
| I will say as far my limited understanding of the JVM goes,
| it seems like container tech can take care of any system
| dependencies that you might need for a complex c++ build.
|
| It also seems that the JVMs original purpose of running the
| same code across operating systems/architectures has also
| been superseded by containers, better cross compilation
| (llvm) and possibly wasm as well.
|
| Maybe at some point in the future, the JVM will mostly be
| relegated to legacy systems and most new software (assuming
| AI isn't writing all future software) will target wasm or
| require some container runtime.
| Tainnor wrote:
| You can't complain about the complexities of the JVM and
| then propose containers, which are incredibly complex
| themselves, as a solution.
|
| I mean sure, most modern JVM apps _deploy_ to containers,
| but developing in container images is quite another thing
| and requires you to understand and debug a lot of issues
| (e.g. mounting, caching, networking) that you 'd like not
| to care about (especially if you're not particularly an
| infrastructure/ops person).
| swlkr wrote:
| Fair enough.
|
| This might also come down to editors and things that I
| didn't cover in the post too.
|
| There's probably a happy path for clojure/jvm via an IDE
| that I didn't try (I use neovim) or something else I
| might have missed in my clojure years.
| mjburgess wrote:
| No one's comparing java and C. The phrase "C-derived" here
| includes, eg., python/php/ruby/javascript/etc. ie., all those
| languages whose targeted VM is extensible with C.
|
| The idea is that there's a "cluster of C-based ecosystems" of
| languages whose open-source philosophy, programming culture,
| etc. "is just fun". In contrast with the JVM ecosystem which,
| I think, just isnt.
| oriolid wrote:
| For C and C++ Meson is quite nice.
| burntoutfire wrote:
| Hah, I feel pretty much the opposite. For me, Java is simple
| and logical, and its IDEs help tremendously.
|
| C (and C++), on the other hand, is a trash fire of macros
| obfuscating code, header files (WTF they're still here in
| 2022?), libraries which are hard to import, barely working IDEs
| (IntelliSense in latest Visual Studio takes 30+ seconds to
| update itself after every change in my small C++20 pet
| project), people redefining primitive data types in a hundred
| different ways, unusable compiler error messages etc. Every
| time I have to work with C++, I'm getting angrier by the hour -
| and my codebase is only a simple personal project!
| agumonkey wrote:
| Java makes few sense to me, it never did, and I tried to read
| the JVM spec a few times to avoid poking at random, which
| seems to be the difference here, the whole platform is
| spec'd. Not the javascript/c+make+libtool kind of blur or
| chaos.
| adenozine wrote:
| Where could someone read about implementing immutability checks
| in a compiler?
|
| I've always wondered if there's a way to know at compile time
| whether a value is being mutated, rather than throwing a runtime
| exception.
| pjmlp wrote:
| Some proprietary UNIX in the 70's?!?
|
| I guess he also never saw the price of ISO C document that
| someone has to pay so that GCC actually supports C the proper
| way.
|
| Talk about being precise on the details.
| swlkr wrote:
| I did gloss over a few things there, the goal was to say, yes I
| understand that C-land hasn't always been as free and open
| source as it is now
| brundolf wrote:
| I think the takeaway here is that any language or ecosystem has
| an unspoken culture, set of habits and norms, set of assumed
| background knowledge, and general "look and feel" to it that
| matter to the productivity and overall satisfaction that any
| given developer will get, based on their personality and past
| experience. We often ignore these aspects when doing something
| like picking a language, but they really do make a difference.
| tomatowurst wrote:
| i think the biggest point is that it's hard to find developers
| in a special niche even if it allegedly offers productivity
| gains, this is negated by increased costs.
|
| clojure was cool, I used it mainly for datomic, but the gains
| really dont justify relying on public slack channels and
| mailing lists to hire and find devs.
|
| I really see this from an economic point of view. I could be
| mistaken based on my own experience dealing with clojure and
| datomic in particular. I'm just not sure the gain is there
| anymore as other databases built on conventional tech stacks
| increasingly more or less take away the gains.
| warcher wrote:
| Not gonna lie, I think the jvm integration is a big win for
| clojure as a language. The fact that you can pull in and interop
| with established jvm tools and libraries makes using a niche
| language like clojure a possibility for professional development.
|
| C libraries are wonderful tools when you need a low-level library
| to run hot, but if you need, I don't know, a database adapter or
| a queueing library and you don't want to write one, I'd much
| prefer pulling something out of maven than trying to integrate a
| C library. There's just a lot of infrastructure the jvm gives you
| pretty easily.
|
| If you're just messing around with fun side projects, there's
| nothing wrong with using something you _enjoy_ for no other
| reason than your own personal enjoyment.
| pkulak wrote:
| > If you're just messing around with fun side projects, there's
| nothing wrong with using something you enjoy for no other
| reason than your own personal enjoyment.
|
| That was my thought too. If it's a side project, I guess you
| should just always use Python because you will never need
| anything else. But I already kinda know Python and it doesn't
| interest me much, so I write my side projects in the flavor of
| the day that has my fancy at the moment.
| chefandy wrote:
| Minor point: Proprietary UNIX OSs aren't artifacts of the
| seventies. OSs like AIX and Solaris live on. A former employer
| sells enterprise software for both of those environments to this
| day. Banks, especially, seem to love AIX in my experience.
| swlkr wrote:
| Wow that's crazy, I love learning new tidbits about how older
| tech like cobol or mainframes or something are still around and
| plugging along
| chefandy wrote:
| Kind of mind boggling. You figure _" surely there must have
| been a point at which being that change-averse bit them in
| the ass hard enough to modernize their approach"_ but...
| guess not.
|
| In fact, one large banking system I worked on in the late
| aughts completely revamped their megalith of a back-end for a
| major component of their system and the only two things they
| _didn 't_ change were using AIX and Oracle.
| chipotle_coyote wrote:
| Huh. I genuinely didn't know Solaris -- the closed-source
| commercial version, rather than offshoots like Illumos and
| OpenIndiana -- was still kicking around, but sure enough
| there's an "Oracle Solaris 11" page.
| chefandy wrote:
| Turned 30 last year (basically). Well-funded inertia might
| float it for another 30. I'll bet even joking about EOLing it
| could trigger flop sweats in some enterprise technical
| executives.
___________________________________________________________________
(page generated 2022-04-15 23:00 UTC)