
The Big Bang project aims to create a typed language with the feel of scripting - luu
https://pl.cs.jhu.edu/projects/big-bang/
======
m0th87
I feel like this is the direction Julia is going in. It's in this interesting
space between statically and dynamically typed languages - technically it's
dynamically typed, but you get a lot of the safety and performance guarantees
afforded by static type systems through Julia's aggressive type inference [1].
As the type system gets richer, it should only get better on this front.

If you haven't checked out Julia yet, it's a beautiful language. There's a
reason why Graydon (the guy who made the very early versions of Rust) likens
it to a Goldilocks language [2].

[1] [https://stackoverflow.com/questions/28078089/is-julia-
dynami...](https://stackoverflow.com/questions/28078089/is-julia-dynamically-
typed)

[2]
[https://graydon2.dreamwidth.org/189377.html](https://graydon2.dreamwidth.org/189377.html)

~~~
mamazmaz
The difference between Julia and Big Bang is that Big Bang will check your
types at compile time. You'll know before any of your code executes whether or
not it will yield any type errors.

Edit: (Disclaimer, I work on big bang)

~~~
KenoFischer
How do you handle, say deserialization of objects over a network (to give the
canonical non-trivial example)?

~~~
eru
I don't know about Julia or Big Bang, but in Haskell your values conforming to
types for serialization / deserialization would typical be checked once when
parsing, and throw an error (or use a Maybe type) if anything is off.

~~~
KenoFischer
Yes, that's the standard approach, but I was wondering how that meshed with
not having to declare types (maybe the answer is just, that's the one place
where you have to - or that's disallowed), but I was curious.

~~~
eru
In Haskell, if you don't do anything weird, you don't have to declare types
either in the norm case: it can all be inferred.

------
gaius
Someone beat you to it [https://donsbot.wordpress.com/2010/08/17/practical-
haskell/](https://donsbot.wordpress.com/2010/08/17/practical-haskell/)

~~~
mamazmaz
Haskell has an equational type system, and doesn't support subtyping in the
same way that big bang does.

(Disclaimer I'm working on big bang, so I'm a bit biased)

------
oneJob
Chapel Programming Language? By which I mean, Chapel seems like a great
project to through support behind to add these feature sets. It is already
very capable, had a good amount of resources, a roadmap, and seems that it
would lend itself to this.

------
brightball
Doesn't Go basically accomplish that via near instant compile time?

~~~
NhanH
Not quite, polymorphism is a bit iffy in Go (there is interface, and it's
doable but not great). Type inference is extremely limited (this is also due
to a weak type system, with comparison point being ML-family languages for
examples) . Global type inference is off the picture without generic/
polymorphic typing.

I don't think Go achieves the look and feel of working with Python and the
like.

~~~
s3nnyy
The go philosophy is that inheritance "does not scale" and they deliberately
went another route:
[https://golang.org/doc/faq#inheritance](https://golang.org/doc/faq#inheritance)

~~~
bjz_
Errm - where did the parent say anything about inheritance?

~~~
albemuth
Isn't the feel of working with Python all about inheritance?

~~~
johntb86
Duck typing is far more important.

------
vfclists
Use Nim

~~~
tomp
Doesn't Nim require types (e.g. for function arguments)?

~~~
jboy
In Nim, you can use the type `auto` for proc parameters & return types:
[http://nim-lang.org/docs/manual.html#types-auto-type](http://nim-
lang.org/docs/manual.html#types-auto-type)

When you use the `auto` type, the compiler will infer the type automatically
from the context of the proc invocation or from the proc body. The inferred
types can be different for the different parameters. So you can have a proc
declaration that looks like:

    
    
      proc inferTypes(a, b: auto)  # `a` & `b` can accept different argument types
    

Within a proc, you can also create bindings & variables without needing to
specify a type:

    
    
      let iBinding = 1
      var fVariable = 1.2
    

The following typeless code will compile & run without any complaints or
problems:

    
    
      import strutils  # `%` operator
    
      proc inferTypes(a, b: auto) =
        echo "$1 $2" % [$a, $b]
    
      proc main() =
        inferTypes(25, 30)
        inferTypes(1, "hello")
        inferTypes(4.4, 7)
        inferTypes("cat", 9.5)
    
      main()
    

When the above code is compiled & run, it will produce the following output:

    
    
      25 30
      1 hello
      4.4 7
      cat 9.5

~~~
jerf
How does Nim hold up if you put "auto" everywhere you possibly can in a non-
trivial program? (Tone note: Straight question. I have no idea and am honestly
interested.)

Context: Type inference is hard. Hindley-Milner is famous for making it
possible, but the farther you stray from it, the harder it gets to do with no
human-added annotations. I hope the authors of "Big Bang" are intimately
familiar with the issues involved or they're going to be in trouble. If they
aren't they ought to correct that.

I'd also suggest that the Haskell community would be happy to share their
experiences on that front if they are asked, and unless the authors are
already experts, they _really really_ should ask. Only good things can come
from asking.

~~~
jboy
I don't know, I'm sorry.

(The majority of my professional & personal programming has been along the
Shell-Python-C-C++ axis. My preference for static types increases
approximately logarithmically with the size of the program; historically, I
preferred Python for most quick scripting needs, but for larger programs, I
was glad of static types, so I would switch to C++.)

Now, Nim has replaced C++ for me completely (and also expanded downwards into
the upper end of Python's territory). The work I'm currently doing in Nim is
well into the "I prefer static types" area of the spectrum.

Maybe some of the Nim core devs would have more experience with this
situation.

IIRC, several of the Nim core devs are familiar with Haskell, and consider it
to be one of the reference languages guiding aspects of the Nim language
design.

