41–50 of 207 posts
Earlier quoted context omitted.
Elixir compiles to bytecode which is not half bad
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.
What I've noticed, and personally experienced, about these porting projects is that they're generally a premature optimization but are a great way to learn a new language. The gains from a port are largely intrinsic in nature, residing with the programmers. However, systems and operations largely carry on just fine with the original language chosen. Only one story comes to mind where a programmer had a legitimate pro…
The story I see over and over again as a startup CEO consultant.
Earlier quoted context omitted.
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…
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 ecosys…
Most of the stuff in Kotlin looks more like less boiler plate (data classes) than "more expressive".
Earlier quoted context omitted.
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…
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…
Crazy attracts crazy, now you know.
I can agree with most of the article, but for some it looks like we have not been using the same language ecosystem at all. Go really feels opinionated around the wrong things, in order to claim "simplicity" as a feature: - No generics just mean you're going to be handing interface{} all the way in your stack, it makes things more complex and less readable for no reason (and less safe) - error handling which is essen…
Python packages are installed via a separate tool so I'm not sure what you're getting at here.
Including github in the import path is a good idea. It makes it so you always know where the source code for any package is. This consistent approach empowers sites like godoc.org. I don't know how many times I've tried fruitlessly to find documentation for libraries in other languages, but in Go the developer who created the library gets it for free. I wish more languages did this.
Do you remember the left-pad fiasco in npm? Out of the box you'll have similar problems in Go, but at least you'll get them when you work locally, not when you spin up a new node. And to fix the problems you end up having to do the same thing regardless. Either you vendor your dependencies or you setup some sort of caching middle-man proxy.
Go's dependency headaches aren't the fault of the language or the ecosystem - Go actually has a really well crafted module system, specifically designed to fix major performance issues in languages like C++ and Scala. Rather they're a reaction to the problems latent in the "easy" solutions and simply switching is just trading one set of problems for another.
What I've noticed, and personally experienced, about these porting projects is that they're generally a premature optimization but are a great way to learn a new language. The gains from a port are largely intrinsic in nature, residing with the programmers. However, systems and operations largely carry on just fine with the original language chosen. Only one story comes to mind where a programmer had a legitimate pro…
What I've noticed, and personally experienced, about these porting projects is that they're generally a premature optimization but are a great way to learn a new language. The gains from a port are largely intrinsic in nature, residing with the programmers. However, systems and operations largely carry on just fine with the original language chosen. Only one story comes to mind where a programmer had a legitimate pro…
Developers have the gain, company suffers, developers move on for higher salary with more skills, CTO is in it, doesn't fullfil his duty towards the company or investors, CEO has no clue and doesn't manage the CTO. The story I see over and over again as a startup CEO consultant.
Developers learn a new language that is faster to develop, safer and faster to run than existing solutions (which work but are of increased technical debt) and successfully & quickly port the existing solution to the new tool.
The company doesn't really benefit from it apparently because they never scale enough or because they lacked a target so they had their developers working on sth small instead on working on the company's products.
This skill is highly valued and the developers leave for an other company while the original one struggles to continue.
Do you think that it may be the case that the problem in all these is not within the developers or tool? Furthermore, shouldn't the CEOs and the CTOs know better and to a better job?
Earlier quoted context omitted.
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.
> it's definitely a "Windows First" language C# used to be that but I don't think that's the direction anymore.
Earlier quoted context omitted.
Developers have the gain, company suffers, developers move on for higher salary with more skills, CTO is in it, doesn't fullfil his duty towards the company or investors, CEO has no clue and doesn't manage the CTO. The story I see over and over again as a startup CEO consultant.
So if I get your argument correctly: Developers learn a new language that is faster to develop, safer and faster to run than existing solutions (which work but are of increased technical debt) and successfully & quickly port the existing solution to the new tool. The company doesn't really benefit from it apparently because they never scale enough or because they lacked a target so they had their developers working o…
Most often only in the eye of the developers with no proper evaluation.
"Furthermore, shouldn't the CEOs and the CTOs know better and to a better job?"
Yes.
Earlier quoted context omitted.
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…
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.
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.