8 ms·

Recently I have had the opportunity to write a microservice in Go. It was a very refreshing experience switching from Scala. Go is a lot faster to compile and r

Recently I have had the opportunity to write a microservice in Go. It was a very refreshing experience switching from Scala. Go is a lot faster to compile and runs with a far smaller footprint. The channels are nice. On the other hand the testing feels wrong because its so annoying to do mocks. And don't even get me started on the dependency management. Overall Go feels to me like some version compiled PHP with better concurrency support.

egeozcan 9y ago
> compiled PHP with better concurrency support ...and simpler syntax and without the quirks. But that's one of the best descriptions of Go I've seen so far.
- cies 9y ago
  Indeed. Go and PHP are at the complete opposites when it comes to quirkiness. And syntactically PHP is at a very noticeable disadvantage.
oblio 9y ago
I really wish that there was a language which had these features: - simple (so not Scala, Haskell, Perl 6, etc.; no Rust either, unfortunately) - clean (nice syntax, preferably Python inspired, but consistent) - modern (generics, some functional features, string interpolation, etc.) - decent concurrency/parallelism story - good IDE, preferably supported by the core dev team - compilation to a (possibly static) native binary - decently big ecosystem - and a big enough community of contributors or commercial backing from at least 1 stable entity - also preferably didn't have a lot of historical baggage From what I gather C# might actually be close to this, 2-3 years from now, if the .Net Core transition happens smoothly and the OSS community adopts it... Who knows, maybe even Kotlin 2019 or so?
- jhh 9y ago
  Kotlin comes to mind.
- cjsuk 9y ago
  A lot of people I know are bailing on .net because it doesn’t live up to the promises. Everyone else gets the cool stuff first, the vendor that owns it is a dick and there has been so much schizophrenia over the last few years that it’s a business risk adopting it in case you have to throw your product under a bus again. Go is showing itself to be a good compromise especially with the simplified nature of deployment and runtime stuff. It’s like a safer, higher level C, with a decent runtime library. That has so much mileage. I’ve learned one thing as well over the last 15 years of using .net as well. An IDE is a monolithic brain damager. If you have to do something outside the scope of it, you’re shot. Give me an extensible text editor and shell.
  - pjmlp 9y ago
    I wonder where, in this little corner of the Earth, it keeps being Java and .NET as it has always been the last 20 years.
    - cjsuk 9y ago
      Java is fine to be honest. It’s a good solution. Now I’m going to duck for cover!
  - pwdisswordfish 9y ago
    > A lot of people I know are bailing on .net Crazy attracts crazy, now you know.
  - maxxxxx 9y ago
    You are pretty much describing my thought process. .NET is comfortable but the cool stuff is happening on other platforms.
- pjc50 9y ago
  C# actually already has most of that except for "compilation to a (possibly static) native binary", which is really just a convenience for shipping. It's also not really very cross-platform, it's definitely a "Windows First" language.
  - pjmlp 9y ago
    C# has always had "compilation to a dynamic native binary" since version 1.0 via NGEN. Mono has always supported "compilation to a (possibly static) native binary". Windows 8 introduced "compilation to a dynamic native binary" on the Windows Store via the Bartok compiler used in Singularity. Windows 10 adopted "compilation to a static native binary" with .NET Native, based on Midori compiler toolchain. The .NET Core team has CoreRT for the same purpose.
  - egeozcan 9y ago
    > it's definitely a "Windows First" language C# used to be that but I don't think that's the direction anymore.
    - mkesper 9y ago
      Which platform-agnostic GUI toolkit do you use?
      - egeozcan 9y ago
        HTML but there's always GTKSharp: http://www.mono-project.com/docs/gui/gtksharp/ http://www.mono-project.com/docs/gui/gtksharp/
      - symlinkk 9y ago
        Which platform-agnostic GUI toolkit do you use for Go? What about Python? No language ships a cross-platform GUI toolkit in its standard library.
        lmm 9y ago
        TCL comes with TK, Python comes with PyTk, Java comes with JavaFX...
