This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # bangalore-clj (27)
- # beginners (82)
- # boot (4)
- # chestnut (1)
- # cider (22)
- # cljs-dev (26)
- # cljsrn (4)
- # clojure (118)
- # clojure-dev (18)
- # clojure-italy (2)
- # clojure-losangeles (1)
- # clojure-nl (2)
- # clojure-russia (1)
- # clojure-spec (15)
- # clojure-uk (125)
- # clojurescript (61)
- # core-async (74)
- # cursive (2)
- # datomic (41)
- # duct (6)
- # editors (7)
- # emacs (3)
- # events (1)
- # figwheel-main (3)
- # fulcro (111)
- # hoplon (11)
- # jobs-discuss (97)
- # lein-figwheel (99)
- # off-topic (34)
- # onyx (4)
- # parinfer (9)
- # pedestal (4)
- # precept (2)
- # re-frame (5)
- # reagent (2)
- # reitit (4)
- # ring-swagger (11)
- # shadow-cljs (104)
- # spacemacs (4)
- # tools-deps (19)
- # vim (8)
- # yada (15)
@gklijs I am in the same spot, exactly. I did a lot of pet projects for me with no chance to introduce clojure at my job and wonder if there is a more "usefule" way to use my spare time.
i introduced clojure and go into current job by stealth — mostly various small tools and utilities, several bits of glue code
long-running Lambdas, some support tooling. Clojure should have been a good choice as we were mostly a Java shop and it using it as glue code was a nice simple way to show it in ways that would force pretty verbose Java
it didn't quite work for Clojure, unfortunately, but it did for Go, so arguably the right overall method, but couldn't get past some of the expectations
I work as part of a ~7 men team where everyone works on everything and it would be pretty unethical to introduce a new language that others will have to support sooner or later without consent of everybody, so, its not an option to sneak in stuff.
I've been in a similar situation. "Work" applications have largely been one-off projects that no-one was obliged to maintain (e.g. data migrations). I'm not sure if Java 8 makes Clojure an easier sell to management, or harder (since Java now has some of the capabilities, albeit in a vastly uglier form).
yeah, the main reason was many people found Clojure too uncomfortable, therefore weren't prepared to look past the fascia to the underlying design and the simplicity it offered, and a team of one is no team at all
where Go succeeded because it was less different syntactically, but also offered the singular benefit of compiling to a very small binary with high-speed — which was very attractive in a Docker context
Go was specifically designed to be a minimal feature set, I guess, so that makes it faster to pick up
Also, as a personal investment it means better career prospects: a lot of people want to learn Go because a lot of other people want to learn Go (indicating a lot of job openings in future), and because Go is backed by Google (so people hope it’ll have guaranteed long-term support.)
I would suggest from an industrial adoption perspective it is not the ease of writing- though it is easy to write, and the ergonomics are unbeatable for many problems- but the ease of reading that makes it low risk and quick to spread. Very constrained space of solution shapes, no "what's going on here" head scratchers. Clojure still framed as an expert's tool, in an industry of commodification.
otoh, you said @jonahbenton, Go is is very readable, way more readable than Ruby can be
My gut tells me, that a programming language wont live long if it doesn't offer (or isn't suitable) for more than specialized use cases. It's the human factor vs usefulness factor. You learn Clojure, you can use it for work and for hacking and creating art and games. Many artists use Clojure and has I think contributed a lot of coolness to many people, at least attracted attention. I think Rust will go similar path, C++ still alive and kicking. But Go, I think in 5 years it will have just as few users then as today, it will not grow substantially. It's going to be academic and/or expert sysadmin language.
yeah I’m thinking somewhat the same. My belief is that Go’s success is tied to the hype of its projects. Once the hype around Docker, Kubernetes, etc. has subsided and they become more “normal”, people will look for other sources of excitement
im very conflicted on rust.... it sounds great in theory, but using it is like pulling teeth. Swift is already painful enough, Rust just amps it up. This is me saying that as a guy who uses C++ a lot.
@jgh what do you find the most painful about Rust? Trying to keep the borrow checker happy?
That and Boxing for passing stuff to another thread I found to be more verbose than it should be.
it's been a couple of years since I tried it though so I don't exactly remember all the pain points
Yeah, with all respect I disagree about Go. As an industrial language targeted at problems that are commonly solved with c, c++, java, python, it has better ergonomics and quality and maintenance factors than any of those. It is harder to write crappy go than crappy anything else, and it is easier to refactor when you do. Personally I don't see a universe where go is not top 5, even top 3, by conventional metrics of project and use counts, etc, in 5 years.
@jonahbenton in what ways are its ergonomics and maintenance factors better than python’s?
@scriptor I don’t like Go, but I’d say “types” would improve python’s maintainability 100x
On ergonomics I agree though, python is quite nice until you try writing functional stuff with it
Yeah, the compiler is really fast and really helps. I have found refactoring large python projects (of my own creation) to be painful when I failed to create sufficient tests. With go the compiler will lead you out of the jungle
And with python imo the deployment story is at best poor compared to go, though docker helps even out the landscape
yes th deployment story is different, but I’m not sure if that falls under ergonomics/maintenance
I’ve heard good things about go making large refactors easier, although would be good to see some concrete examples
@jgh lol, agree, though I am old enough that I don't care for everyone reinventing the wheel in accordance with their own preferences. Very few programmers, again imo, have the skill to be granted the privilege of inventing their own universe
ive got nothing against go, it's ok. I like that it's relatively easy to jump in and fix bugs when they come up without requiring a ton of up-front knowledge about the language. I'd say it's better than Python in that regard.
Yes, agree. It has a whole lot of- better than X on the margins for Y- kinds comparative advantages that I see it over time continuing to become a preference
Though I agree with @jgh on the upfront knowledge required: that’s the tradeoff in this case, but it depends on how long you plan to maintain something and how many drive-by contributors you have
@nilrecurring I have not had the pleasure of working much in Haskell, though would certainly concur that to the extent languages reflect deeper patterns of creative practice, Go and Haskell are not competitors.
I'm looking at haskell now for a project, the syntax is going to take a bit of getting used to but i'm pretty excited to get more hands on with it.
(primary goals are reduce side-effects, increase productivity, decrease bugs and improve maintainability vs similar c++ projects)
Curious, though none of my business- isn't it risky to do that with a language one doesn't know inside and out? The benefits from expert use of a particular tool only come to that expertise?
I’ll chime in to say that without having Haskell experts on our team we wouldn’t have started new things with it, as the learning curve would be too steep (now we have a team of seniors and it’s really easy to manage - e.g. we just onboarded a new dev in ~1 month and he’s pretty productive already; no previous haskell experience)
Maybe, I have time for my initial development so I can overcome the learning curve comfortably. The reason I don't want to do it in C++ is because we're talking about long-running operations (on the order of hours and sometimes days) and errors can build up, so reducing side-effects is essential. C++ doesn't really encourage this behavior so it's easy to slip into bad habits. Reducing the amount of code written improves maintainability and the number of potential bugs. Undefined behavior and memory errors are problematic and sometimes manifest themselves in subtle ways in C++ -- although tooling has gotten much better in the past few years to catch things. So some of my goals here are somewhat theoretical. Going as purely functional as possible may or may not reduce the number of bugs I create, but it's hard for me to say because I haven't done such a large project in a functional way before. But I believe, given what I've experienced with smaller projects I've done in Clojure, that it will help. Ultimately I'm willing to risk the learning curve in exchange for dividends down the road. The domain itself is complicated enough, so I believe (perhaps mistakenly) that minimizing the LOC and maximizing the correctness of each line through the language's benefits will help tremendously. This isn't really something I'm taking lightly either, I've been evaluating different languages (probably 4 or 5 at this point) to see if they'll be appropriate for some of my "theoretical" goals with the project as well as concrete requirements.
@jgh that’s good reasoning 👍 Feel free to shoot any questions if in need (especially for stuff like tooling, libraries, etc), I’ll be happy to help 🙂
@jgh FYI I’ve just started playing around with Eta (http://eta-lang.org) which is a Haskell that runs on the JVM. Still has a long ways to go but it works nicely with Clojure. So you can define a module in Eta, and call that from your Clojure ns. It’s an easy way to throw some haskell code into the mix for small internal tools
@U5J5ME2NQ Yeah Eta is cool. I was looking into doing that as well (Clojure + Eta), but stopped at the “ok how do I set up the build” stage. How are you building your project? (I was leaning towards etlas + boot at the time)
ahhh… haven’t gotten that far yet. These are just for internal things so figured I can just dump all into a jar.
i like that haskell is not on jvm. GHC is quite fast and interop with C is easy as I mentioned in the main channel
In those places where Haskell's GC can get in the way, I know people who'd drop down to C (or C++) via the FFI
however, have seen a few incredible successes in using Rust instead for this in other languages
i suspect the "painful" bit might be more a construct of how much time you're prepared to invest in it
i thought about swift as well, the ABI will finally be stable in Swift 5 which will be released in a few months. But there's just so many little things that bug me. The way the optionals work. Casting is a hassle. Argument labels. I feel like it takes a lot longer to get anything done even though I'm relatively proficient at it.
@jgh There are already a lot of rust libraries making things like working with Postgres almost as easy as it's with Java/Clojure. So eventually it might be a similar effort.
YMMV, but i've tried several FP languages, and they've all had some degree of friction when you get started
the ones which have stuck with me, for sheer intuitiveness and expressiveness have been Haskell and Clojure — though I haven't been able to find time to go very deeply with Rust, mind you
F# disappoints me a bit, as I couldn't get past feeling like it was ignoring a lot of the really powerful constructs from more-modern [FP] languages in order for MS to be able to say "Look! CLR/CLI does kool FP!"
Note, I said "feeling" and I realise that it probably isn't the case — haven't been able to find any posts about why they wrote it why they did, and would be pretty keen to read those, BTW; love reading stuff about that decision-making process.
But, C# seemed a really powerful and compelling extension of C/C++ ideas, in comparison.
I think the thing is that people want that C syntax (or more accurately, they want an Algol descended language), which Clojure isn't.
Like 95% of reason why clojure hasn't had more adoption is because it doesn't do C-like syntax
the upside of this feature of lisps is that it makes an excellent filter for developers who are looking for better ways
There's also a minority of programmers, a large minority, that refuse to consider anything not statically typed.
That's true, but I have, for some time now, considered it worse than that - in addition there is a large amount of not wanting to know
for me the worrying trend of people that find Clojure and then decide it’s all there is and then they don’t want to know Like a lot of people that seem to disregard types altogether
The first sounds like a worry about a pretty low occurrence rate. After all, most come to Clojure from a variety of other things. And certainly all the ones I've interacted with are very curious about all manner of 'new' stuff. For the second, I would say Clojure people would be a very small minority of that category (think python, ruby, perl, JS, etc.)