Maybe, or maybe there is an emerging space for a service that would count stars, forks, etc on all versions of a repository and aggregate the values. But I would hate another centralized service.
TL;DR I'm famous and contributed to the Python community, I'm depressed (it's real! Check this references) because people don't like me forcing them to use my tool. these people must be awful.
Java is compile to bytecode which is then interpreted by a virtual machine, it's not compiled to native code, that's why you cannot distribute Java programs as executable like go.
Is there a way to bundle the JVM (or the parts you need) with the Java app you'd like to run? Erlang (and Elixir) does this with the Erlang VM (BEAM), allowing you to bundle VM+app as a release. The Erlang release must be compiled for the platforms on which that release will be run. It's not quite as elegant as a Go binary, but it's still pretty handy.
Java has a specification and has lots of implementations.
The majority of commercial implementations of Java have native code compilers, and Oracle is in the process of improving the AOT compiler introduced in Java 9.
It's been like this forever, the police have access to so called "information management system" directly to QQ and later Wechat. There is no other way to talk to people online, you are monitored in all channels. They have no choice, anyone that doesn't cooperate is blocked. Also the sense of "Privacy" is very weak among Chinese, they are brain washed enough to believe "what are you afraid of if you have nothing to hide". So yeah people will continue to use Wechat and other social channels in China.
> ...they were almost dropped from .NET schedule as being "academic only"
For all the good that has come out of .NET, and the nice platform it is today, there are a lot of high level design decisions where the team decidedly landed on 'the wrong answer'. To their credit they've been moving towards 'the right answer' for a while now.
Auto-wrapped properties instead of exposed value fields. Smart initialization. Safe default values. Generics. Anonymous functions. Nulls. Higher order functions.
Still under way: pattern matching, DSL support, option type, type aliasing, etc.
Related, but I also find it highly fascinating on those topics how much of Visual Basic's design they ignored, derided, and have then had to re-implement after-the-fact. A lot of babies got thrown out with the COM+/VB6/MFC bathwater.
> A lot of babies got thrown out with the COM+/VB6/MFC bathwater.
Not sure what you mean here, COM has become the main way of doing Windows APIs since Vista, going full circle to the original design of COM Runtime with WinRT (now UWP).
I was referring to the APIs, components, and language experience that got recycled incompletely as they were ported into .Net and "abstracted away", moreso than how components are marshaled :)
COMs resilience in the face of competing models, as you've pointed out, and the fractured GUI landscape of the windows client platform are symptoms, IMO, of ceding a pretty mature platform for something almost, but not quite, as capable. It has taken .Net over a decade to relearn lessons won painfully for the VB5 and VB6 teams, and I believe they lost a lot of larger systems because of WinForms restrictions in the 2005-2009 window.
I think the ideal is something close to ML-style polymorphism a la OCaml/Haskell, or F# on .Net.
The generics in C#/Vb.Net are pretty nice too, but their absence in the language during the design of the original standard libraries is still felt (typically along IDictionary and ICollection interfaces).
It seems obvious in retrospect how useful they are, but I do remember lots of contemporaneous "debate" about how academic and complicating they would be that turned out to be. My personal opinion is that these debates were relics of the C++ contingent of the ecosystem, and less applicable to languages running on top of virtual machines.
C# was originally trying to copy Java, a language that took influence from C (weak types retrofitted) and Smalltalk (no static types at all). Industry has since learned a lot about the tremendous value that types bring. Other forms of static analysis are now gaining popularity too.
For the record I'm not trying to argue generics are not important, on the contrary having worked with them for years go seems to be too limiting in this matter for my practical use.
But I agree they can be tricky to get right (compare e.g. declaration-site vs use-site variance [0]) or "accidentaly Turing-complete" TypeScript [1].
> hell no, if generics get into go I'll have to find another favorite language.
Well, I hope go get generics fast then. Seriously, what is this community that rejects any possible enhancement to a language? Even C gets new features albeit slowly. A language that doesn't evolve is a dead one.
There is nothing complicated with generics, they are just incomplete types, that's all. Generics =/= C++ templates.
Ada has a great implementation of generic programming which forces the developer to complete generic types before using them. In fact Ada got a lot of things that go got wrong despite being way older, especially when it comes to concurrency and types.
Package based generics make them completely compile time and runtime safe, no type erasure. The'd be the equivalent of reflect.MakeFunc or reflect.MakeStruct at compile time, so without any performance penality or ugly reflection, which go has right now.
I'm on the fence about generics...but to answer your question generally...it's not all 'enhancements', it's making a language less readable. Sure, I can choose never to use it. But now I have (more) trouble reading others code. Go's strength, to me, is readability.
Why? Like, I might have weird taste, because I really liked generics and even Java-style checked exceptions :-) And to me, generics always sounded like the most practical way to do safe code-reuse across various types.
They add complexity which makes understanding and auditing code much harder. Look at OpenSSL and their overuse of macros, or heavily-templated C++ code.
No one is asking for C/C++ style macros, or even C++ templates. Go generics would be closer to Java or C# generics, which increase code clarity, reduce boilerplate and copy/paste code, and communicate intent.
Yeah, I can see how having features added to your favorite language while remaining fully compatible with the code you write today would warrant such a reaction. I mean, just having them in your language, even if you don’t have to use them is just so horrible.
I think it would be naive to believe that adding generics to Go would have no effect on the stdlib, third party packages, and ultimately how you write Go code.
Well the same is true for multiple languages which will mean not everyone has to use Go. Especially when there are so many interesting languages to choose from.
I don't know why you're downvoted. Generics is a feature that's holding back a lot of developers dealing with complicated business logic (and need for abstraction) from moving to Go. And at the same time, including generics into the language means that all libraries will add generics interfaces - and most probably, stop supporting the old, non-generic interfaces in some time into the future, breaking backwards compatibility at some point.
I am one who downvoted that statement, because I considered it a snippy remark without any content. Especially, as the question of generics in Go has been mentioned and discussed often enough. And if one feels the need to restart that discussion with each Go release, one should do so with an insightful comment.
I do not agree with your comment. I don't see how generics are needed to deal with "complex business logic". Yes, ultimately I would like to see generics added to the Go language. As does the Go development team. But, as they have clearly laid out, this is not a trivial undertaking. There hasn't yet been an implementation concept presented, which fits into the Go framework with its design goals.
And until then, I am quite happy that they didn't implement some half-finished concept.
> I don't see how generics are needed to deal with "complex business logic".
Complex business logic really has no place in Go. I would advise people to use more expressive languages (ideally with a modern type system). Go was designed for low-level network systems programming and is not well suited to more high-level problems, despite what the hype train might claim. I see the future as a polyglot one. Folks should use the most appropriate language for whatever domain they are currently working in and not let their careers be defined by any one language or technology.
And Java was designed for toasters. But enough people worked on it made it one of the most popular general purpose language of all times. A lot of folks do not have time to evaluate most appropriate language for a given task at hand and they would rather write code for their needs in a general purpose language and be done with it.
Sure they tried to make it work. But it did create a static typing and OOP backlash. IMHO, too many of us succumbed to the marketing. Many would have been better off using OCaml or Python, both of which were released about the same time (and OCaml has always shipped with "generics"!).
I didn't bring the term up, but I personally understand it to mean complex domain-specific code. Some examples from my own workplace: pricing/risk of derivatives transactions, financial contract definition, portfolio optimisation, interpreters/compilers for various complex data transformations.
It's not so much "we should add generics but no one is really working on it" it's more "we should add generics and we've tried a dozen designs that haven't really panned out and we're still working on it".
That's what makes me think they will end up happening.
Adding generics to Java and C after several years, shows how successfully the "wait and see" actually works, versus languages that have supported them from the get go.
CLU was designed in 1975 and ML in 1973, several languages with support for some kind of generics have been born and died since then.
So in 42 years, there wasn't a single generic implementation that could fit Go's design goals, other than not having generics at all?!
But Go has not existed for 42 years. Fitting any of those models on Go is exactly what should be avoided unless one of those models magically was a perfect fit for Go which came out just a few years ago.
Magically? It would take magic for one of these models to NOT be a perfect fit for Go.
The fact that Go "has not existed for 42 years" is irrelevant -- almost all of its characteristics have been present for 3 to 5 decades, even altogether in the same language(s).
"..Updated 2015-09-25: So, about six years later, people are still reading this. I'm not sure how to feel about this; Looking at it now, it's incoherent, badly argued, and a lot of the details are simply wrong. But 1000 hits a month indicate that people still get value out of it."
But this article link is still quite handy for random proof of Go badness.
Especially since he adds "Don't get me wrong; I still think that Go is a terrible language. I now work for a company that does a lot of it, and every time I touch it it depresses me a little more".
The "wait and see" approach as you call it, means that "Generics" (a.k.a. parametric polymorphism) have had to be retro-fitted to languages like Java. This means they are more complex than they need to be and have some ugly edge cases.
This. We still can't overload foo(List<Integer> x) and foo(List<String> x) because vintage 2004 JVMs wouldn't be able to distinguish them. Type erasure was a horrible compromise from which Java will probably never completely recover.
In C11 they are even uglier with the _Generic selector, which understandably was made to work together with how generics were done via pre-processor macros.
These two statements are arguments for different discussions:
> I don't see how generics are needed to deal with "complex business logic".
Here, we're talking about what user (developer who chooses between Go and Java) needs or wants. User doesn't care about costs behind the product.
However, instead of proving this statement, you jump to a different perspective whatsoever:
> But, as they have clearly laid out, this is not a trivial undertaking. There hasn't yet been an implementation concept presented, which fits into the Go framework with its design goals.
And here you're estimating things from the cost perspective; and it quite logically follows that it's not rational for Go developers to dive into generics at the moment. Just keep it mind that this decision means that Go stays unappealing to users like me.
No, I am not talking about costs at all. First of all, I don't see how complex business logic requires generics. I have written complex business applications and not required them. I really have no idea why you would "need" them.
And also for the Go developers, it is not about "cost". They have no idea how they could implement generics without fundamentally changing the Go language to something different than what it was about before. They are working on concepts, but nothing resulted what would be a candidate for implementation.
This boils down to how much one values static types and code reuse. If you do not have Generics (a.k.a. parametric polymorphism) then you are forced to make a choice between type safety and code reuse. You cannot have them both.
I imagine the downvotes are because it doesn't really add anything insightful. It just looks like whining.
Personally, I don't get the fuss. If you want generics, go use Java/Kotlin/something else. I don't see anyone complaining about the lack of generics in C or brainfuck, what makes golang special?
Because C actually has better support than Go for generics.
They could be faked with macros since the early days, which was what Borland's BIDS framework in Borland C++ 2.0 for MS-DOS made use of, dropped when version 3.0 with initial template support was released (around 1992).
Additionally, C now has basic language support for generics in C11 with _Generic.
Except adding tools for doing some kind of macros is much simpler in Go than C because the language is easier to parse. What stops you from using a preprocessor in Go? It is not really part of the compiler in C either.
People like 90% of Go e.g. simplicity, build process, speed and feel that if they added features such as generics, decent error handling e.g. Option or Exceptions then it might go to 95%.
Everyone is looking for that perfect development platform.
> If you want generics, go use Java/Kotlin/something else. I don't see anyone complaining about the lack of generics in C or brainfuck, what makes golang special?
Because it's painful to see a language that would be just perfect for a LOT of things with just ONE extra feature - but without this feature that is a requirement, we have to chose alternatives that have irritating downsides.
People have been using Basic and similar for ages to successfully implement business logic without generics. What is necessary for business applications is good integration with databases and reading/writing in various data formats.
That typically depends on reflection facilities provided by the language, not genetics. In fact genetics, unless done with extreme care, inevitably makes reflection API more complex. In turn that makes it harder to write readers/writers for typical business formats harming the case of business applications.
Basic got generics long time ago in Visual Basic.NET.
I have been coding since early 80's, naturally I have delivered lots of production code without generics.
Oberon, one of my favorite language family and influence to Go, which I used for a while, also did not had generics.
But that was in 1996, when generic programming was WIP in ANSI C++, ML compilers were starting to be adopted, Ada was too expensive, Java and .NET were yet to come.
In 2017 I only use static typed languages without support for genericity when forced to do so.
Isn't there some fact about how COBOL (which I'm reasonably sure doesn't have generics) still handles more transactions and/or more $$ per year than anything else?
Use another language then. What is the point of different languages if they are supposed to have the same feature set? If you want native code type safety and generics use Rust instead. If that is too complicated use a more friendly type safety focused language like Swift.
Really you are spoiled for choice and there is no need to insist every language should follow your particular language philosophy.
Yes, it's very impressive, and the purpose of the whole post IMO is part of the marketing (call me evil). Also if he didn't quit his job, he probably wouldn't be able to get this far within a year.
He was only a month away from completing the game when he quit. If he'd worked evenings and weekends, and used some vacation time, it seems like he could have easily finished and released the game by early next year. That way he wouldn't have to bet everything on the "magic unicorn" of instant Steam success.
I sometimes think people starting businesses take on an unnecessary amount of risk out of some unconscious belief that, by doing so, it will "prove" to God or the universe, or maybe just themselves, that they really want it.
From the name, I'm guessing he's Romanian; it's not illegal here to have a contract that states "everything you create, even in the spare time, is the company's property, unless you get written manager approval first". I have exactly such a contract. And yes I know it would be illegal in the US.
(I'm not exactly sure how enforceable such a clause would really be, but that's another story, and I really understand him not wanting to take the risk)
I haven't looked into it extensively, but I believe the EU has no laws about that. It's down to the individual countries, which have differing employment laws.
Nice link. I like Joel's writing. Haven't kept track of it in a while. The last para really rubbed me the wrong way ("sleeping with boss"). Most likely it was in jest but we need to have a zero tolerance to this kind of crap now (men and women).
Wait... you're offended by a non-gendered joke about the fact that interpersonal relationships in an office environment can impact the enforcement of contracts against you?
Do you just look for things to be offended by, or is there a particular reason?
You sound way more offended than the person you replied to. All I see up there is a harmless, well-intentioned critique with a perfectly civil tone. Meanwhile, you sound angry.
This similar in in Germany: It's not "everything is company property" but you need to ask permission to do "work" outside your employement, need to disclose if you create/"invent" something and allow the company to aquire your invention. Frankly, no idea how/if that will be enforced but something along these lines were in most contracted I had and it always made me feel uncomfortable.
I did some research about "work outside your employment" in Germany and found that the main thing is about the amount of hours one can (or is allowed) to work. The idea here was that working more than the "normal" 8 hours a day, would have a negative effect on the actual job, i.e. you're too tired to do your job properly if you work an additional 4 hours at home. In plain English, if you work additional hours daily on a side project, you'll be too tired the next day at work, hurting your productiveness (and upsetting your employer...). I did not find anything relating to weekends and/or to software created in one's spare time.
Are you aware of any specific laws concerning this whole thing?
It's an old link, but here's Apple enforcing that against a developer who developed an app in their spare time, and Apple wanting to take ownership of the app & source code:
That app is competing with Apple's iTunes, so that seems more like a non-compete issue. I'd like to see an example of an employee developing something completely unrelated to his employer's business.
My last company required IP assignment of all works that were:
- created on company hardware or
- related to the business in which the company engages
...and that struck me as eminently reasonable as a default. My current company defaults to everything full stop. I'm pretty sure this is going to be the default for most knowledge work in any state that hasn't specifically ruled such provisions unenforceable.