- mfontani 9y ago
  Other than the compilation to binary, Elixir seems a good fit for what you're looking for
  - dnautics 9y ago
    Elixir compiles to bytecode which is not half bad
    - masklinn 9y ago
      Pretty much everything compiles to bytecode (e.g. Java does, Python does, C# does, …) I expect they want a native binary (possibly even statically linked) so they can trivially distribute the artefact without requiring that the VM be installed or bundled which is a PITA, in which case "compiles to bytecode" is useless.
      - deleted 9y ago
        [deleted]
      - dnautics 9y ago
        sorry, i should have said compiles to a bytecode that's not half bad
- masklinn 9y ago
  OCaml seems to match a majority of the criteria, though AFAIK no "good IDE" (tooling like merlin is available, but if you're looking for e.g. a refactoring IDE you're probably SOL), the ecosystem is small, and it does have some historical baggage.
  - cies 9y ago
    And with the ReasonML frontend there is a much more approachable-for-other-language-refugees syntax to it.
  - Double_a_92 9y ago
    > - clean (nice syntax ...) Just looked at wikipedia examples and the code is full of special chars and shortened keywords. Doesn't look nice or simple to me, tbh.
    - masklinn 9y ago
      I guess beauty is in the eye of the beholder, though your eye seems questionable, the only "shortened keywords" I can find in the wikipedia page are "rec" (which is a long-standing shortening of "recursive" in recursive lets) and "fun" (for functions).
    - hajile 9y ago
      SML is what Ocaml should have been. With a few small syntactic changes (mostly to add some nice-to-have features), SML syntax would be better in every way instead of almost every way.
    - TheAceOfHearts 9y ago
      As another commenter mentioned, you might want to try out Reason [0]. It's a new-ish programming language from Facebook that uses OCaml as its backend. [0] https://reasonml.github.io https://reasonml.github.io
  - mbenoni7 9y ago
    OCaml is great, but F# is better for almost every one of his bullet points.
- lenkite 9y ago
  Believe kotlin (especially kotlin-native) should soon relieve all those itches.
  - oblio 9y ago
    Yeah, but Kotlin Native loses all the Java libraries. The more interesting thing would be Java native compilation coupled with Kotlin. So you'd write a Kotlin Java app and pass that through the Java native compiler introduced in Java 9. Unfortunately that's a beta feature right now, I think it only supports Linux x64, that's why I said Kotlin 2019, I assume that by then the Java native compiler will support all Java platforms.
    - pjmlp 9y ago
      Java compiles to native code since version 1.0, only not for free. All commercial JDKs had this option in one form or the other, and many of them are still around. If you want to try this for free on open source projects, Excelsior JET is one option.
      - oblio 9y ago
        I'm probably too conservative, but I'd rather use these kinds of things from the actual platform developers. I'm a bit more liberal with libraries, but in general I want the compilers/interpreters from the upstream source. Software has enough bugs as is :)
        pjmlp 9y ago
        Commercial JDKs, like from IBM or OEMs for embedded platforms, are the actual platform developers.
      - mhd 9y ago
        > Java compiles to native code since version 1.0, only not for free. Well, there was GCJ, but I think that hurt more than it helped.
- oweiler 9y ago
  Kotlin covers all those features - much simpler than Scala while still being much more expressive than Java - clean syntax, with a higher consistency than e.g. Java - Generics, Higher Order Functions, Multiline-Strings, Destructuring, ADTs, Pattern Matching - Coroutines (experimental but production-ready) - IntelliJ Community Edition (or Ultimate) - not yet but will be possible with Kotlin Native - has its own ecosystem but also has great interoperability with Java - stable for quite some time, big community - well, a little bit for reasons of Java-interoperability; on the other hand
  - _Codemonkeyism 9y ago
    I like Kotlin too, but in which way is it "much more expressive" in your opinion? What can you express in Kotlin that you can't express in Java? Scalas type system is much more expressive than the one in Java as an example. Only thing that comes to mind in Kotlin is non-nullable references. Most of the stuff in Kotlin looks more like less boiler plate (data classes) than "more expressive".
    - pabl0rg 9y ago
      It's not immediately obvious, but when you write some Kotlin you'll see. Little things that are a apin in Java and elsewhere are quick and natural in Kotlin: - nullable types are smoother than Options - null checks are relatively painless - the stdlib works with you, not against - named parameters and optional parameters means no need for builders - etc. Etc.
      - _Codemonkeyism 9y ago
        I have written some Kotlin, and perhaps it's me, but I don't see. "nullable types are smoother than Options - null checks are relatively painless" Might be the case, but Options are more expressive in that I can combine them and restrict them with other type classes to express larger constraints. Reusabilty is higher e.g. with Monad transformers like OptionT. So nullable types are less code, but also less expressive as building blocks of larger constructs. They might be also less expressive because they conflate two concepts: Not initialized and not-there, whereas Option expresses not-there and _ (in Scala) expresses not-initialized. "named parameters and optional parameters" Not sure how this more expressive?
- beagle3 9y ago
  Nim has everything nailed down except the ecosystem/commercial backing; It does have some of those, but not to the extent that I would blindly tell you they are there. It's as fun as writing Python (with a similar syntax), but it has essentially all the goodies you want from Lisp when you need them, runs as fast as equally optimized C, produces standalone native binaries, _or_ standalone JavaScript if that's your thing.
  - egeozcan 9y ago
    I wish there was a Go->Nim compiler or a way to simply import stuff from Go :) I'm just half-joking to be honest.
    - beagle3 9y ago
      Go can generate .so/.dll usable from C; Nim can use them.
  - reacharavindh 9y ago
    Cheers to Nim. I'm learning it in my spare time for fun. However, I will not consider using it for anything more than toy projects until it hits 1.0. Hopefully soon.
    - narimiran 9y ago
      > I will not consider using it for anything more than toy projects until it hits 1.0. Hopefully soon. It should happen soon (TM), but from what I understand it will be just another version, just this time renamed to 1.0 - this basically means you could start using it more seriously even now.
      - reacharavindh 9y ago
        Yeah. I understand that it will be just another version with not that many changes. Nim as it currently already feels stable and solid. But, I believe v1.0 release will carry a commitment to not introduce breaking changes at least for reasonable period of time after.
