10 ms·
What language would it be in 2016 ? Go ? Rust ?
by interrrested 10y ago
What language would it be in 2016 ? Go ? Rust ?
- MichaelBurge 10y agoHaskell's a good choice there.
- Anderkent 10y agoGo is pretty much mainstream by now, I don't think it's a stronger filter than say python. Depending on subject area, I'd look at clojure, ocaml, haskell, lua, or rust.
- claudiug 10y agohow you define mainstream? by number of jobs, scala is way ahead, also python, javascript, ruby, java. Even here, when jobs are listed, numbers of go jobs are quite low
- hughperkins 10y agoWhenever i see a bunch of code written in a language different fron whatever the rest of tge team are using, that language is often: go :)
- Anderkent 10y agoMight be bias from my anecdotal experience, but whenever I speak with people working at large corpos, go comes up more often than python or ruby.
- tonyarkles 10y agoAnother subject-area-specific option: Elixir. I do like every option you've presented as well; Elixir just fills another niche.
- Anderkent 10y agoI was considering mentioning erlang, but you probably don't want to write erlang. I've never touched elixir, but I would likely try it if I hit a problem that I would use erlang for in the olde days.
- agentgt 10y agoI would say OCaml particularly with a potential killer app of MirageOs. Stat usage wise it makes Haskell look mainstream... but serious real world code is written in OCaml (I would argue maybe even more serious than Haskell :P ). The users of OCaml almost always know how to parse really hard things to parse which is a pretty descent filter.
- JohnnyConatus 10y ago+1 I'm seeing OCaml at a number of HFT FinTech plays. MirageOS sounds cool. What are people using it for?
- vegabook 10y agoThe missing link in MirageOS is a BEAM-style distributed computing framework. If this were available, I'd be using Ocaml/Mirage almost exclusively. Imagine the beauty of supervisable, millisecond demand-scalable, ultra-lean, Ocaml-safe microkernels all messaging each other atomically and cross-node, without the dev having to build it from scratch.
- aikah 10y ago> Go It was specifically design to disallow smart-asses to write ninja-code, so no. Go is for monkey programmer factories which managers want to make sure they will only code a certain way because Go doesn't give the developer choices. It's the anti C++,scala,python,clojure... Go tells you to do this that way, and doesn't give you the constructs or features to make your own choice about coding.
- fixxer 10y agoIf you want to experience a "programmer factory", learn Java and get a job at a bank.
- booleandilemma 10y agoI've read that a good codebase is supposed to look like it was written by one person, no matter how many people have contributed. I know that doesn't sound fun but it makes maintenance so much easier.
- adrenalinelol 10y agoOf the two you listed, Rust. Go could have held this space back in ~2013?
- jsmith0295 10y agoGo would probably be the opposite of this, and I would argue that is a good thing. Hiring "smarter" people by picking a more esoteric language is likely to result in you having an esoteric or "clever" code base. That's just going to cost you in terms of maintenance in the long term, and it's not a requirement for productivity. You should be able to hire good people without this kind of filter, and use the tools that best fit your domain. That may or may not be Go, but at least it emphasizes consistency, simplicity, and readability, which is basically the opposite of what you get out of Scala.
- acjohnson55 10y agoI'd argue Scala emphasizes both simplicity and readability. Simplicity in the "simple, not easy" sense. I will grant that the language had a reputation for operator soup, due to many library authors being enamored with them. But I think this has long since fallen out of favor. In Scala, you basically have to learn the constructs and their semantics. No way around that. But once you do, almost everything is just various compositions. For the most part, it's very predictable. The execution model is ultimately pretty simple. Consistency -- I'll give you that. There are a lot of options for how to structure your code. And when you start composing libraries together, you have to be able to understand the paradigms the authors use.
- Roboprog 10y agoYeah. Seeing some Scala Build Tool stuff a while back really turned me off. Me: ooooh, look at all that overloaded operator stuff! Scala guy: those aren't overloaded operators, they are just function calls with funny names and optional parentheses. Me: it just gets better and better :-( Operator stew, whether Scala or C/++, REALLY makes me appreciate the Lisp style of function calling. "Evaluate inner parentheses first. There is no step 2." Now you're trained in "operator" precedence, which, by the way, I have seen responsible for far more costly errors than runtime types. (I'm putting C's lack of any real type checking at all in a different level of problem - sometimes useful for systems stuff, but foolish for general biz apps)
- 10y ago
- tsaprailis 10y agoProbably Elixir
- sotojuan 10y agoI second Elixir, though if trends continue you're going to get a bunch of long time Ruby/Rails people (not bad or good, but something to be aware of).
- danenania 10y agoElixir is great in the sense of attracting people who are interested in functional programming, distributed systems, and scalability, but aren't willing to give up pragmatism/productivity/readability in exchange. In my experience, these are the best kinds of people to work with. Cs theory + get shit done = good engineering.
- sotojuan 10y agoHappy to report that I'm one of those people! I like how Elixir keeps itself very practical, but at the same time lets you extend it however you want if you feel something is missing in your project. For example, you'll never find monads in the standard library but people have made their own monads through macros.
- acjohnson55 10y agoThe only problem, in my opinion, is the lack of explicit types. From what I can see, the compiler provides some safety that doesn't exist in typical scripting languages. But I think we're pretty much at a point where so many of the commonly used scripting language idioms can be effectively described in a type system. TypeScript proves this. But it also proves that's it's still pretty difficult to add types to a programming language ecosystem after the fact, so it feels like that ship has likely sailed for Elixir.
- Roboprog 10y agoI would argue that enforcing, or at least favoring, immutability and the ability to trace data flow is more helpful that static types. You could have both, but I know which one I would rather give up first. (actually, in the best of all worlds, I would want optional [compile time] types as well as type inference)
- lj3 10y agoClojure? Nim? Julia? Kotlin? Swift? There are no shortage of new, good languages these days.
- crdoconnor 10y agoI think we live in different times now. Ecosystem matters much more. There are certain languages with features that I love (haskell's state isolation looks lovely, for instance), but I'm not willing to make the jump because the Haskell ecosystem isn't there and might not ever be there. This mattered much less in the past as ecosystems were much smaller and people tended to build software much more from the ground up. That said, I think it applies within ecosystems still. Scala programmers get to choose a better language without abandoning the Java ecosystem. F# programmers get to choose a better language without abandoning the C# ecosystem. The "paradox" is evident there. Go is definitely not that language (generics? lack of package management for years? c'mon). Rust, maybe (for systems programmers).