Sweet.js  did it for me initially as cspjs had async, await and more years before ... but I never found the time to ramp up to the updated version sadly so I can't comment on its state now.
The full quote:
> The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
-- Rob Pike, 2014, at ~20m50s of https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr...
The learning curve seems to be with other aspects - like where the hell do I put my I/O? Error handling? How do I trace (or write) all these functions that are piped or composed together? Questions like those are what I tend to see. Both personally and when pointing other people to F#.
But ya, functional oragami will make debugging harder even in C#.
You as a user can choose to live with those decisions or use a language that gives you more freedom. All such decisions come with a series of tradeoffs. Just make sure you are making the decision in as informed a way as you can.
I would say that using Nim's metaprogramming capabilities to create a great SPA framework is a better direction than creating a brand new language.
BTW: I've read your book, great job! The "Advanced concepts" part was a bit too short (I'd gladly trade some of the earlier chapters for more examples of both FFI and metaprogramming), but I generally enjoyed the book.
Also, I like how the code listings are annotated - how did you generate them? Is there some software specifically for this, or did you have to position all the arrows and lines and text manually?
We need you to help us change that :)
> BTW: I've read your book, great job!
> Also, I like how the code listings are annotated - how did you generate them?
I used asciidoc to write the book and then my publisher applied some magic to format everything nicely. Not sure about the details I'm afraid.
Macros allow you to introduce dialects which can be powerful in their expressiveness but often result in significant departures from the original language.
When someone new comes into the project they have to learn the dialect before they can even read the code. More often than not they give up and rewrite the code from scratch in a language they understand.
Sometimes additions to the language make sense, but there's a real cost, a cost that often gets ignored. Do it to much and you kill the golden goose.
The go language seems more than anything to be "you can use our language, but it serves us and our wants first and foremost."
Now, I like the enforced style guide. That's not my gripe. It's that go deliberately treats certain platforms as second class, deliberately treats feature requests as second class if they are not complementary to what the original creators intents.
I don't wanna get shot for opening the can of worms about generics for the millionth time, but it just seemed like such an obvious solution to a widespread, pervasive, irritating problem. It was an issue early on, before there was really a lot of back-compat surface to even think about, but it wasn't what the Google posse wanted, and it didn't happen.
In the case of go, I believe the true cost of making it better is that Google is learning that when you use an internal product for a wide array of projects, and then later on you decide to flesh it out and open source it, you lose the ability to react to your audience as easily and that also narrows the surface for people to come in fresh to the project and contribute or provide feedback.
Go shot it's own foot. We (non-googlers) certainly didn't do it to them.
All this aside, the technical prowess at work on the team, especially in the past twoish years has been really impressive. At least they have stellar developers.
If they are anything like Guido for Python, I think the idea is quite the contrary.
Language users are smart. Just too smart for their own good.
Like the coyotes we talked about recently on HN (https://news.ycombinator.com/item?id=17079369) who are "winning the mini-game of each human interaction, but they are losing the meta-game of what society will do if coyotes aren’t scared."
Well, just like that, language users with macros are winning the mini-game of their interaction with the current opened files in their editor, but they are loosing the meta game of maintainable projects, shareable knowledge and reusable tools.
Macros (or their small brother, "just a little DSL") are the most abuse feature in dev, period. They are too clever, the results almost never documented or even tested properly while often being very specific to the creator use cases.
I really think macros are one of the reasons why Lisp never became more popular: a small smart population love it for macros while the rest of the population just doesn't want to have to deal with all the macros BS created by the former population.
Same for Ruby. Honestly, having to go through yet another DSL du jour killed it for me.
So my guess is that the Goland creators know very well how smart the language users are. And they are afraid, very afraid.
By echoing this in the echo chamber, we've perhaps deprived ourselves of getting enough collective experience with powerful programming tools to be able to establish good norms to teach high power maintainable programming. We're instead stuck in low level language wars.
Using type systems for system design anyone? Use Beta abstraction systematically?
That would be fantastic.
But right now most companies have a hard drive finding decent middle level dev.
Let's talk about your plan when american companies don't hire me to work from my bedroom in the south of France because they can't even find what they need in their own country anymore.
Unless you have a recipe to turn people that strugle with fizz buzz being able to magically understand complex abstractions.
Are these the same ones who are "too smart for their own good"?
But they do satisfy a lot of the desire for syntactic abstraction -- see e.g. https://github.com/erights/quasiParserGenerator
Personally, I never used OCaml on the frontend, but have some experience writing native apps in it and it's a really good language. Its type system is top-notch, its object system is unorthodox and powerful, the camlp4 macros allow for adding new syntax to the language - and so on. Worth taking a look at if you're searching for strongly, statically typed language for the frontend.
And of course, there's Elm if you want to get a completely different thing.
What about an action creator / reducer isn't dry?
I know somebody is going to jump in and tell me I’m wrong, that they’re using Elm in production and it’s the best, etc. This is my personal experience from using Elm on several side projects and also in production at my last job.
It was the same thing when Ruby on Rails hit it big; some people swore by it and others detested it. It's like having a car that will only turn left, as long as you need to go left the car is perfect for you.
Elm works for me and makes me happy. I couldn't ask for more. Any perceived slowness in initial development is gained later by very solid foundation on which I work. Again, all you said is true.
1) The language development pace (localStorage does not have an Elm equivalent, let alone service workers, etc)
2) The Elm ecosystem is very closed and only one person can actually release powerful libraries in the blessed package manager.
As has been said in other thread, for some that's great news, for others it's limiting.
In a sense it tries to be like Elm:
- good developer experience with nice error messages
- single binary that have all the tools
- enforcing types
- no runtime exceptions is you don't use JS interop
In an other sense it tries not to be like Elm:
- JSX syntax with easy compose-ability
- Straightforward JS interop
- Decentralized and open package management
Syntax is not such that I am immediately sold, but also not put off. What I didn't see is some performance promise like Elm, or simplicity, where it make sense to use this over anything else.
I think it is good that a lot of people are thinking about languages and how to improve development, not everything has to be ground breaking. I will keep an eye for future work and how it develops.
> What I didn't see is some performance promise like Elm, or simplicity, where it make sense to use this over anything else.
I was focusing on the example, it seems I should really put up more information about this on the website, but to answer for this is basically:
- it uses React under the hood meaning you have the same performance, the devtools works the same, it is possible (with some work) to use components from Mint in React and vice versa.
- the error messages are really nice (there 281 unique error messages overall) both for syntax errors and type errors
- easy JS interop using backticks
- no import statements
- fast compile times (the website compiles around 1 second)
- single binary with all the tools included (development server, production builder, favicon generator, test runner)
Is there itsokay statement to pacify the compiler more?
Result of 'a | Void
Yes, this is what I'm worried about.
I'm still tweaking a lot of things and I wanted to share it with HN when I thought it was ready, but on the other hand it's a nice that it got some attention already.
I hope there will be enough interest over time to actually build up a community.
"Nothing to see here." literally.
If I decided I wanted to use Delphi, but I didn't like Object Pascal, so I implemented a Scheme over the top that gave weird deep backtraces with wrong line numbers whenever an error occurred, compiled to a single-line semicolon-delimited mess of unidiomatic Pascal, and often required me to write some Pascal anyway, you'd think I was nuts. Why do we think it's a good idea just because it's in a browser?
Think Elm: it's impossible to produce side-effects or mutate objects, cause the language simply does not have the facilities to do so. The guarantees Elm gives you would be hard to maintain if it was just a library which had to deal with JS's constant dynamicness.
Moreover this guarantees do not only improve developer experience; but also compiler optimizations.
If I'm trying to make a thick-client, I'd rather build it in a language and platform that I don't have to fight quite so much.
Depends on scope and number of developers I guess.
And this is true for many more languages (Flow, PureScript, LiveScript, IcedCoffeeScript, ...) which don't innovate on many aspects but just offer a slightly different - sometimes improved - syntax. I do recognize that many languages add value, but that must be offset to the cost of using these languages. Costs which are often quite high: Googleability, StackOverflowability, documentation, tooling, develop mindshare, library support, stability - these things don't come cheap and take years to mature.
Furthermore, these "innovate slightly" languages in the webspace take away resources from improving the current state of the art in mainstream (EcmaScript, TypeScript, Dart, C#, Java, ...). For instance, instead of improving some JS tool now resources go into e.g. writing a language server for aforementioned language.
A good example is Elm which does try to innovate on core concepts (builtin reactivity). That's a conceptual feature which can bring the state of the art of programming language design further.
Last, I do not mean that we should not write any more new languages; but we should stop trying to get large-audience adoption for "innovate-slightly" languages. It's a waste of braincycles and actually hurts the ecosystem.
Algebraic data types and pattern matching;
Row polymorphism and extensible records;
Higher kinded types;
Type classes with functional dependencies;
Higher-rank polymorphism" http://www.purescript.org
For example, why do you consider TypeScript to be a "state of the art in mainstream" worth improving, and Flow to be just an "innovate-slightly" language? Those two projects are very close in nature. And if the key difference is adoption, then why is Dart along with EcmaScript and TypeScript?
Flow is a nice comparison as it is also backed by a large company. They don't offer a developed IDE in tandem, development pace is a lot lower and language features are not that many compared to TypeScript. The "innovation factor" is a lot lower - of the level I think it's not worth pouring resources into it.
Idk whose "side" I'm on here, but I didn't want to lose an opportunity to blurt out my love.
It's a shame dart is being managed by google. I wish they had been more hands off with the dart team, as they are deviating from server-side go so people can write mobile apps in dart. Even though they'll look almost exactly like C# apps but with better types...
Anyways yeah. Dart. Cool types. Good vm. Gilad is a cool guy.
(I have been considering Dart for a while, but haven't taken the time to look into it because it doesn't seem like it provides additional benefits compared to other languages (apart from the Flutter aspect).)
Anyways, you could check for certain major structural errors in unchecked mode and compile very fast, and then when it's time to start propping up a release, you can turn on checked mode and catch more intricate errors.
Gilad has been working on gradual/optional type systems for years. (they are technically two different ideas but the difference is rather academic and of little use to most programmers)
Anyways, dart has strong generics, it can do contravariance easily which makes refactoring code without breaking existing call sites, the dart lang spec has a great section on this.
In addition to all this, dart has really good reflection support through mirrors, a concept I'm not very familiar with, but it makes possible a tool called observatory, which is awesome. You can have source maps for dart2js, you can see which individual classes or methods or even lines of code are being utilized, you can get a lot visualizations about your performance profile, you can look at dart from the inside of dart. It's a lot like smalltalk, but way more practical.
Sort of like how rails took a perfectly good language and destroyed it, flutter seems to have built a foundation for taking dart and exploiting it.
Now they say its client-oriented" which I assume is googlese for "if you're not using dart for flutter, fuck off."
There was also a dart llvm effort at one point, but that became too useful and was abandoned.
If you are looking for a really good functional language for web, consider F# if you have dotnet experience, or bucklescript if you have ocaml support, scalajs if you have jvm experience and also love shitty tooling, and finally, purescript if you like haskell.
HN likes Elm a lot, but it's a little too opinionated for me, and although I like the BDFL approach to FOSS, it doesn't mean that you should be the ONLY developer in the core. That makes me exceptionally nervous about adoption, especially for professional work.
YouTube search for "gilad is right" for some talks that he's given. There's one where he dives in depth to the type system and how checking works.
Sorry for no links, literally using 2G right now, travelling.
Yeah, I am unhappy that they are focusing Dart more on the client side (another reason, I didn't look too closely at it) -- focus like that is probably good for language adoption in some niche, but it would be nice to have a good strongly typed language that also has good support, good tooling and extensive libraries for use both on the client side and the server side (and for mobile app development!) so you have only one language to deal with everywhere. Dart is one of the few languages that from the outside seems closest to that ideal.
I'm kind of at the age where I'm just too far removed to try and work on learning a whole new field. If I could go back, I think I'd choose type theory and compilers and spent longer in college. Instead I learned to reverse software and built my career up piecemeal, but there is so much fascinating material surrounding compilers and the intricacies of how different type systems behave and allow modeling. I see how people get their whole career sucked up into that space.
F# still has a chance if dotnet can step their game up just a few more notches. They're getting better lately.
What is Gilad up to now, I wonder?
For such a talented researcher, that's gotta be demotivating for him. Bless him.
I guess dart is basically ceylon now but with contravariance? Gradual typing gave it such a unique space.
I'm glad to see him in a position where he will be able to be more explorative though, that's gotta be a relief for him. I'm sure once flutter started picking up more engineers he probably knew then what the outcome would be and how his directional influence would start to be limited.
Sometimes these projects wither and die. Sometimes they find niches where they’re particularly useful. Sometimes they hang around with a core of dedicated users. Sometimes the ideas they introduce go on to influence other languages. Those are all beneficial.
I’m surprised to see this same complaint levelled so often.