- nicoburns 9y ago
  Swift is a potential competitor in this space too.
- s_kilk 9y ago
  Take a look at Elixir, it covers most of what you want.
- squeaky-clean 9y ago
  I think my dream language would be C# but with a slightly more Pythonesque syntax (significant indentation, no semicolons or braces...). I wonder if a transpiler like that exists.
  - mbenoni7 9y ago
    You can write "Pythonesque C#" today using F#. Once you get used to it, though, you'll probably want to write idiomatic F#.
- hawski 9y ago
  C38 (so when the world ends): - arrays with slices (that could also be used for strings) and Cilk Plus array notation [1] - maybe actual string type with separate concatenation operator (possibly space as awk uses and C for literal strings) it could probably be folded to improved arrays - standard SIMD vector types so that most use for operator overload disappears - cleaned up standard library - actual macros so the remaining use for operator overload disappears - module system (so you would generally not need make and could easily compile to static binary) - already you can build with static musl libc [2] - something like libdill [3] or libmill [4] in stdlib - there are multiple good IDEs, debuggers, analyzers - one of biggest ecosystems and communities - historical baggage mostly cleaned up [1] https://en.wikipedia.org/wiki/Cilk#Array_notation https://en.wikipedia.org/wiki/Cilk#Array_notation [2] https://www.musl-libc.org https://www.musl-libc.org [3] http://libdill.org/ http://libdill.org/ [4] http://libmill.org/ http://libmill.org/
- dilap 9y ago
  seems like Go 2 has a good chance of being this (at least if you consider its syntax clean, which I do). basically go is missing from your list is generics and string interpolation.
- hajile 9y ago
  I think F# has the things you're looking for.
- didibus 9y ago
  By simple, you mean easy? What about Java? Its easy, modern in the way you describe, has a good concurrency story, multiple great IDEs, can compile to a static binary with commercial JVMs, or experimentally in OpenJDK9. Really big ecosystem. Huge commercial backing. It just maybe fails at historical baggage and syntax. Kotlin fixes those last two. And Java 10 will also fix a good chunk of the syntax complaints. In all fairness though, I think you're focused on nitpicks that have no practical benefits. You're asking for a language with a better user experience. Which is great, as it can make programming more pleasant, and I'm all for it. That said, I'd focus on language changes that provide functional value. Haskell adds a powerful correctness layer at a low expressiveness cost. Go adds a useful CSP concurrency mechanism with green threads, as well as being friendly to containerisation. Erlang and co add a great deal of reliability features and massive parallelism with first class actors. Clojure gives you powerful metaprogramming, state of the art immutability and a similar CSP layer as Go, while maintaining the access to Java's large ecosystem. Kotlin adds null type checking, and better functional primitives. Rust gives you safe memory access without the performance overhead of a GC. Chapel allows for super parallel computing. Scala gives you OOP with the safety layer of Haskell on it. Nim gives you faster python, with type safety. Crystal gives you faster Ruby with type safety. Etc. Those are the languages that challenge the status quo, and have a chance at bringing real value in terms of the average output they result in when used to program with. A slightly better UX for Java or Python is a hard sell. Its like the famous Unix quote: "the most dangerous enemy of a better solution is an existing codebase that is just good enough." - Eric S. Raymond Java, C#, Python, Ruby, C++ are all good enough, even UX wise, to be displaced by something that doesn't offer compeling functional value. At least, in my opinion.
lbruder 9y ago
YMMV, but my experiences with SBCL were way better than with Go. Using Hunchentoot and the other Quicklisp libraries made developing fun again. With Go I had to constantly worry about errors, repeat the same code snippets over and over again, had to comment out "unused" variables just to try something... not fun. That said, let's see how Lisp works out once I cross the 10'000 LOC barrier. But by then it won't be a microservice anymore, anyway...
- TurboHaskal 9y ago
  The problem is getting people to actually code in CL or any Lisp. I haven't had that problem with Go so far.
weberc2 9y ago
I haven't had a problem with testing in Go, but I also don't mock many things. Most things that should be mocked are already interfaces in my code. My biggest grievances with Go are its limited type system and dependency management. Unlike most[^1], I don't need semantic versions--I just need deterministic, reproducible builds, and for that, vendoring is fine in theory, but Go's tooling around it needs work. I love that Go is a language that can be mastered in a matter of months; that it has such a simple "get up and running" story; that its tools mostly do the right thing by default; and that almost everything is straightforward. In most other languages, I have to figure out what build system to use, how to script it, how to specify and download dependencies, what testing library to use, how to actually run the tests, how (if it's possible at all) to get a static binary, etc--and then I usually have to learn a complex language on top of all of that. For the most part, Go just works out of the box. I think folks also underappreciate Go's runtime--it has a fast garbage collector and an awesome goroutine scheduler that all get statically compiled into your application binary. Mostly, I want a functional language that compiles to Go so I can still leverage Go's awesome tooling, runtime, and deployment model, but with things like generics and algebraic data types. I've started prototyping it too, and so far it's coming along smoothly (modulo all the things I'm learning about building a programming language). On that note, there is some effort going on in the Go community to build a VM for Go, which would probably make an even more attractive compilation target, at least from a toolchain perspective. Even if my project doesn't take off (and it likely won't), I think this is a low-effort way to address Go's most significant complaints. [^1]: Well, "most" judging by the significance many of Go's critics place on semantically versioned dependencies
- mrhwick 9y ago
  Have you used dep? https://github.com/golang/dep https://github.com/golang/dep
  - weberc2 9y ago
    I have, but early on and not much since. I forget my particular issues; I just remember at the time there didn't seem to be a way to do what I wanted (I think it was adding docker as a dependency).
sethammons 9y ago
Chances are, if you are using mocks in Go, you are doing it wrong. Functions should take interfaces (not interface{}, but interfaces that list methods) and return structs. In your tests, you create a fake that meets the interface and pass that to your function under test. If you have to test file io or DB interaction, you can either do the adapter pattern or, as I prefer, just actually use the filesystem and DB but with some test infrastructure around it.
- deleted 9y ago
  [deleted]
- AnimalMuppet 9y ago
  What's the difference here between a "fake" and a "mock"?
  - sethammons 9y ago
    Might be splitting hairs. There are fakes, mocks, and stubs. Generally, mocks assert, stubs do not. Some folks define both stubs and mocks as fakes. This does not fit perfectly for Go. The "fake" in Go is just a struct that matches an interface but is purely for testing. It allows for dependency injection where you pass a fake designed for your test. It can have its own properties and helper methods, but the key thing is that it matches your interface. You don't make assertions against the fake like you would a mock. You assert against responses from your functions under test. Example: > type Bar interface{ > Walk() (int, error) > } > > func Visit(b Bar) (string, error) { ... some code ...} In the production code, you call Visit with some struct that matches the interface (has a Walk method). In tests, you create a new struct like fakeBar that also matches the interface. You can have your fakeBar return any string or error you like and you can verify that Walk behaves the way you need it to. Hope that helps.

egeozcan 9y ago

> compiled PHP with better concurrency support ...and simpler syntax and without the quirks. But that's one of the best descriptions of Go I've seen so far.

cies 9y ago
Indeed. Go and PHP are at the complete opposites when it comes to quirkiness. And syntactically PHP is at a very noticeable disadvantage.

oblio 9y ago

I really wish that there was a language which had these features: - simple (so not Scala, Haskell, Perl 6, etc.; no Rust either, unfortunately) - clean (nice syntax, preferably Python inspired, but consistent) - modern (generics, some functional features, string interpolation, etc.) - decent concurrency/parallelism story - good IDE, preferably supported by the core dev team - compilation to a (possibly static) native binary - decently big ecosystem - and a big enough community of contributors or commercial backing from at least 1 stable entity - also preferably didn't have a lot of historical baggage From what I gather C# might actually be close to this, 2-3 years from now, if the .Net Core transition happens smoothly and the OSS community adopts it... Who knows, maybe even Kotlin 2019 or so?

jhh 9y ago
Kotlin comes to mind.
cjsuk 9y ago
A lot of people I know are bailing on .net because it doesn’t live up to the promises. Everyone else gets the cool stuff first, the vendor that owns it is a dick and there has been so much schizophrenia over the last few years that it’s a business risk adopting it in case you have to throw your product under a bus again. Go is showing itself to be a good compromise especially with the simplified nature of deployment and runtime stuff. It’s like a safer, higher level C, with a decent runtime library. That has so much mileage. I’ve learned one thing as well over the last 15 years of using .net as well. An IDE is a monolithic brain damager. If you have to do something outside the scope of it, you’re shot. Give me an extensible text editor and shell.
- pjmlp 9y ago
  I wonder where, in this little corner of the Earth, it keeps being Java and .NET as it has always been the last 20 years.
  - cjsuk 9y ago
    Java is fine to be honest. It’s a good solution. Now I’m going to duck for cover!
- pwdisswordfish 9y ago
  > A lot of people I know are bailing on .net Crazy attracts crazy, now you know.
- maxxxxx 9y ago
  You are pretty much describing my thought process. .NET is comfortable but the cool stuff is happening on other platforms.
pjc50 9y ago
C# actually already has most of that except for "compilation to a (possibly static) native binary", which is really just a convenience for shipping. It's also not really very cross-platform, it's definitely a "Windows First" language.
- pjmlp 9y ago
  C# has always had "compilation to a dynamic native binary" since version 1.0 via NGEN. Mono has always supported "compilation to a (possibly static) native binary". Windows 8 introduced "compilation to a dynamic native binary" on the Windows Store via the Bartok compiler used in Singularity. Windows 10 adopted "compilation to a static native binary" with .NET Native, based on Midori compiler toolchain. The .NET Core team has CoreRT for the same purpose.
- egeozcan 9y ago
  > it's definitely a "Windows First" language C# used to be that but I don't think that's the direction anymore.
  - mkesper 9y ago
    Which platform-agnostic GUI toolkit do you use?
    - egeozcan 9y ago
      HTML but there's always GTKSharp: http://www.mono-project.com/docs/gui/gtksharp/ http://www.mono-project.com/docs/gui/gtksharp/
    - symlinkk 9y ago
      Which platform-agnostic GUI toolkit do you use for Go? What about Python? No language ships a cross-platform GUI toolkit in its standard library.
      - lmm 9y ago
        TCL comes with TK, Python comes with PyTk, Java comes with JavaFX...
mfontani 9y ago
Other than the compilation to binary, Elixir seems a good fit for what you're looking for
- dnautics 9y ago
  Elixir compiles to bytecode which is not half bad
  - masklinn 9y ago
    Pretty much everything compiles to bytecode (e.g. Java does, Python does, C# does, …) I expect they want a native binary (possibly even statically linked) so they can trivially distribute the artefact without requiring that the VM be installed or bundled which is a PITA, in which case "compiles to bytecode" is useless.
    - deleted 9y ago
      [deleted]
    - dnautics 9y ago
      sorry, i should have said compiles to a bytecode that's not half bad
masklinn 9y ago
OCaml seems to match a majority of the criteria, though AFAIK no "good IDE" (tooling like merlin is available, but if you're looking for e.g. a refactoring IDE you're probably SOL), the ecosystem is small, and it does have some historical baggage.
- cies 9y ago
  And with the ReasonML frontend there is a much more approachable-for-other-language-refugees syntax to it.
- Double_a_92 9y ago
  > - clean (nice syntax ...) Just looked at wikipedia examples and the code is full of special chars and shortened keywords. Doesn't look nice or simple to me, tbh.
  - masklinn 9y ago
    I guess beauty is in the eye of the beholder, though your eye seems questionable, the only "shortened keywords" I can find in the wikipedia page are "rec" (which is a long-standing shortening of "recursive" in recursive lets) and "fun" (for functions).
  - hajile 9y ago
    SML is what Ocaml should have been. With a few small syntactic changes (mostly to add some nice-to-have features), SML syntax would be better in every way instead of almost every way.
  - TheAceOfHearts 9y ago
    As another commenter mentioned, you might want to try out Reason [0]. It's a new-ish programming language from Facebook that uses OCaml as its backend. [0] https://reasonml.github.io https://reasonml.github.io
- mbenoni7 9y ago
  OCaml is great, but F# is better for almost every one of his bullet points.
lenkite 9y ago
Believe kotlin (especially kotlin-native) should soon relieve all those itches.
- oblio 9y ago
  Yeah, but Kotlin Native loses all the Java libraries. The more interesting thing would be Java native compilation coupled with Kotlin. So you'd write a Kotlin Java app and pass that through the Java native compiler introduced in Java 9. Unfortunately that's a beta feature right now, I think it only supports Linux x64, that's why I said Kotlin 2019, I assume that by then the Java native compiler will support all Java platforms.
  - pjmlp 9y ago
    Java compiles to native code since version 1.0, only not for free. All commercial JDKs had this option in one form or the other, and many of them are still around. If you want to try this for free on open source projects, Excelsior JET is one option.
    - oblio 9y ago
      I'm probably too conservative, but I'd rather use these kinds of things from the actual platform developers. I'm a bit more liberal with libraries, but in general I want the compilers/interpreters from the upstream source. Software has enough bugs as is :)
      - pjmlp 9y ago
        Commercial JDKs, like from IBM or OEMs for embedded platforms, are the actual platform developers.
    - mhd 9y ago
      > Java compiles to native code since version 1.0, only not for free. Well, there was GCJ, but I think that hurt more than it helped.
oweiler 9y ago
Kotlin covers all those features - much simpler than Scala while still being much more expressive than Java - clean syntax, with a higher consistency than e.g. Java - Generics, Higher Order Functions, Multiline-Strings, Destructuring, ADTs, Pattern Matching - Coroutines (experimental but production-ready) - IntelliJ Community Edition (or Ultimate) - not yet but will be possible with Kotlin Native - has its own ecosystem but also has great interoperability with Java - stable for quite some time, big community - well, a little bit for reasons of Java-interoperability; on the other hand
- _Codemonkeyism 9y ago
  I like Kotlin too, but in which way is it "much more expressive" in your opinion? What can you express in Kotlin that you can't express in Java? Scalas type system is much more expressive than the one in Java as an example. Only thing that comes to mind in Kotlin is non-nullable references. Most of the stuff in Kotlin looks more like less boiler plate (data classes) than "more expressive".
  - pabl0rg 9y ago
    It's not immediately obvious, but when you write some Kotlin you'll see. Little things that are a apin in Java and elsewhere are quick and natural in Kotlin: - nullable types are smoother than Options - null checks are relatively painless - the stdlib works with you, not against - named parameters and optional parameters means no need for builders - etc. Etc.
    - _Codemonkeyism 9y ago
      I have written some Kotlin, and perhaps it's me, but I don't see. "nullable types are smoother than Options - null checks are relatively painless" Might be the case, but Options are more expressive in that I can combine them and restrict them with other type classes to express larger constraints. Reusabilty is higher e.g. with Monad transformers like OptionT. So nullable types are less code, but also less expressive as building blocks of larger constructs. They might be also less expressive because they conflate two concepts: Not initialized and not-there, whereas Option expresses not-there and _ (in Scala) expresses not-initialized. "named parameters and optional parameters" Not sure how this more expressive?
beagle3 9y ago
Nim has everything nailed down except the ecosystem/commercial backing; It does have some of those, but not to the extent that I would blindly tell you they are there. It's as fun as writing Python (with a similar syntax), but it has essentially all the goodies you want from Lisp when you need them, runs as fast as equally optimized C, produces standalone native binaries, _or_ standalone JavaScript if that's your thing.
- egeozcan 9y ago
  I wish there was a Go->Nim compiler or a way to simply import stuff from Go :) I'm just half-joking to be honest.
  - beagle3 9y ago
    Go can generate .so/.dll usable from C; Nim can use them.
- reacharavindh 9y ago
  Cheers to Nim. I'm learning it in my spare time for fun. However, I will not consider using it for anything more than toy projects until it hits 1.0. Hopefully soon.
  - narimiran 9y ago
    > I will not consider using it for anything more than toy projects until it hits 1.0. Hopefully soon. It should happen soon (TM), but from what I understand it will be just another version, just this time renamed to 1.0 - this basically means you could start using it more seriously even now.
    - reacharavindh 9y ago
      Yeah. I understand that it will be just another version with not that many changes. Nim as it currently already feels stable and solid. But, I believe v1.0 release will carry a commitment to not introduce breaking changes at least for reasonable period of time after.
nicoburns 9y ago
Swift is a potential competitor in this space too.
s_kilk 9y ago
Take a look at Elixir, it covers most of what you want.
squeaky-clean 9y ago
I think my dream language would be C# but with a slightly more Pythonesque syntax (significant indentation, no semicolons or braces...). I wonder if a transpiler like that exists.
- mbenoni7 9y ago
  You can write "Pythonesque C#" today using F#. Once you get used to it, though, you'll probably want to write idiomatic F#.
hawski 9y ago
C38 (so when the world ends): - arrays with slices (that could also be used for strings) and Cilk Plus array notation [1] - maybe actual string type with separate concatenation operator (possibly space as awk uses and C for literal strings) it could probably be folded to improved arrays - standard SIMD vector types so that most use for operator overload disappears - cleaned up standard library - actual macros so the remaining use for operator overload disappears - module system (so you would generally not need make and could easily compile to static binary) - already you can build with static musl libc [2] - something like libdill [3] or libmill [4] in stdlib - there are multiple good IDEs, debuggers, analyzers - one of biggest ecosystems and communities - historical baggage mostly cleaned up [1] https://en.wikipedia.org/wiki/Cilk#Array_notation https://en.wikipedia.org/wiki/Cilk#Array_notation [2] https://www.musl-libc.org https://www.musl-libc.org [3] http://libdill.org/ http://libdill.org/ [4] http://libmill.org/ http://libmill.org/
dilap 9y ago
seems like Go 2 has a good chance of being this (at least if you consider its syntax clean, which I do). basically go is missing from your list is generics and string interpolation.
hajile 9y ago
I think F# has the things you're looking for.
didibus 9y ago
By simple, you mean easy? What about Java? Its easy, modern in the way you describe, has a good concurrency story, multiple great IDEs, can compile to a static binary with commercial JVMs, or experimentally in OpenJDK9. Really big ecosystem. Huge commercial backing. It just maybe fails at historical baggage and syntax. Kotlin fixes those last two. And Java 10 will also fix a good chunk of the syntax complaints. In all fairness though, I think you're focused on nitpicks that have no practical benefits. You're asking for a language with a better user experience. Which is great, as it can make programming more pleasant, and I'm all for it. That said, I'd focus on language changes that provide functional value. Haskell adds a powerful correctness layer at a low expressiveness cost. Go adds a useful CSP concurrency mechanism with green threads, as well as being friendly to containerisation. Erlang and co add a great deal of reliability features and massive parallelism with first class actors. Clojure gives you powerful metaprogramming, state of the art immutability and a similar CSP layer as Go, while maintaining the access to Java's large ecosystem. Kotlin adds null type checking, and better functional primitives. Rust gives you safe memory access without the performance overhead of a GC. Chapel allows for super parallel computing. Scala gives you OOP with the safety layer of Haskell on it. Nim gives you faster python, with type safety. Crystal gives you faster Ruby with type safety. Etc. Those are the languages that challenge the status quo, and have a chance at bringing real value in terms of the average output they result in when used to program with. A slightly better UX for Java or Python is a hard sell. Its like the famous Unix quote: "the most dangerous enemy of a better solution is an existing codebase that is just good enough." - Eric S. Raymond Java, C#, Python, Ruby, C++ are all good enough, even UX wise, to be displaced by something that doesn't offer compeling functional value. At least, in my opinion.

lbruder 9y ago

YMMV, but my experiences with SBCL were way better than with Go. Using Hunchentoot and the other Quicklisp libraries made developing fun again. With Go I had to constantly worry about errors, repeat the same code snippets over and over again, had to comment out "unused" variables just to try something... not fun. That said, let's see how Lisp works out once I cross the 10'000 LOC barrier. But by then it won't be a microservice anymore, anyway...

TurboHaskal 9y ago
The problem is getting people to actually code in CL or any Lisp. I haven't had that problem with Go so far.

weberc2 9y ago

I haven't had a problem with testing in Go, but I also don't mock many things. Most things that should be mocked are already interfaces in my code. My biggest grievances with Go are its limited type system and dependency management. Unlike most[^1], I don't need semantic versions--I just need deterministic, reproducible builds, and for that, vendoring is fine in theory, but Go's tooling around it needs work. I love that Go is a language that can be mastered in a matter of months; that it has such a simple "get up and running" story; that its tools mostly do the right thing by default; and that almost everything is straightforward. In most other languages, I have to figure out what build system to use, how to script it, how to specify and download dependencies, what testing library to use, how to actually run the tests, how (if it's possible at all) to get a static binary, etc--and then I usually have to learn a complex language on top of all of that. For the most part, Go just works out of the box. I think folks also underappreciate Go's runtime--it has a fast garbage collector and an awesome goroutine scheduler that all get statically compiled into your application binary. Mostly, I want a functional language that compiles to Go so I can still leverage Go's awesome tooling, runtime, and deployment model, but with things like generics and algebraic data types. I've started prototyping it too, and so far it's coming along smoothly (modulo all the things I'm learning about building a programming language). On that note, there is some effort going on in the Go community to build a VM for Go, which would probably make an even more attractive compilation target, at least from a toolchain perspective. Even if my project doesn't take off (and it likely won't), I think this is a low-effort way to address Go's most significant complaints. [^1]: Well, "most" judging by the significance many of Go's critics place on semantically versioned dependencies

mrhwick 9y ago
Have you used dep? https://github.com/golang/dep https://github.com/golang/dep
- weberc2 9y ago
  I have, but early on and not much since. I forget my particular issues; I just remember at the time there didn't seem to be a way to do what I wanted (I think it was adding docker as a dependency).

sethammons 9y ago

Chances are, if you are using mocks in Go, you are doing it wrong. Functions should take interfaces (not interface{}, but interfaces that list methods) and return structs. In your tests, you create a fake that meets the interface and pass that to your function under test. If you have to test file io or DB interaction, you can either do the adapter pattern or, as I prefer, just actually use the filesystem and DB but with some test infrastructure around it.

deleted 9y ago
[deleted]
AnimalMuppet 9y ago
What's the difference here between a "fake" and a "mock"?
- sethammons 9y ago
  Might be splitting hairs. There are fakes, mocks, and stubs. Generally, mocks assert, stubs do not. Some folks define both stubs and mocks as fakes. This does not fit perfectly for Go. The "fake" in Go is just a struct that matches an interface but is purely for testing. It allows for dependency injection where you pass a fake designed for your test. It can have its own properties and helper methods, but the key thing is that it matches your interface. You don't make assertions against the fake like you would a mock. You assert against responses from your functions under test. Example: > type Bar interface{ > Walk() (int, error) > } > > func Visit(b Bar) (string, error) { ... some code ...} In the production code, you call Visit with some struct that matches the interface (has a Walk method). In tests, you create a new struct like fakeBar that also matches the interface. You can have your fakeBar return any string or error you like and you can verify that Walk behaves the way you need it to. Hope that helps.